지난 몇 년 동안에 대해 많은 말이 쓰여졌습니다. SBOM – 소프트웨어 BOM. 이러한 모든 노출을 통해 사람들은 설명하기에 충분할 만큼 잘 알고 있다고 느낍니다. 이는 소프트웨어 구성 요소의 목록이고 투명성과 보안에 중요하며 일시적인 종속성을 노출하는 데 도움이 됩니다. 이 모든 것은 사실입니다.
그러나 SBOM은 보이는 것만큼 명확하지 않습니다. 우선, 각각의 새 라이브러리 버전이나 패치를 계속 업데이트하려면 새 SBOM을 출시해야 한다는 점을 고려하세요. 종종 한 번에 하나 또는 두 개의 라이브러리만 변경하거나 패치하여 새로운 구성 요소를 분석하고 이를 SBOM에 추가하고 다른 모든 항목은 동일하게 유지할 수 있습니다. 그렇죠?
그리고 '알려진 것-알려지지 않은 것'이라는 개념은 어떻습니까? 개발자가 누락된 항목이 있다는 것을 알고 있는 경우 이를 '알려짐-알 수 없음'으로 입력하고 나중에 공백을 채울 수 있습니다(또는 전혀 채울 수 없음).
매우 복잡하고 여러 개의 연동 요소를 포함하는 소프트웨어 가공물도 있으며, 각각은 그 자체로 소프트웨어 가공물입니다. 각 요소에는 자체적인 별도의 SBOM이 있는 경우가 많으며 전체 빌드는 더 크고 집계된 SBOM을 가질 수 있습니다.
이 모든 것은 명확하고 단순한 SBOM 파일 대신 가능한 한 지속적으로 최신 상태를 유지해야 하는 다양하고 끊임없이 변화하는 요소로 끝날 수 있음을 보여줍니다.
이것은 모두 훌륭하지만 SBOM 또는 SBOM의 일부가 정확하지 않거나 최신 상태가 아닌 경우 누구에게나 어떤 차이가 있습니까? SBOM의 출처와 정확성을 모두 유지하려면 어떻게 해야 합니까?
이 기사에서는 취약점 스캔 및 취약점 공개에 SBOM을 사용하는 방법을 살펴보겠습니다. 암호화 서명에 대해 이야기하고 SBOM 또는 그 일부에 서명하면 보안 및 투명성 도구로서 어떻게 더 유용해지는지 살펴보겠습니다. 또한 메타데이터에 대해 이야기하고, 특히 암호화 방식으로 증명에 로그인할 때 SBOM 및 기타 아티팩트 생산에서 메타데이터가 중요한 이유에 대해 설명합니다.
여기에서 시작하세요: 암호화 서명이 무엇인가요?
암호화 서명은 디지털 파일이나 폴더의 무결성과 정확성을 확인하는 데 사용됩니다. 서명된 파일은 서명을 무효화하지 않고는 변조할 수 없으므로 누군가 서명된 문서를 확인하려고 하면 즉시 발견됩니다.
따라서 디지털 서명은 무기고에서 귀중한 도구가 됩니다. 소프트웨어 보안 업계에서는 디지털 자산의 간단한 디지털 또는 암호화 서명 개념에 대한 수많은 용도가 이미 발견되었습니다.
어떻게 작동하나요? 디지털 서명은 엔터티가 개인 키와 공개 키라는 두 개의 키를 갖는 비대칭 암호화를 기반으로 합니다. 두 개의 키는 개인 키로 서명된 문서를 공개 키를 사용하여 확인할 수 있도록 서로 연결되어 있습니다. 확인은 문서가 어떤 식으로든 변조되지 않았음을 의미하며(단일 비트만 변경해도 서명을 확인할 수 없게 됨) 서명자의 신원 또는 최소한 사용된 키의 신원을 증명합니다.
그 SBOM으로 무엇을 하고 있나요?
SBOM은 소프트웨어 구성 요소 정보가 포함된 길고 복잡한 파일이 아닙니다. 소프트웨어 결과물을 구성하는 구성 요소가 무엇인지 정확히 알 수 있는 관문입니다. 포함된 내용을 정확히 알고 있다고 생각하더라도 전체 구성 요소 목록을 알아야 합니다. 추가된 모든 라이브러리와 함께 수많은 숨겨진 임시 종속성을 제공할 가능성이 높으며, 각 종속성은 다음과 같은 취약성 또는 악용의 전달체가 될 수 있습니다. 이제 귀하가 고객에게 제공하는 소프트웨어에 포함되어 있습니다.
SBOM과 전체 구성 요소 목록이 있으면 해당 목록을 알려진 취약성 데이터베이스와 비교하여 소프트웨어에 어떤 취약성이 포함되어 있는지 확인할 수 있습니다. 그러나 그것은 시작에 불과합니다. 취약점 스캔을 실행해 본 사람이라면 누구나 알고 있듯이 간단한 아티팩트 스캔의 결과에도 쉽게 수백 개(또는 그 이상)의 취약점이 있을 수 있습니다.
여기에서 각 취약점을 매핑하고, 해당 취약점이 특정 소프트웨어 구성에서 악용될 수 있는지 확인하고, 해당 정보를 문서화하고, 가급적 위험 순서에 따라 패치 및 교정을 통해 악용 가능한 취약점을 처리하는 등의 노력이 시작됩니다. 실제 공격은 아직 발생하지 않은 이론적 공격보다 더 위험합니다.
이 모든 작업과 취약점 문서화 및 해결은 소프트웨어 제작자로서 중요하지만 고객, 파트너 및 잠재적 감사자에게도 중요합니다.
그들은 귀하가 잠재적인 취약점을 알고 있고 그 위에 결함을 패치하고 수정하여 고객이나 파트너인 그들에게 영향을 미치지 않는다는 것을 알고 싶어합니다.
새로운 취약점이 지속적으로 드러나기 때문에 스캔을 수행하는 시간이 중요하므로 SBOM이 생성된 시기의 메타데이터와 함께 서명하는 것은 자신이 실제로 최고임을 보여주는 좋은 방법입니다. 귀하의 취약점 목록.
이런 방식으로 취약점에 대해 미리 알고 있었고 관련성이 없다는 것을 증명할 수 있습니다( VEX 권고), 특정 버전에 존재하지 않거나 마지막 버전을 출시할 당시에는 존재하지도 않았다는 것입니다.
어디에 서명합니까?
이제 간단한 성분 목록 파일을 기사 시작 부분에 설명된 보다 복잡한 사용 사례 중 하나로 바꾸겠습니다. 전체 아티팩트를 설명하기 위해 여러 개의 SBOM을 결합하여 더 큰 집계 버전을 형성하면 해당 집계 버전의 각 개별 부분에 서명하고 확인하는 것이 더욱 중요해집니다. 복잡한 소프트웨어 결과물의 새 버전을 구축한다고 가정해 보겠습니다. 이 새 버전에서 변경된 유일한 사항은 1부분으로 구성된 아티팩트 중 3부입니다. 나머지 두 부분은 완전히 동일하게 유지됩니다. 전체 3부분으로 구성된 SBOM을 구축하고, 3개 모두에서 취약점을 검색하고, 3개 모두에 관련 익스플로잇을 매핑하는 데 시간과 리소스를 낭비해야 하는 이유는 무엇입니까? 유일한 변경 사항은 파트 1에 있었기 때문에 작업을 적용해야 하는 유일한 부분입니다. 마지막으로 생성했을 때 3개의 SBOM 및 취약점 스캔을 모두 서명한 경우 다른 두 부분의 정보를 포함할 수 있습니다. 수정되지 않았습니다. 그러면 파트 2와 3의 SBOM이 원래 버전과 동일하다는 것을 언제든지 증명할 수 있습니다. 물론 새로운 취약점이 걱정된다면 다시 스캔을 수행할 수 있지만 이는 전적으로 귀하와 귀하의 소프트웨어에 달려 있습니다. 위험도 분석.
SBOM을 생성하고 취약점을 검색한 시기와 빈도를 고객, 파트너 및 감사자에게 입증할 수 있으면 여러 가지 이유로 유용합니다. 그 중 중요한 것은 귀하가 보호받기 위해 해야 할 모든 일을 했기 때문에 착취로 인한 손해에 대해 책임이 없다는 것을 법정에서 증명하는 데 사용될 수 있다는 것입니다. 안전한 항구.
어디에서 가야할 것인가?
앞서 언급했듯이 소프트웨어 아티팩트나 파일의 디지털 서명과 관련된 문제 중 하나는 키 관리 시스템을 처리하는 번거로움입니다. Sigstore와 같은 것을 사용하여 기존 PKI 사용을 우회하고 서명 및 확인 흐름을 자동으로 만들어 이러한 번거로움을 제거하면 이 보안 도구를 사용하지 않을 이유가 거의 없습니다. 파일이나 아티팩트에 서명하는 데 사용되는 ID가 CI/CD 파이프라인의 보안을 확인하는 정책에도 사용될 수 있다는 점을 고려하면 눈에 보이는 거의 모든 것에 서명을 시작하려는 동기가 더욱 커져야 합니다.
메타데이터로 파일에 서명하면 원본의 시간과 위치는 물론 파일이 생성된 페르소나와 시스템, 보안 전문가의 관점에서 고려할 때 모든 관련 정보를 확인하는 데 도움이 될 수 있습니다. 사람, 시스템 및 시간이 소프트웨어가 만들어진 회사 및 파이프라인과 일치하는지 알 수 있다는 것은 노래하는 페르소나가 확인될 때까지 간단한 대체가 서명된 확실한 위조품을 나타낼 수 있는 경우 좋은 생각입니다.
증거에 서명하고 확인하기 위해 제가 제안하는 도구가 무료로 사용할 수 있다는 점을 고려하면 정말 변명의 여지가 없습니다. 전체 기사를 확인하세요. 발린트 – 우리의 검증 무결성 도구를 사용하여 다른 무엇을 할 수 있는지 확인하고 지금 바로 SBOM 및 기타 생성된 증거에 서명을 시작하세요.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
