모든 산업 분야에서 오픈 소스 소프트웨어는 계속해서 소프트웨어 보안 문제를 제기하고 있습니다. 우리 모두는 상용 및 오픈 소스 소프트웨어, 애플리케이션 및 운영 체제의 취약성이 소프트웨어 공급망 침해를 초래할 수 있다는 것을 알고 있지만 이제 웹 애플리케이션, API 서버, 모바일 장치 및 소프트웨어 구성 요소를 대상으로 하는 공격자를 목격하고 있습니다. 그것들을 구축하는 데 필요합니다.

오픈 소스 보안에 대한 Synopsys의 연간 연구 최신판이 방금 발표되었습니다. 그만큼 "오픈 소스 보안 및 위험 분석"(OSSRA) Synopsys의 연구에서는 1,700개 이상의 상용 코드베이스 감사 결과를 살펴봅니다.

Synopsys가 1,703년에 감사한 2022개의 코드베이스 중 96%가 오픈 소스를 포함했습니다. 항공우주, 항공, 자동차, 운송 및 물류 에듀테크; 17년 OSSRA 보고서에 포함된 2023개 산업 부문 중 100개 부문은 감사된 코드베이스의 92%에 오픈 소스를 포함했습니다. 나머지 업종에서는 코드베이스의 XNUMX% 이상이 오픈 소스를 포함했습니다.

고위험 취약점이 코드에 남아 있습니다.

2019년 이후로 고위험 취약점은 42개 OSSRA 비즈니스 전체에서 최소 17% 증가했으며, 소매 및 전자상거래 부문에서 +557%, 컴퓨터 하드웨어 및 반도체 부문에서 +317%까지 급증했습니다.

올해 OSSRA 보고서에 새로 추가된 XNUMX개년 회고에서는 오픈 소스 및 보안 동향에 대한 보다 포괄적인 그림을 제공합니다. 산업별 차이에도 불구하고 감사된 코드베이스의 전체 오픈 소스 콘텐츠는 전반적으로 증가했습니다. 또한 여러 산업에서 코드베이스에서 발견된 취약점의 수가 놀라울 정도로 증가한 것으로 나타나 취약점 완화가 부족함을 나타냅니다.

계속해서 해결해야 할 중요한 영역 중 하나는 패치 관리입니다. 감사를 받은 1,703개의 코드베이스 중 89%는 5년 이상 된 오픈 소스를 포함했습니다(2022년 보고서보다 91% 증가). 그리고 54%는 사용 가능한 최신 버전이 아닌 구성 요소를 사용했습니다. 즉, 업데이트 또는 패치를 사용할 수 있지만 적용되지 않았습니다. 패치 관리와 함께 라이센스 충돌은 계속해서 보안 문제를 야기합니다. 올해 감사된 코드베이스의 2%에는 라이선스 충돌이 있는 코드베이스가 포함되어 있으며 이는 작년보다 XNUMX% 증가한 것입니다.

소프트웨어를 업데이트하지 않는 데는 타당한 이유가 있지만 91% 수치의 상당 부분은 개발 팀이 최신 버전의 오픈 소스 구성 요소를 사용할 수 있다는 사실을 모르고 있기 때문일 수 있습니다. 회사가 코드에 사용된 오픈 소스의 정확한 최신 인벤토리를 유지하지 않으면 구성 요소가 고위험 익스플로잇에 노출될 때까지 눈에 띄지 않을 수 있습니다.

이것이 바로 Log4j에서 일어난 일이며 4년이 지난 후에도 여전히 문제입니다. 대중의 관심과 기업이 코드베이스에서 Log5j의 존재를 확인하고 수정하기 위해 취할 수 있는 많은 단계에도 불구하고 Log11j는 모든 코드베이스의 XNUMX%와 감사된 Java 코드베이스의 XNUMX%에서 지속됩니다.

보안을 위한 오픈 소스 모범 사례 수립

소프트웨어 거버넌스 모범 사례를 설정하면 오픈 소스 소프트웨어 관리 프로그램을 시작하여 리소스와 데이터를 제로 데이 취약성으로부터 보호하는 데 도움이 될 수 있습니다.

1. 정책을 정의합니다.

조직을 위한 오픈 소스 정책을 구축하면 법적, 기술 및 비즈니스 위험이 최소화됩니다. 주요 이해관계자를 식별한 다음 조직의 오픈 소스 소프트웨어 목표, 기존 활용도 및 대상 용도를 정의하려고 합니다. 이 정책은 오픈 소스 패치 및 라이선스뿐만 아니라 이를 유지 관리할 책임이 있는 사람을 식별해야 합니다.

2. 승인 프로세스를 만듭니다.

소프트웨어 패키지가 조직의 요구 사항과 품질 표준을 충족하는지 평가하기 위한 승인 프로세스를 설정합니다. 코드 품질, 지원, 프로젝트 성숙도, 기여자 평판 및 취약성 패턴을 고려하십시오. 이러한 기준을 고려하는 승인 프로세스는 팀이 조직의 코드에 동일한 소프트웨어 패키지의 여러 버전을 포함하는 것을 방지하며, 그 중 일부는 패치되거나 업그레이드되지 않았을 수 있습니다.

3. 오픈 소스 소프트웨어에 대한 감사.

감사는 오픈 소스 소프트웨어를 드러내고 회사 규정을 준수하는지 확인합니다. 이를 통해 오픈 소스 라이선스 준수 및 취약성 공개를 위한 구성 요소를 찾을 수 있습니다. 소프트웨어 개발 수명 주기(SDLC) 전체에 걸쳐 오픈 소스 스캔을 수행해야 하지만, 애플리케이션이 오픈 소스 소프트웨어를 활용하는 릴리스 후보에 빌드될 때마다 최종 스캔을 수행해야 합니다. 특히 타사의 구성 요소에 의존하는 경우 파티.

4. SBOM 구축

소프트웨어 재료 명세서(SBOM)는 코드베이스에 있는 모든 오픈 소스 및 타사 구성 요소 목록입니다. 또한 SBOM에는 이러한 구성 요소를 제어하는 ​​라이선스, 코드베이스에 사용되는 구성 요소의 버전 및 해당 패치 상태가 나열되어 보안 팀이 관련 보안 또는 라이선스 위험을 신속하게 식별할 수 있습니다. 이 작업을 자동화하면 부정확한 수동 오픈 소스 인벤토리가 제거됩니다.

적절한 보안 관행을 마련함으로써 오픈 소스 취약성 위험을 파악하고 이를 관리하기 위한 강력한 시스템을 구축할 수 있습니다.

저자에 관하여

Charlotte Freeman은 20년 넘게 기술과 보안에 관해 글을 써왔습니다. 그녀는 현재 Synopsys Software Integrity Group의 선임 보안 작가입니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://www.darkreading.com/application-security/open-source-vulnerabilities-still-pose-a-big-challenge-for-security-teams