구글은 오픈 소스 보안을 개선하기 위해 새로운 규칙을 만들 것을 제안합니다

오픈 소스 소프트웨어의 보안은 업계의 관심을 끌었습니다.,하지만 솔루션을 구현하려면 도전에 대한 합의와 협력이 필요합니다.

문제는 복잡하고 다루어야 할 측면이 많습니다. 무엇보다도 공급망, 종속성 관리, 신원에서. 이를 위해 Google은 최근 업계가 오픈 소스의 취약성과 먼저 해결해야하는 특정 영역에 대해 어떻게 생각할 수 있는지 설명하는 프레임 워크 ( '알고, 방지, 수정')를 출시했습니다.

Google은 그 이유를 설명합니다.

“최근 이벤트로 인해 소프트웨어 세계는 공급망 공격의 실제 위험에 대해 더 깊이 이해하게되었습니다. 모든 코드와 종속성이 개방되어 있고 검사 및 검증에 사용할 수 있으므로 오픈 소스 소프트웨어는 보안 측면에서 덜 위험해야합니다. 그리고 이것은 일반적으로 사실이지만 사람들이 실제로이 검사 작업을하고 있다고 가정합니다. 의존성이 너무 많아서 모든 것을 모니터링하는 것은 불가능하며 많은 오픈 소스 패키지가 잘 유지되지 않습니다.

“프로그램이 수천 개의 패키지와 라이브러리에 직간접 적으로 의존하는 것은 일반적입니다. 예를 들어 Kubernetes는 이제 약 1000 개의 패키지에 의존합니다. 오픈 소스는 아마도 독점 소프트웨어가 아닌 종속성을 사용하며 더 광범위한 공급 업체에서 제공합니다. 신뢰할 수있는 독립 엔티티의 수는 매우 클 수 있습니다. 이로 인해 제품에서 오픈 소스가 사용되는 방식과 관련 될 수있는 취약점을 이해하기가 매우 어렵습니다. 빌드 된 것이 소스 코드와 일치 할 것이라는 보장도 없습니다.

Google이 제안한 프레임 워크 내에서이 난이도를 크게 독립적 인 세 가지 문제 영역으로 나누는 것이 좋습니다. 각 영역에는 구체적인 목표가 있습니다.

소프트웨어의 취약성 파악

소프트웨어 취약성을 아는 것은 예상보다 어렵습니다. 여러 이유들로. 예 예 취약점을보고하는 메커니즘이 존재합니다. 사용중인 소프트웨어의 특정 버전에 실제로 영향을 미치는지 확실하지 않습니다.

• 목표 : 정확한 취약성 데이터 : 첫째, 사용 가능한 모든 데이터 소스에서 정확한 취약성 메타 데이터를 캡처하는 것이 중요합니다. 예를 들어, 취약점을 도입 한 버전을 아는 것은 소프트웨어가 영향을 받는지 확인하는 데 도움이되며 패치 된시기를 알면 정확하고시기 적절한 수정 (및 잠재적 인 악용 가능성이있는 창)을 얻을 수 있습니다. 이상적으로이 분류 워크 플로는 자동화되어야합니다.
• 둘째, 대부분의 취약점은 직접 작성하거나 제어하는 ​​코드가 아니라 종속성에 있습니다. 따라서 코드가 변경되지 않더라도 소프트웨어에 영향을 미치는 취약성의 환경은 지속적으로 변경 될 수 있습니다. 일부는 수정되고 일부는 추가됩니다.
• 목적 : 취약성 데이터베이스에 대한 표준 스키마 인프라 및 산업 표준은 오픈 소스 취약성을 추적 및 유지하고, 그 결과를 이해하고, 완화를 관리하는 데 필요합니다. 표준 취약성 체계를 사용하면 공통 도구를 여러 취약성 데이터베이스에서 실행하고 추적 작업을 단순화 할 수 있습니다. 특히 취약성이 여러 언어 또는 하위 시스템을 교차하는 경우 더욱 그렇습니다.

새로운 취약점 추가 방지

취약점 생성을 피하는 것이 이상적입니다. 테스트 및 분석 도구가 도움이 될 수 있지만 예방은 항상 어려운 주제입니다.

여기에, Google은 두 가지 특정 측면에 초점을 맞출 것을 제안합니다.

• 새로운 의존성을 결정할 때의 위험 이해
• 중요한 소프트웨어 개발 프로세스 개선

취약점 복구 또는 제거

Google은 수리의 일반적인 문제가 범위를 벗어난다는 것을 인정하지만 게시자는 배우가 문제를 해결하기 위해 할 수있는 일이 훨씬 더 많다고 믿습니다. 종속성의 취약성을 관리하기위한 것입니다.

또한 다음을 언급합니다. 

“오늘날이 문제에 대한 도움은 거의 없지만 정확성이 향상됨에 따라 새로운 프로세스와 도구에 투자하는 것이 좋습니다.

“물론 한 가지 옵션은 취약점을 직접 패치하는 것입니다. 이전 버전과 호환되는 방식으로이를 수행 할 수 있다면 모든 사람이 솔루션을 사용할 수 있습니다. 그러나 문제는 문제에 대한 경험이 없거나 직접 변경할 수있는 능력이 없다는 것입니다. 취약성을 수정하는 것은 또한 소프트웨어 유지 관리 책임자가 문제를 알고 있고 취약성을 공개 할 수있는 지식과 리소스를 가지고 있다고 가정합니다.

출처 : https://security.googleblog.com