소프트웨어 공급망은 개발 라이프사이클 전반에 걸쳐 어떤 방식으로든 소프트웨어 코드에 연결된 모든 것을 의미합니다. 모든 소프트웨어는 여러 구성 요소로 구성됩니다. 처음부터 작성된 독점 코드 외에도 코드가 제대로 작동하려면 외부 소프트웨어 인프라, 클라우드 서비스, 운영 체제도 필요합니다. 레지스트리, 리포지토리, 코드베이스, 심지어 이 소프트웨어를 작성한 사람들까지 모두 소프트웨어 공급망의 일부입니다.
이 복잡한 체인의 각 노드는 어떤 방식으로든 소프트웨어의 성능과 보안에 영향을 미칠 수 있는 잠재적인 취약점 지점입니다. 이 종속성 체인의 어느 지점에서든 발생하는 취약점은 다운스트림에 심각한 영향을 미칩니다. 소프트웨어 공급망의 복잡성으로 인해 위험이 가려지고 공급망 보안을 위한 표준화된 프레임워크 없이는 예측 및 식별이 어렵기 때문입니다. 이것이 바로 개발자와 제품 조직이 다음을 수행하는 것이 중요한 이유입니다. 소프트웨어 공급망 보안이 무엇인지 알아보세요.
소프트웨어 공급망 보안은 애플리케이션 개발 시점부터 지속적인 통합 및 배포(CI/CD 파이프라인)를 통해 소프트웨어 개발 수명주기 전반에 걸쳐 잠재적인 취약성으로부터 소프트웨어를 보호하기 위해 마련된 일련의 표준화된 방식을 의미합니다.
조직의 소프트웨어 공급망을 안전하게 유지하려면 보안 팀이 소프트웨어 공급망 보안 모범 사례 목록을 이해하고 따르는 것이 중요합니다. 이 게시물에서는 알아야 할 공급망 모범 사례를 자세히 설명합니다.
소프트웨어 공급망 보안을 위한 모범 사례
이 섹션에서는 개발자와 제품 조직이 소프트웨어 공급망을 보호하기 위해 따라야 하는 표준 관행을 언급합니다. 소프트웨어 수명주기의 다양한 단계에서 조직의 보안 관행을 설명, 평가 및 측정하기 위한 기본 프레임워크로 이러한 지침을 사용할 수 있습니다. 이러한 모범 사례는 소프트웨어 공급망의 획득, 개발 및 배포 단계 전반에 걸쳐 개발 환경, 소스 코드 및 최종 제품의 무결성을 보장합니다.
보안이 철저한 구성 요소 확보
타사 구성 요소를 소프트웨어에 통합하는 것은 개발자의 표준 관행입니다. 이를 통해 개발자는 처음부터 구축하는 대신 기존 API 기능을 활용하여 원하는 기능을 제공할 수 있습니다. 타사 구성 요소는 상용 독점 소프트웨어 또는 무료 오픈 소스 도구의 형태일 수 있습니다. 이러한 구성 요소 중 하나를 소싱할 때 소프트웨어 구성 요소가 충족해야 하는 가장 중요한 기준 중 하나로 보안을 고려하는 것이 중요합니다.
타사 구성 요소의 보안을 확인하려면 보안 구성 분석, 취약성 데이터베이스 분석, 소스 코드 평가 및 위험 평가 분석과 같은 고급 보안 분석을 수행해야 할 수 있습니다. 이러한 검사 결과는 이 구성 요소가 안전하고 제품에 허용되어야 하는지 결정하는 데 도움이 됩니다.
또한 선택한 구성 요소는 자동화된 취약점 추적 서비스를 사용하여 지속적으로 모니터링하여 가능한 한 빨리 취약점을 식별하고 제거해야 합니다.
보안 코딩 관행을 준수하는 보안 소프트웨어 구성 요소를 사내에서 생성
소프트웨어에 통합된 외부 소프트웨어 구성 요소도 중요하지만 소프트웨어 제품의 보안과 무결성은 사내에서 따르는 보안 코딩 방식에 따라 달라집니다.
모든 조직에는 생성된 아티팩트가 규정된 지침을 준수하도록 보안 코딩 방식을 통합하는 포괄적인 소프트웨어 개발 수명 주기 프레임워크가 필요합니다.
우선, 소프트웨어 제품의 무결성과 사내에서 구축한 결과물은 팀의 품질에 따라 달라집니다. 개발 팀에는 표준 보안 관행에 대한 풍부한 지식을 갖춘 개발 전문가, 품질 보증, 사이버 보안 전문가 및 빌드 엔지니어가 포함되어야 합니다.
제품 관리 팀에는 보안 개발 정책을 준수하도록 노력하는 보안 설계자, 제품 관리자 및 제품 리더도 포함되어야 합니다. 사내에서 안전한 소프트웨어 아티팩트를 생성하는지 확인하기 위한 몇 가지 기본 전략은 다음과 같습니다.
- 각 아티팩트에 대한 디자인 및 아키텍처 문서 생성
- 소프트웨어 제품에 대한 위협 모델 만들기
- 보안 테스트 정의 및 구현
- 제품 평가를 위한 구체적인 출시 기준 설정
- 제품별 취약점 처리 정책 수립
- 각 소프트웨어 릴리스에 대한 보안 절차 문서화 및 게시
안전한 타사 소프트웨어 툴체인 및 호환성 라이브러리 사용
소프트웨어 개발 프로세스에 사용되는 많은 통합 개발 환경(IDE)은 독립형입니다. 즉, 코딩, 컴파일, 패키징, 코드 디버깅 등 개발 프로세스 내에서 다양한 단계를 모두 동일한 도구에서 수행할 수 있습니다. 일부 IDE에는 소스를 외부 저장소에 연결하는 도구도 있습니다. 이 기능이 있는 IDE는 여러 컴파일러 언어를 지원합니다. 이러한 핵심 기능 외에도 개발자는 플러그인을 사용하여 IDE의 기능을 확장할 수 있습니다. 이는 이와 같이 신뢰할 수 없는 소스의 복잡성으로 인해 로컬 개발 환경에 대한 잠재적인 취약점의 원인입니다.
개발 환경을 안전하게 유지하려면 해당 환경 내에서 사용되는 모든 IDE 및 플러그인을 감사하고, 취약점을 스캔하고 검증한 후 사전 승인을 받아야 합니다.
빌드 환경의 기능을 확장하는 플러그인 외에도 취약점을 확인해야 할 수 있는 타사 빌드 도구의 또 다른 범주는 소프트웨어 도구 체인 및 호환성 라이브러리입니다. 이러한 타사 운영 체제 도구는 해당 운영 체제에 고유한 특정 유틸리티와 명령을 사용할 수 있도록 개발 환경에 설치됩니다. 예를 들어, Windows 개발 환경에서는 프로덕션 프로세스 중 두 시스템 간의 호환성을 제공하기 위해 빌드 프로세스 중에 Linux 운영 체제에 고유한 일부 운영 체제 명령이 필요할 수 있습니다.
마찬가지로 API 변환 라이브러리는 서로 다른 두 운영 체제에 대한 공통 코딩 환경을 만드는 데에도 도움이 됩니다. 이러한 API 도구 체인은 오픈 소스 및 상용 도구이며 빌드 환경에 채택되고 프로젝트에 사용되기 전에 취약점에 액세스해야 합니다.
내부자에 의한 소스 코드 수정 또는 악용 완화
CISA(사이버보안 및 인프라 보안국)에 따르면 내부자는 조직의 리소스에 대한 액세스 권한이 있거나 지식이 있는 모든 사람입니다. 귀하의 시설, 네트워크, 장비 및 시스템에 접근했거나 액세스할 수 있었던 개인은 의도적이든 무의식적으로든 소프트웨어 제품의 무결성을 잠재적으로 위험에 빠뜨릴 수 있습니다.
소프트웨어를 보호하기 위한 노력의 일환으로, 손상된 직원, 교육을 제대로 받지 못한 엔지니어 또는 활동하지 않는 직원과 같은 내부자에 의해 프로덕션 코드의 악성 코드에 의도적이거나 의도하지 않은 노출을 방지하기 위한 정책이 개발 프로세스에 마련되어 있는지 확인해야 합니다. 이를 완화하기 위해 취할 수 있는 조치 중 일부는 다음과 같습니다.
- 균형있고 인증된 소스코드 체크인 프로세스
- 취약점에 대한 자동 보안 스캐닝
- 보안 소프트웨어 개발 교육
- 개발 환경 강화
- 코드 검토 우선순위 지정
코드 또는 실행 파일을 저장하고 승인 전에 모든 변경 사항을 검토합니다.
버전 관리는 소프트웨어의 무결성을 유지하는 데 도움이 되는 표준 관행 중 하나입니다. 지속적인 통합 및 배포 프로세스(CI/CD 파이프라인)의 일부로 코드와 실행 파일을 저장할 리포지토리를 유지 관리해야 합니다. 이는 코드의 작업 기록을 제공하므로 해당 지점까지 개발 스택에 들어간 내용을 쉽게 추적할 수 있습니다.
또한 승인되기 전에 소프트웨어에 적용된 모든 변경 사항을 검토하려면 지속적인 승인 시스템이 필요합니다. 이는 팀 내에서 다른 개발자와 공동 작업할 때 특히 유용합니다. 이 경우 변경 사항이 적용되는 동안, 변경한 사람을 쉽게 식별할 수 있으므로 문제 해결이 더 쉽습니다.
구축 중인 소프트웨어가 얼마나 간단하든 복잡하든 소스 또는 버전 제어 시스템을 사용하면 코드에 대한 모든 변경 사항을 쉽게 보고 추적할 수 있으며 필요할 때 버전 기록을 추적하거나 이전 버전으로 되돌릴 수도 있습니다. 필요할 때 코드.
생성된 각 소프트웨어 패키지에 대한 SBOM 생성 및 유지 관리
XNUMXD덴탈의 소프트웨어 BOM 소프트웨어 제품에 통합된 모든 타사 구성 요소를 자세히 설명하는 중요한 문서입니다. SBOM을 사용하면 소프트웨어의 승인된 모든 구성 요소를 쉽게 검증하고 취약점이나 결함을 쉽게 식별할 수 있습니다. 생성하는 모든 소프트웨어 패키지에 대해 SBOM도 생성하고 유지 관리해야 합니다.
소프트웨어 BOM은 각각 Linux, OWASP 및 NIST에서 정의한 SPDX(Software Package Data Exchange), CycloneDX 및 SWID(Software Identification) 태그와 같은 표준 형식으로 정의된 사양을 기반으로 준비할 수 있습니다.
귀하가 구축하는 모든 소프트웨어 제품에 대해 귀하가 사용하는 타사 구성 요소의 공급업체 또는 소유자는 포괄적인 소프트웨어 BOM을 제공해야 합니다. 프로젝트의 결과물과 공급업체가 제공하는 SBOM은 구성 분석(SCA) 도구를 사용하여 검증할 수도 있습니다.
공급업체가 SBOM을 제공하지 않더라도 소프트웨어 구성 분석 도구로 생성된 SBOM은 소프트웨어의 타사 구성 요소를 설명하는 데 필요한 정보를 계속 제공할 수 있습니다. 과정은 SBOM 생성 자동화되어야 합니다. SBOM 자동화 타사 공급업체와 개발자는 타사 소프트웨어가 수정될 때마다 새로운 SBOM을 생성해야 하며 수동으로 생성하는 것은 비실용적이기 때문에 매우 중요합니다. 업데이트된 SBOM은 구성 요소 코드의 향상 또는 변경 사항과 구성 요소와의 관계를 설명합니다. 소프트웨어 제품.
빌드 환경 강화
소프트웨어의 무결성을 보장하는 방법 중 하나는 잠재적인 취약점에 대비하여 개발 환경을 강화하는 것입니다. 여기에는 개별 개발자 환경과 전체 프로덕션 빌드 환경이 모두 포함됩니다.
빌드 환경이 클라우드에서 호스팅되든 온프레미스에서 호스팅되든 상관없이 이를 구성하고 서버와 네트워크를 보호하는 동시에 누가 무엇에 액세스할 수 있는지 제어하기 위한 조치를 취해야 합니다. 이러한 방식으로 빌드 환경을 최적화하고 보호하기 위해 실사를 수행하면 소스 코드와 최종 제품의 무결성이 보장됩니다.
빌드 파이프라인 보안에는 제품 빌드 프로세스 중에 사용하는 모든 시스템 보안이 포함됩니다. 여기에는 코드 저장소, 서명 서버, 엔지니어링 워크스테이션, 배포 서버 등이 포함됩니다. 빌드 파이프라인 인프라를 보호하기 위해 취할 수 있는 몇 가지 조치는 다음과 같습니다.
시스템 잠금
시스템을 보호하려면 시스템 작동을 시스템이 수행해야 하는 특정 기능으로 제한해야 합니다. 예를 들어, 빌드 시스템은 빌드 작업에만 사용해야 하며 다른 용도로는 사용할 수 없습니다.
외부 및 LAN 외부 네트워크 활동 제한
인바운드 및 아웃바운드 네트워크 활동 모두 잠재적으로 시스템이 다음에 노출될 수 있습니다. 공격. 모든 외부 및 LAN 외부 활동을 차단하고 외부 연결을 필요한 URL로 제한해야 합니다.
데이터 유출에 대한 시스템 모니터링
제품 소스 코드의 무결성을 보장하려면 저장소, 워크스테이션 및 빌드 환경의 기타 부분을 데이터 유출 및 침입으로부터 보호하기 위한 사이버 보안 방어를 설정해야 합니다. 여기에는 모든 악의적인 행동을 차단하고, 앱을 격리하고, 침입이 발생하는 즉시 이를 포착할 수 있는 탐지 시스템을 설정하는 것이 포함됩니다.
버전 제어 파이프라인 구성
코드 파이프라인은 버전 제어되어야 합니다. 제품을 변경할 때 실제 시스템이 아닌 구성 코드를 업데이트해야 합니다.
다중 요소 인증
빌드 환경의 일부인 각 시스템은 가능한 한 다단계 인증으로 구성되어야 합니다. 역할 기반 액세스, 최소 권한 등과 같은 추가 보안 조치도 마련해야 합니다. NIST 지침에서는 또한 빌드 환경의 모든 중요하거나 민감한 시스템에 대해 이중 인증 시스템을 권장합니다.
엔지니어링 네트워크 분리
빌드 시스템은 조직의 나머지 네트워크와는 다른 격리된 엔지니어링 네트워크를 통해서만 액세스해야 합니다. 가능하다면 엔지니어링 네트워크는 오프라인 상태여야 합니다.
각 취약점을 분석하여 해결 계획을 세우는 데 충분한 정보를 수집합니다.
소프트웨어를 개발할 때 제품과 모든 구성 요소에 알려진 고위험 취약점이 없는지 확인하기 위한 조치를 취해야 합니다. 마찬가지로 고객이 새로운 취약점을 발견하거나 보고한 경우 즉시 사건에 대응해야 합니다. 어떤 경우에는 새로 발견된 취약점과 관련된 위험을 완화하기 위해 시스템을 업데이트해야 합니다.
소프트웨어 공급업체는 타사 연구원이나 고객으로부터 자사 제품의 잠재적인 취약점이나 결함에 대한 업데이트나 보고를 수용할 수 있는 프로세스를 갖추고 있어야 합니다. 또한 CISA(사이버 보안 및 인프라 보안 기관)와 같은 신뢰할 수 있는 조직에서 발표한 취약성 업데이트에 대해 알려주는 자동화된 시스템이 필요합니다.
모든 조직에는 표준 지침을 준수하는 내부 취약성 관리 정책이 필요합니다. 고위험 위협에 대한 경고는 보고된 취약점의 영향을 받았을 수 있는 제품과 해당 구성 요소 간의 관계를 기반으로 평가되어야 합니다. 엔지니어링 팀은 또한 문제를 검토, 진단 및 해결하기 위한 포괄적인 시스템을 갖추고 있어야 합니다.
구성 요소 유지 관리
소프트웨어 제품과 그 구성 요소는 결코 정적이지 않습니다. 귀하의 제품에 통합된 제3자 구성요소는 공급자에 의해 정기적으로 수정되거나 업데이트될 수 있다는 점을 명심해야 합니다. 특히 CVE(Common Vulnerability and Exposures)와 관련된 경우 이러한 수정 사항을 모니터링해야 합니다.
소프트웨어 구성 요소를 유지 관리하는 데 있어 가장 큰 부분은 표준 CVE 보고 메커니즘 및 기타 지원 채널을 모니터링하여 제품에 통합된 타사 구성 요소에서 새로 식별된 취약성이 자체 시스템의 무결성에 영향을 미치는지 확인하고 위험을 완화하기 위한 적절한 조치를 취하는 것입니다( 만약에 어떠한).
제품에 포함할 타사 구성 요소를 선택할 때 구성 요소 소유자가 제품 조직에 시스템 업데이트, 취약점 존재 및 취약점 기간에 대해 알리는 방법에 대한 정책이 있는지 확인하기 위해 계약을 확인해야 합니다. 최적의 보안을 보장하기 위해 사용자 측에서 수행해야 할 수 있는 모든 작업과 해결 방법을 제공합니다.