지속적인 보증: 소프트웨어 공급망 보안을 위한 통합 사례

이 새로운 NIST SP 800-218 지침을 검토하는 일련의 기사 중 두 번째입니다. 첫 번째 기사를 찾을 수 있습니다 LINK.

지속적인 보증:
소프트웨어 공급망 보안을 위한 통합 사례

이전 기사에서 논의한 것처럼 미국 국립표준기술연구소(NIST)가 수립한 지침은 소프트웨어 제품과 서비스가 미국 정부에 공급되는 방식을 극적으로 변화시킬 것입니다. 

특히, NIST SP 800-218 모든 SDLC(소프트웨어 개발 수명 주기)에 통합될 일련의 높은 수준의 보안 소프트웨어 개발 방식을 확립합니다. 소프트웨어 공급망 전반에 걸쳐 이러한 관행을 통합하면 미국 정부뿐만 아니라 궁극적으로 산업 전반과 전 세계에 보다 안전한 제품과 서비스를 제공할 수 있을 것으로 예상됩니다. 

이 기사에서는 이러한 새로운 요구 사항을 충족하는 데 있어 CA(지속적 보증)의 중요한 역할을 살펴봅니다. 

개요: 지속적인 보증이란 무엇이며 어떻게 작동합니까? 

CA는 DevOps 분야의 이미 친숙한 지속적인 통합, 개발 및 테스트 개념을 보완하는 개념이자 제작 중인 솔루션 세트입니다. CA는 최종 소프트웨어 제품의 보안에 영향을 미칠 수 있는 제품 빌드 및 배포를 포함하여 개발 수명 주기의 모든 이벤트에 대한 증거를 세부적으로 수집합니다. 이는 소프트웨어 소비자(예: 사용자, 구매자 및 기타 위험 이해관계자)가 사용하는 제품의 위험을 통제할 수 있는 수단입니다. 

오늘날 기업에서는 개발하는 소프트웨어 제품의 보안을 강화하기 위해 수많은 보안 도구를 적용합니다. 그러나 이러한 도구의 일관된 사용을 위한 표준을 설정하기 위해 전반적인 정책을 거의 사용하지 않습니다. 더욱이 소프트웨어 제품의 소비자가 다른 조직 출신인 경우 위험 기준을 설정하는 데 필요한 정보나 도구가 전혀 없습니다. 간단히 말해서, 이는 CA가 해소하려는 소프트웨어 공급망의 사각지대입니다. 

CA의 즉각적인 결과는 소프트웨어 제품이 변조되지 않았음을 확인하고 개발 중에 중요한 보안 관련 테스트가 수행되었음을 보장하는 수단이지만, 이를 통해 더 많은 것을 얻을 수 있습니다.

금지된 국가와 같이 의심스러운 출처의 내부 구성 요소에 대한 공격자의 변조 또는 공급업체의 은폐를 방지하기 위해 CA는 정보에 암호화 방식으로 서명하고 이를 변경할 수 없는 저장소에 저장하여 수집된 증거를 변조 방지 증명으로 전환합니다. 격리된 보안 환경. 

수집된 증거를 기계가 읽을 수 있도록 함으로써 정책 엔진은 모든 제품 버전이나 업데이트에 대해 위험 이해관계자가 설정한 규범이나 규칙을 지속적으로 검증할 수 있습니다. 이러한 방식으로 이해관계자는 제품이 보안 표준을 준수하는지 확신할 수 있습니다. 

개념적으로 CA 방법론을 사용하면 제품 품질도 향상됩니다. 특정 제품의 파이프라인에 대한 중앙 정책을 통해 코드 검토 및 보안 테스트에 대한 기본 표준을 제어함으로써 정돈된 프로세스에 대한 불일치 및 임시 변경이 제거됩니다.

왜 지속적인가?

개발 프로세스의 보안 구성은 새로운 것이 아닙니다. 예를 들어 취약점 스캔 없이는 바이너리가 프로덕션으로 이동하지 않는다는 것을 이미 설정했을 수 있습니다. 

오늘날 소프트웨어 제공 주기는 점점 더 짧아지고 있습니다. 결과적으로 모서리가 잘릴 수 있습니다. 코드 검토를 건너뛰거나 보안 테스트 또는 중요한 절차가 수행되지 않을 수 있습니다. 또한 새로운 CVE 및 익스플로잇이 항상 보고되고 새로운 구성 요소 버전이 지속적으로 게시됩니다. 

이러한 모든 요소가 결합되어 설정된 보안 표준에 대해 구성 요소를 지속적으로 테스트하여 사용되는 프로세스가 여전히 보안 정책을 준수하는지 확인해야 합니다. 

보안 정책은 위험 보유자에 의해 결정됩니다. 다음은 채택될 수 있는 정책 규칙의 몇 가지 예입니다. 

• 승인된 목록에서만 오픈 소스 패키지 사용을 허용합니다.
• 모든 끌어오기 요청에는 두 명의 검토자가 필요합니다.
• 최종 아티팩트의 모든 독점 구성요소가 소스 제어 저장소로 역추적될 수 있는지 확인하십시오.

소프트웨어 보안 기준 높이기

소프트웨어 공급망 공격은 소프트웨어 구성 요소의 예상 동작을 변경합니다. 오늘날 이러한 공격은 소프트웨어 소비자와 생산자의 소프트웨어 구성 요소 무결성 확인 능력이 부족하기 때문에 발생합니다. 

그러나 오픈 소스 종속성부터 최종 제품까지 개발 수명 주기의 모든 부분에서 증거에 서명하고 이 증거를 예상되는 것과 지속적으로 비교함으로써 공격자는 파일, 도구 또는 CI/CD 파이프라인의 예상 동작.     

증거 수집: 예시 및 권장사항

다음은 SDLC를 통해 수집할 수 있는 증거의 몇 가지 예입니다.

그리고 이 증거를 사용하여 활용할 수 있는 정책 유형은 다음과 같습니다.

지속적인 코드 보증의 미래

2022년 XNUMX월 보안 소프트웨어 개발 프레임워크(SSDF), NIST는 개발 프로세스 전반에 걸친 보안 도구 구현이 자동화에 크게 의존해야 한다고 제안합니다. 지속적인 보증에 대한 우리의 접근 방식은 이 권장 사항과 일치합니다. 

모든 보안 단계와 보호 장치가 올바르게 구성되었다고 확신하더라도 보안 정책이 일관되고 지속적으로 시행되었음을 고객과 공급업체에게 확신시킬 수 있는 수단을 제공해야 합니다. 모든 이해관계자, 소프트웨어 생산자(개발자 또는 공급업체) 및 소비자(사용자 또는 구매자)는 소프트웨어 공급망의 각 링크에서 나오는 증거를 지속적으로 자동으로 검사하고 검증하여 자체 보안 기준이 충족되는지 확인할 수 있어야 합니다. 

현재 소프트웨어 공급망에 대한 신뢰도는 낮으며 이는 모든 이해관계자들의 끊임없는 걱정거리입니다. 구현된 보안 조치에 대한 가시성을 높이고 지속적인 코드 보증의 증거를 제공하는 것은 소프트웨어 공급망에 대한 신뢰를 재구축하고 검증 가능하게 더욱 안전한 제품을 생산하는 데 필수적입니다.