소프트웨어 공급망 보안은 '소프트웨어 공장'의 발견 및 거버넌스부터 시작됩니다.
오늘날의 소프트웨어 개발 환경에서 팀은 코드 저장소, 빌드 파이프라인, 컨테이너 이미지와 같은 분산된 자산을 처리합니다. 이 분산 모델은 유연성을 제공하고 프로덕션 속도를 높이지만, 특히 클라우드 네이티브 애플리케이션이 더 널리 퍼지면서 자산을 분산시키고 거버넌스와 보안 감독을 복잡하게 만듭니다.
그 결과, 보안팀은 보안 문제가 발생하거나 승인되지 않은 소프트웨어 아티팩트가 프로덕션으로 유입될 때 고아 프로덕션 워크로드에 대한 코드 소유자를 추적하는 데 귀중한 시간을 허비하는 경우가 많습니다. 소프트웨어 공급망은 중요한 공격 표면이 되었으며, 사각 지대를 피하고 소프트웨어 개발 수명 주기(SDLC) 전반의 모든 자산을 모니터링하기 위해 개발에서 빌드 단계까지 보안 신호를 일찍 수집하는 것이 필수적입니다.
DevSecOps 팀은 일반적으로 새로운 코드 경로와 도구가 자주 도입되는 이 변화하는 개발 환경을 지속적으로 매핑할 자동화된 도구가 부족합니다. 정보는 종종 다양한 플랫폼에 분산되어 있어 보안 목적으로 액세스하기 어렵습니다. 개발 플랫폼과 도구는 소프트웨어가 단계를 거쳐 홍보됨에 따라 개발, 통합 및 배포에 따라 종종 다릅니다.
ASPM(애플리케이션 보안 포스처 관리) 및 관찰성 공급업체가 보안 검사를 집계하는 반면, 코드 경로를 프로덕션에 연결하는 전체적인 뷰를 제공하지 못하는 경우가 많습니다.
오래된 자산의 존재는 문제를 더욱 복잡하게 만듭니다. 어떤 리포지토리가 여전히 프로덕션에서 활성화되어 있는지 파악하는 것은 특히 대규모 조직의 경우 압도적일 수 있습니다. 합병 및 인수는 다양한 플랫폼과 개발 표준을 추가하여 이를 더욱 복잡하게 만듭니다.
DevSecOps 팀은 종종 매니페스트 작성이나 컨테이너 라벨링과 같은 수동 프로세스를 사용하는데, 이는 지루하고 오류가 발생하기 쉬우며, 더 시급한 우선순위를 위해 종종 제쳐두곤 합니다.
보안팀이 자산을 보호하기 위해 정확한 지도가 필요한 끊임없이 변화하는 전장을 방어하는 것과 같다고 생각해보세요. 이러한 자산은 항상 개발 중에 움직이고 있으며, 새로운 대상을 식별하여 보호해야 합니다. 이를 해결하려면 변화가 발생하는 대로 지도화하는 지속적인 발견 메커니즘이 필요합니다.
모범 사례와 프레임워크는 이 접근 방식을 지원합니다. 예를 들어, 사이버 보안 및 인프라 보안 기관 (CISA) 조직이 소프트웨어 구성 요소의 출처를 확인하고 포괄적인 인벤토리를 유지 관리하도록 요구합니다. 자기 증명 프로세스. 유사하게, NIST 보안 소프트웨어 개발 프레임워크(SSDF) 그리고 OWASP DevSecOps 성숙도 모델(DSOMM) 지속적인 발견과 가시성의 중요성을 강조합니다.
이 글의 나머지 부분에서는 이러한 과제를 해결하기 위한 청사진을 개략적으로 살펴보고 Scribe Security가 조직이 이러한 기능을 효과적으로 구현하는 데 어떻게 도움이 되는지 살펴보겠습니다.
효과적인 발견을 위한 서기관의 청사진
Discovery는 그래프로 모델링된 맵을 생성하여 자산, 관계 및 공장의 보안 태세를 볼 수 있도록 합니다. 이를 통해 다음을 수행할 수 있습니다.
- 완벽한 가시성과 소유권 통제.
- 향상된 쿼리 기능.
- KPI 및 보안 성숙도 측정 항목 모니터링.
- 위험 요소를 더 빨리 식별하고 우선순위를 지정합니다.
- 초기 스캔
초기 검사는 추가 분석이 필요한 자산을 식별하는 데 중점을 두고 자산의 상위 수준 맵을 만드는 것을 목표로 합니다. 전체 심층 검사는 시간이 많이 걸릴 수 있으며, 프로덕션에 연결되지 않았거나 폐기된 자산과 같은 많은 자산은 관련이 없을 수 있습니다. 이 초기 검사는 일반적으로 리포지토리 이름, ID 및 활동 통계와 같은 기본 세부 정보를 수집하지만 커밋 또는 기여자의 전체 목록은 포함하지 않습니다.
한 가지 방법은 "오른쪽에서 왼쪽으로" 스캔하는 것입니다. 프로덕션 환경에 액세스하면(예: K8s 클러스터 API를 통해) 스캐너는 실행 중인 컨테이너 이미지, 즉 비즈니스 가치를 반영하는 중요한 자산을 식별할 수 있습니다. 거기에서 스캔은 컨테이너 레지스트리와 관련 저장소로 추적합니다. 스캔은 일반적으로 레지스트리와 이전 SDLC 파이프라인 사이에 직접적인 연결이 없기 때문에 여기서 중지됩니다.
보완적인 스캔은 "왼쪽에서 오른쪽으로" 실행하여 다양한 SDLC 단계(예: 개발, 통합, 테스트)에 걸쳐 코드 저장소, 빌드 파이프라인 및 레지스트리를 식별할 수 있습니다.
결과는 플랫폼 전반에 걸친 자산의 우선순위가 매겨진 목록으로, 코드에서 프로덕션까지의 계보를 추적하고 SDLC의 보안 태세를 평가하기 위한 심층 스캐닝을 위해 준비됩니다. 우선순위는 프로덕션과의 관련성, 활동 수준 및 최근성과 같은 요인을 기반으로 합니다. 때때로 자산 중요성에 대한 기관의 지식이 이 프로세스를 안내하는 데 도움이 됩니다.
초기 스캔은 주기적으로 예약하거나 코드 푸시와 같은 이벤트에 의해 트리거될 수 있습니다. 후속 스캔은 새로 발견된 자산을 심층 스캔하기 위해 글로브를 사용하는 것과 같은 자동 선택 기준을 적용할 수 있습니다.
- 면밀히 살펴보다
관련 자산이 우선순위가 지정되면 심층 스캔은 브랜치 ID, 커밋 및 커미터 ID, 파이프라인 실행 ID와 같이 자산 간의 관계를 설정하는 자세한 속성을 수집합니다. 이 스캔의 기간은 자산의 범위와 API 속도 제한에 따라 달라질 수 있습니다.
이 단계가 끝나면 자산 관계 그래프가 형성되기 시작하며, 코드 저장소(빌드 정보 포함)와 런타임 환경(레지스트리 자산 포함)을 중심으로 연결된 자산 클러스터가 형성됩니다. 그러나 레지스트리는 일반적으로 빌드 아티팩트를 푸시한 파이프라인에 대한 정보를 저장하지 않으므로 완전한 계보는 아직 완료되지 않았습니다.
- 클러스터 연결
인벤토리가 확립되면 파이프라인에서 CLI 도구를 계측하여 빌드 출처 세부 정보를 캡처하거나 CI 로그를 처리하여 계보를 완료할 수 있습니다. 계측은 코드 저장소 ID, 파이프라인 및 실행 ID, 이미지 ID와 같은 주요 속성을 기록하는 가장 신뢰할 수 있는 방법입니다. 이전에 격리된 클러스터를 효과적으로 연결하고 코드에서 프로덕션까지 완전한 엔드투엔드 계보를 만듭니다.
보완적인 접근 방식은 CI 로그 처리로, 관련 속성을 검색하지만 더 많은 리소스가 필요하고 기존 로깅에 의존합니다. 이 방법은 더 빠른 구현을 제공하지만 두 가지 접근 방식을 결합하면 중요한 파이프라인을 계측하고 새로 발견된 파이프라인에 로그 분석을 사용하여 추가 계측을 위해 평가할 수 있는 최상의 결과를 얻을 수 있습니다.
이러한 클러스터링 접근 방식은 여러 구성 요소로 구성된 웹 애플리케이션(예: 마이크로서비스)과 같은 복잡한 제품에 대해 별도의 계보를 통합된 구조로 집계하는 것도 고려합니다.
- 소프트웨어 재료 명세서 (SBOM)
지금까지는 플랫폼 간에 개발 자산을 연결하여 관련 자산에 대한 코드에서 프로덕션까지의 명확한 계보를 확립하는 데 중점을 두었습니다. 이제 소프트웨어 아티팩트 자체의 구성으로 주의를 돌립니다. 이 단계에서는 해당 아티팩트와 관련 코드 저장소에서 SBOM을 생성하여 기존 인벤토리에 추가합니다.
코드 저장소와 아티팩트 SBOM을 단일 SBOM으로 합성하고 종속성을 상관관계로 연결하고 개발 및 테스트 라이브러리와 같은 관련 없는 라이브러리를 제외하는 논리를 적용하면, 두 소스가 단독으로 제공할 수 있는 것보다 더 정확하고 포괄적인 SBOM이 생성됩니다.
- 보안 포스처 및 DevSecOPs KPI
자산 인벤토리와 그 관계를 지속적으로 매핑하면 이러한 자산의 보안 태세를 평가할 수 있는 최상의 기회가 제공됩니다. 주요 요소로는 인간 및 비인간 신원에 대한 액세스 권한, 코드 서명 검증, 위험하거나 취약한 종속성, 다양한 플랫폼 및 계정의 보안 설정이 있습니다.
이 데이터는 제품 출시, 프로덕션 배포 시간, DevSecOps 성숙도에 대한 KPI를 측정하기 위해 다양한 차원으로 집계될 수 있습니다. 구체적으로, 이를 통해 팀은 코드 서명 및 보안 설정 준수와 같은 보안 제어 도입을 평가하여 진행 상황을 추적하고 강력한 보안 관행을 보장하는 데 도움이 됩니다.
- SDLC 및 소프트웨어 공급망 그래프의 시각화 및 쿼리
발견 프로세스의 주요 이점 중 하나는 SDLC와 소프트웨어 공급망을 동적 그래프 또는 "전투 지도"로 시각화할 수 있는 기능입니다. 이 시각화는 전체 개발 라이프사이클에 대한 포괄적인 뷰를 제공하여 자산과 그 관계를 더 쉽게 추적할 수 있습니다.
진정한 힘은 그래프를 쿼리하는 기능에서 나오며, 이를 통해 팀은 다음과 같은 중요한 질문을 할 수 있습니다.
- "빌드 또는 배포 중에 보안 검사에 실패한 구성 요소는 무엇입니까?"
- “생산 중 어떤 워크로드가 고아가 되었습니까?”
- "취약성을 도입한 변경을 저지른 사람은 누구입니까?"
- "패치가 필요한 자산을 소유한 사람은 누구입니까?"
계보를 쿼리하면 팀이 문제의 근본 원인을 파악하는 데 도움이 되며, 이는 수동 문서화보다 분명한 이점입니다. 수동으로 유지 관리되는 소유권 매핑은 빠르게 오래되어 DevSecOps 팀이 적절한 이해 관계자를 비효율적으로 검색하게 됩니다. 반면 쿼리 가능한 그래프는 소유권과 책임이 항상 최신 상태인지 확인하여 코드나 인프라에 대한 책임을 추적하는 데 낭비되는 시간을 줄여줍니다.
- Discovery Tools에 대한 배포 옵션
조직은 발견 도구를 배포하는 데 다양한 요구 사항을 가지고 있으며, 유연한 배포 옵션을 제공하는 것은 다양한 보안 요구 사항을 충족하는 데 필수적입니다. 일부 팀은 SaaS 플랫폼을 통한 원격 액세스를 선호하여 관리와 확장을 간소화합니다. 반면, 보안 프로토콜이 더 엄격한 팀은 개발 플랫폼 API 토큰과 같은 민감한 자격 증명에 대한 엄격한 제어를 유지하기 위해 로컬 스캐너 배포를 선택할 수 있습니다. SaaS와 로컬 배포 간의 선택은 조직의 보안 태세, 규정 준수 요구 사항 및 데이터 제어와 같은 요인에 따라 달라집니다.
결론
소프트웨어 공급망 보안은 지속적인 전투입니다. 어떤 조직도 명확한 지도 없이 이 전투에 참여해서는 안 됩니다. 강력한 발견 프로세스를 구현하면 SDLC와 공급망 전반에 대한 포괄적인 가시성을 확보하여 개발에서 프로덕션에 이르기까지 모든 자산이 설명되도록 할 수 있습니다. Scribe Security의 청사진과 같은 도구를 사용하면 연결된 계보를 구축하고 정확한 SBOM을 생성하고 보안 태세를 평가하고 개발 생태계 내의 중요한 관계를 시각화할 수 있습니다. 이러한 수준의 통찰력을 통해 DevSecOps 팀은 취약성을 신속하게 식별하고, 출처를 추적하고, 소프트웨어 환경에 대한 최신 이해를 유지할 수 있습니다. 이는 오늘날의 빠르게 변화하는 복잡한 개발 환경에서 앞서 나가는 데 필수적입니다.
학자 소프트웨어 공급망 보안을 위한 중요한 지원 도구로서 Discovery 및 거버넌스에 대한 포괄적인 솔루션을 제공합니다.
- 초기 및 심층 스캔 – 환경 전반에서 코드 저장소, 파이프라인, 컨테이너 이미지와 같은 자산을 식별하고 우선순위를 지정하여 관련 구성 요소의 인벤토리를 구축합니다.
- 종단 간 계보 – CLI 도구와 CI 로그를 사용하여 분리된 자산 클러스터를 연결하고 코드에서 프로덕션까지 완전한 계보를 형성합니다.
- 소프트웨어 재료 명세서 (SBOM) – 관련 없는 종속성을 제외하고 아티팩트 및 저장소 데이터를 합성하여 정확한 SBOM을 생성합니다.
- 보안 태세 평가 – 보안 KPI를 측정하기 위해 액세스 제어, 코드 서명 및 취약한 종속성을 지속적으로 평가합니다.
- 시각화 및 쿼리 – SDLC 전체를 시각화하고 취약점, 고아 워크로드 및 자산 소유권을 추적하는 쿼리를 활성화합니다.
- 유연한 배포 – 다양한 보안 요구 사항을 충족하고 민감한 데이터를 제어하기 위해 SaaS와 로컬 배포를 모두 지원합니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
