세 개의 미국 정부 기관이 함께 모여 개발자들이 특정 관행을 채택하도록 "강하게 권장"할 때 주의를 기울여야 합니다. CISA, NSA 및 ODNI는 사이버 해커의 위협과 SolarWinds 공격을 인식하여 향후 이러한 취약점을 방지하기 위해 소프트웨어 공급망 보안을 위한 권장 사항 모음을 공동으로 발표할 것이라고 발표했습니다. . 발표에서는 이 문서의 목적이 개발자들이 모범 사례를 채택하도록 장려하는 것임을 분명히 밝혔습니다.이러한 원칙에는 보안 요구 사항 계획, 보안 관점에서 소프트웨어 아키텍처 설계, 보안 기능 추가, 소프트웨어 및 기본 인프라의 보안 유지 관리가 포함됩니다."
이 지침은 세 부분으로 구성된 시리즈로 구성되어 있으며 소프트웨어 공급망 수명주기와 동시에 발표될 예정입니다. 시리즈 1부소프트웨어 개발자를 위한 권장 사항에 초점을 맞춘 가 2022년 2월에 출시되었습니다. 나머지 두 부분은 가까운 시일 내에 출시될 예정입니다. 파트 3는 소프트웨어 공급업체에 초점을 맞추고 파트 XNUMX은 소프트웨어를 받는 고객에 초점을 맞춥니다. 궁극적인 목표는 이 시리즈가 세 가지 주요 이해관계자와 사이버 보안 전문가 간의 의사소통을 촉진하여 탄력성을 높이고 전반적인 개선을 촉진하는 데 도움이 되는 것입니다. 소프트웨어 공급망 보안.
소프트웨어 보안을 보장하는 것이 누구의 책임인지 항상 명확하지는 않지만 특정 조직에서 누가 전반적인 책임을 지는지에 관계없이 이는 새로운 가이드 모든 개발자가 이러한 새로운 모범 사례를 숙지해야 하며 모두가 소프트웨어 공급망을 보호하는 역할을 맡고 있음을 매우 분명하게 보여줍니다. 아니면 좀 더 솔직하게 말하면: 개발자 여러분, 여러분은 조직의 소프트웨어 공급망을 보호하는 데 중요한 역할을 합니다! 이러한 이유로 우리는 가이드의 첫 번째 부분에 대한 (상대적으로) 짧은 요약을 읽는 것이 도움이 될 것이라고 생각했습니다. 여기 온다.
간단히 말해서 가이드:
개발자를 위한 이 실무 가이드에 언급된 잠재적인 위협의 광범위한 목록 중에는 확인된 몇 가지 주요 취약점이 있으며 이를 해결하고 준비해야 합니다.
- 제대로 문서화되지 않았거나 위험한 기능을 구현하는 기능
- 보안 평가 시점과 코드 전달 시점 사이에 핵심 보안 가정의 비밀스러운 변화
- 공급망 이해관계자에 대한 기업의 변화
- 하위 표준 코딩 또는 보안 관행
관리, 재무 및 프로그램 관리자는 모두 소프트웨어 공급망의 보안을 다룰 책임이 있습니다. 소프트웨어 공급망 보안 이는 종종 소프트웨어 개발자의 경계와 모든 공급망 이해관계자의 인식에 달려 있습니다. 가이드의 1부에서는 개발자의 역할과 개발 프로세스의 각 단계에 내재된 위협에 중점을 두고 표준 관행이 되어야 하는 완화 전략에 대한 권장 사항을 제공합니다.
1단계: 제품 기준 및 관리 확보
안전한 개발은 제품 및 개발 팀의 모든 주요 이해관계자가 소프트웨어 공급망 보안의 중요성을 인식하는 것에서 시작됩니다. 위협 시나리오는 일반적이며 모든 사람에게 명확할 수 있습니다. 해결해야 할 과제는 결정된 완화 정책에 대해 모든 사람이 같은 생각을 갖도록 하는 것입니다. 이러한 정책은 설계 및 아키텍처, 위협 모델링, 코딩, 보안 테스트 계획, 릴리스 기준, 향후 취약점 관리 방법 등 전체 프로세스를 포괄해야 합니다. 여기에는 팀의 역량을 평가하고 해당 작업에 대해 적절한 교육을 받았는지 확인한 다음 문서화 관행을 정의하고 정기적인 보안 검토 및 위협 평가도 포함됩니다.
2단계: 보안 코드 개발
코드 개발과 관련하여 보안 코딩에 대한 올바른 관행은 이미 SSDF. 프로그래밍 언어가 미리 결정되지 않은 경우 보안 고려사항도 결정의 일부가 되어야 하는 이유입니다. 가이드 유용한 지침을 제공합니다 개발자를 위해 '내부자'(예: 개발자)에 의한 유해한 소스 코드 삽입, 오픈 소스 소프트웨어 및 이를 처리하기 위한 모범 사례와 같은 광범위한 시나리오를 다룹니다. 코딩을 위한 보안 환경(보안 빌드 구성 및 타사 소프트웨어 도구 포함)을 생성하고 이후 통합 제품의 보안을 테스트하는 방법입니다. 취약점은 배송 후에도 발생할 가능성이 높으므로 보고된 취약점을 처리하고 향후 외부 소프트웨어 확장으로 인해 제품의 보안 무결성이 손상되지 않도록 하기 위한 권장 사항도 있습니다.
3단계: 빌드 환경 강화
코드가 안전하게 개발되면 소프트웨어 공급망 보안을 위해서는 빌드 환경이 소프트웨어 자체와 동일한 표준으로 강화되어야 합니다. 빌드 시스템을 손상시키는 것은 코드에 침투하는 매력적인 방법입니다. 왜냐하면 이는 개발자가 자연스럽게 덜 면밀히 조사하는 개발 프로세스 단계에 있기 때문입니다.
4단계: 코드 전달
가이드에서 해결한 마지막 약점은 소프트웨어 공급망의 마지막 단계인 코드 전달을 다루고 있습니다. 지금까지 코드가 적절하게 보호되었더라도 완화해야 할 두 가지 주요 공급망 취약점이 여전히 있습니다. 첫 번째는 메타데이터, 개발자 자격 증명 또는 오픈 소스 인벤토리를 실수로 노출하는 등의 방법으로 악용될 수 있는 최종 패키지 유효성 검사입니다. 약점으로 자주 조사되는 또 다른 단계는 배포 시스템으로, 이는 배송 중 하나 이상의 단계를 장악할 수 있는 중간자 공격으로 인해 손상될 수 있습니다.
소프트웨어 개발 수준에서 이러한 위험 완화 방법을 적용함으로써 소프트웨어 공급업체는 업데이트 침투, 코드 서명 조작, 오픈 소스 코드에 숨겨진 "놀라움" 등으로 이어질 수 있는 약점을 피할 수 있습니다.
공짜 점심은 없다: 타사 소프트웨어의 숨겨진 비용
키 개발자 속도에 기여한 사람 타사 소프트웨어를 효과적으로 통합하는 기능이 되었습니다. 이를 통해 개발자는 확장성이나 인터페이스를 위해 기성 구성 요소를 사용하면서 혁신이나 기능 등에 집중할 수 있습니다. 이러한 타사 소프트웨어의 사용 증가로 인해 소프트웨어 공급망 보안에 큰 문제가 발생했습니다. 자신의 코드를 평가하는 데 사용된 것과 동일한 표준에 따라 이러한 코드를 평가하는 것 외에도 이 가이드에서는 바이너리에서 취약점을 검색하고 그에 따른 위험을 평가할 것을 제안합니다. 이 평가 결과는 특정 소프트웨어 구성 요소를 사용할지 여부를 결정하는 데 영향을 미칩니다. 소프트웨어 구성 요소를 선택할 때는 해당 소스도 고려해야 합니다. 타사 구성 요소를 소스 코드에 통합하는 것은 오랜 관계의 시작이며 신뢰할 수 있는 파트너와 협력하기 위해 노력해야 합니다. 코드 소유권, 코딩 방식 및 버전 관리 정책은 신뢰할 수 있는 소스를 선택할 때 고려해야 할 몇 가지 사항에 불과합니다. 새로운 위협이 발견되면 각 구성 요소에 대한 향후 모든 업데이트, 릴리스 및 유지 관리 작업을 생각해 보십시오. 어려운 점은 모든 타사 변경 사항을 모니터링하고, 취약성을 평가하고, 그에 따라 대응하는 것입니다. 때로는 심각한 시간적 압박 속에서도 마찬가지입니다.
SBOM을 통해 소프트웨어 공급망 보안 강화
소프트웨어 공급망의 장기적인 무결성을 보장하는 주요 방법 중 하나는 업데이트된 버전을 유지하는 것입니다. 소프트웨어 BOM (SBOM). SBOM은 특정 솔루션을 구성하는 소프트웨어 구성 요소의 세부 인벤토리입니다.
이렇게 하면 시간과 노력이 절약되고 가장 중요한 것은 지속적인 위협에 대한 노출을 줄일 수 있습니다. 제품에 통합된 각 소프트웨어 구성 요소는 자체 SBOM과 함께 제공되어야 하며, 이는 검증되고 제품의 단일 '마스터' SBOM으로 병합되어야 합니다. SBOM과 함께 제공되지 않는 구성 요소를 통합하려는 경우 SCA(소프트웨어 구성 분석) 도구를 사용하여 자체 분석을 수행해야 합니다.
SBOM이 더 정확하고 설명적일수록 유지 관리 및 참조가 더 쉬워집니다. 소프트웨어 구성 요소가 업데이트되는 어지러운 속도를 고려하면 잘 구성된 SBOM 모든 업데이트, 패치 또는 릴리스를 추적하고 기록해야 할 때가 되면 큰 도움이 될 것입니다. 더욱 중요한 것은 보안 위협이 발견되면 매 순간이 중요하다는 것입니다. 생각해 내다다음 소프트웨어 공급망 보안 항상 당신의 가장 약한 고리만큼 강할 것입니다. 수십 개의 소프트웨어 구성 요소가 위험에 처해 있는 경우 모든 답변을 제공하는 SBOM에 감사하게 될 것입니다.
효율적인 워크플로를 위해 유용한 SBOM에는 최소한 다음 세 가지 구성 요소가 포함되어야 합니다.
- 데이터 필드 – 구현한 구성 요소에 대한 설명입니다. 개발이 완료된 후에도 어떤 구성 요소가 사용되었는지 쉽게 식별할 수 있으면 해당 구성 요소의 취약점을 효과적으로 모니터링하는 데 도움이 됩니다.
- 자동화 지원 – SBOM의 자동 모니터링을 위해서는 허용되는 기계 판독 가능 형식 중 하나로 식별되어야 합니다.
- 실천과 약속 – SBOM을 관리하려면 버전 빈도, 종속성, 알려진 알 수 없는 항목, 배포 및 전달, 액세스 제어, 실수 수용 방법 등 유지 관리 방식에 대한 공통된 이해가 필요합니다.
특정 제품의 이해관계자(소프트웨어 개발자, 소프트웨어 공급업체 및 고객) 간에 SBOM을 공유하면 투명성과 조정을 촉진하고 보안 위협으로부터 제품을 보호하는 소프트웨어 공급망의 능력을 높이는 데 도움이 됩니다. 소프트웨어 공급망의 모든 움직이는 부분을 고려할 때 쉽게 참조, 모니터링 및 유지 관리할 수 있는 SBOM을 일관되게 유지하는 것은 복잡한 과제라는 점에 유의해야 합니다.
마지막 말씀: 소프트웨어 공급망 보안을 어떻게 한 단계 더 높일 수 있습니까?
소프트웨어 공급망 보안이 점점 더 중요해짐에 따라 조직은 제공하거나 사용하는 소프트웨어에 대한 투명한 신뢰를 구축해야 하는 과제를 반복적으로 받고 있습니다. SBOM을 모범 사례로 채택하는 사례가 늘어날 것으로 예상되므로 이러한 문제를 극복할 수 있는 도구를 갖추는 것이 소프트웨어 공급망 보안을 구축하기 위한 핵심 단계입니다. 이것이 바로 우리가 최근 소프트웨어 제품을 위한 최초의 증거 기반 보안 허브를 출시한 이유입니다. 사용자가 팀과 조직 전체에서 소프트웨어에 대한 신뢰를 구축할 수 있도록 지원합니다. 이 사용자 친화적인 플랫폼은 SBOM을 액세스 가능하고 사용하기 쉽게 만들어 개발 팀이 소프트웨어 공급망 위험을 완화하는 데 도움이 되며 가장 중요하게는 다음과 같습니다.소프트웨어 제품의 보안을 고객, 구매자 및 보안 팀에게 투명하게 만듭니다..
소프트웨어 개발자로서 소프트웨어 공급망 보안에 대한 위협이 우려되는 경우 다음을 촉구합니다. 플랫폼을 사용해 보세요; 무료로 사용할 수 있으며 조건이 없습니다. 워크플로우를 구현하면 공급망 전체에서 SBOM을 공유할 수 있습니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
