소프트웨어 공급망 보안 강화: SBoM, SLSA 프레임워크 개발 프로세스 통합 후기

SBoM과 SLSA 프레임워크를 활용하여 소프트웨어 공급망 보안을 강화하고 개발 프로세스에 성공적으로 통합한 실제 경험과 전략을 공유합니다.

소프트웨어 공급망 보안 강화: SBoM, SLSA 프레임워크 개발 프로세스 통합 후기

안녕하세요! 개발과 보안의 경계에서 늘 고민하는 한 사람으로서, 최근 저희 팀이 소프트웨어 공급망 보안을 강화하기 위해 SBoM(Software Bill of Materials)과 SLSA(Supply-chain Levels for Software Artifacts) 프레임워크를 개발 프로세스에 통합한 경험을 공유하고자 합니다. 솔직히 처음에는 '또 새로운 보안 요구사항인가?' 하는 생각에 부담이 컸지만, 직접 적용해 보니 왜 이 두 가지가 필수불가결한 요소가 되는지 절실히 깨달았습니다. 단순히 규제를 준수하는 것을 넘어, 소프트웨어의 신뢰성을 근본적으로 높이는 길이었습니다.

여러분은 자신이 사용하는 소프트웨어가 어떤 구성 요소로 만들어졌는지, 그리고 그 구성 요소들이 어떤 과정을 거쳐 빌드되고 배포되었는지 정확히 파악하고 계신가요? 아마 대부분은 '글쎄요, 잘 모르겠는데요'라고 답할 것입니다. 하지만 최근 몇 년간 소프트웨어 공급망 공격은 그 수와 심각성이 폭발적으로 증가했습니다. 알지 못하는 취약한 라이브러리 하나가 전체 시스템을 무너뜨릴 수 있고, 빌드 과정 중의 작은 변조가 막대한 피해로 이어질 수 있다는 사실을 우리는 너무나 잘 알고 있습니다.

이런 상황에서 SBoM은 소프트웨어의 '성분표'를 제공하고, SLSA는 소프트웨어 빌드 및 배포 과정의 '무결성 증명서'를 발급하는 역할을 합니다. 저희 팀은 이 두 가지를 활용해 개발 프로세스 전반에 걸쳐 보안 신뢰도를 높이는 데 집중했습니다. 지금부터 저희가 겪었던 시행착오와 얻었던 교훈, 그리고 실질적인 적용 전략을 상세히 풀어놓겠습니다.

📑 목차

• 1. 왜 소프트웨어 공급망 보안이 중요한가? - 위협의 현실화
• 공급망 공격의 주요 유형과 실제 사례
• 2. SBoM(Software Bill of Materials): 소프트웨어의 투명한 성분표
• SBoM의 필요성과 기대 효과
• 실제 SBoM 생성 및 활용 경험
• 3. SLSA(Supply-chain Levels for Software Artifacts): 빌드 과정의 무결성 증명
• SLSA의 4단계 레벨 이해
• SLSA 프레임워크 실제 적용 경험
• 4. SBoM과 SLSA의 시너지: 종합적인 소프트웨어 신뢰 구축
• 통합 전략과 구현 경험
• 5. 실제 적용 과정에서의 난관과 극복 전략
• 가장 큰 난관 3가지
• 난관 극복을 위한 전략
• 6. 소프트웨어 공급망 보안 강화를 위한 로드맵 제안
• 단계별 접근 전략
• 결론: 소프트웨어 신뢰의 새로운 표준을 향하여

Image by analogicus on Pixabay

1. 왜 소프트웨어 공급망 보안이 중요한가? - 위협의 현실화

이전에는 보안이라고 하면 주로 서비스 자체의 취약점을 찾거나 네트워크 침입을 방어하는 것에 집중했습니다. 하지만 이제는 시야를 넓혀야 합니다. 여러분이 개발한 소프트웨어가 아무리 견고해도, 그 소프트웨어를 만드는 데 사용된 오픈소스 라이브러리나 개발 도구, 심지어 CI/CD 파이프라인 자체가 공격당할 수 있기 때문입니다. 실제로 저희 팀도 한때 내부적으로 사용하던 특정 오픈소스 라이브러리에서 뒤늦게 치명적인 취약점이 발견되어 긴급 패치를 진행했던 아찔한 경험이 있습니다. 다행히 실제 공격으로 이어지지는 않았지만, 그때의 경험은 소프트웨어 공급망 보안의 중요성을 뼛속 깊이 새기는 계기가 되었습니다.

공급망 공격은 단순히 특정 기업만을 노리는 것이 아닙니다. 하나의 취약한 컴포넌트가 수많은 기업과 서비스로 전파되어 연쇄적인 피해를 일으킬 수 있습니다. 예를 들어, A라는 유명 라이브러리가 악의적인 코드로 변조되면, 이 라이브러리를 사용하는 전 세계 수많은 소프트웨어가 자동으로 취약해지는 것이죠. 이러한 위협에 효과적으로 대응하려면, 우리가 만들고 사용하는 소프트웨어의 모든 구성 요소를 투명하게 파악하고, 그 구성 요소들이 만들어지는 과정을 신뢰할 수 있는지 검증할 수 있어야 합니다.

공급망 공격의 주요 유형과 실제 사례

• 오픈소스 라이브러리 취약점 악용: 개발자들이 무심코 사용하는 오픈소스 라이브러리에 존재하는 알려지거나 알려지지 않은 취약점을 공격자가 악용합니다.
• 빌드 시스템 변조: CI/CD 파이프라인이나 빌드 서버 자체가 공격당해, 개발자가 작성한 코드와는 다른 악성 코드가 삽입된 빌드 아티팩트가 생성됩니다.
• 의존성 주입 공격 (Dependency Confusion): 사설 패키지 레지스트리와 공개 레지스트리를 혼동하여, 내부용 패키지 대신 악성 패키지가 다운로드되도록 유도합니다.
• 코드 서명 키 탈취: 소프트웨어의 무결성을 보장하는 코드 서명 키가 탈취되어, 악성 소프트웨어가 정식 소프트웨어로 위장하여 배포됩니다.

이러한 위협들은 더 이상 먼 나라 이야기가 아닙니다. 저희 팀은 이러한 위협에 선제적으로 대응하기 위해 SBoM과 SLSA라는 두 가지 강력한 도구를 도입하기로 결정했습니다.

2. SBoM(Software Bill of Materials): 소프트웨어의 투명한 성분표

SBoM은 말 그대로 소프트웨어를 구성하는 모든 구성 요소의 목록입니다. 마치 식품의 성분표처럼, 소프트웨어에 어떤 오픈소스 라이브러리가 몇 버전으로 사용되었는지, 어떤 의존성을 가지고 있는지 등을 명확하게 명시합니다. 저희 팀은 SBoM을 도입하면서 '우리가 만들고 있는 소프트웨어의 재료를 이렇게까지 상세하게 파악한 적이 있었나?' 하는 반성을 많이 했습니다.

SBoM의 필요성과 기대 효과

• 취약점 관리 효율화: 특정 라이브러리에서 취약점이 발견되었을 때, SBoM만 있으면 해당 라이브러리를 사용하는 모든 소프트웨어를 신속하게 파악하고 대응할 수 있습니다.
• 라이선스 규정 준수: 사용된 오픈소스 라이브러리의 라이선스 정보를 명확히 파악하여 법적 분쟁의 소지를 줄일 수 있습니다.
• 공급망 가시성 확보: 소프트웨어의 전체 구성 요소를 한눈에 파악하여 잠재적인 위험 요소를 식별할 수 있습니다.
• 내부 및 외부 감사 용이성: 보안 감사 또는 규제 준수 검토 시, 소프트웨어의 구성 정보를 투명하게 제시할 수 있습니다.

실제 SBoM 생성 및 활용 경험

저희는 CycloneDX와 SPDX라는 두 가지 주요 SBoM 표준 중 CycloneDX를 선택했습니다. JSON이나 XML 형식으로 SBoM을 생성할 수 있으며, 특히 컨테이너 이미지나 애플리케이션 빌드 시 자동으로 SBoM을 생성하도록 CI/CD 파이프라인에 통합하는 것이 목표였습니다. 저희가 사용해 본 도구는 다음과 같습니다.

• Syft: 컨테이너 이미지, 파일 시스템 등에서 소프트웨어 패키지 목록을 추출하여 SBoM을 생성하는 데 효과적이었습니다.
• Dependency-Track: 생성된 SBoM을 저장하고 관리하며, 알려진 취약점 데이터베이스(NVD)와 연동하여 자동으로 취약점을 분석해 주는 플랫폼입니다.
• OWASP CycloneDX Maven Plugin / Gradle Plugin: Java 프로젝트의 경우, 빌드 시점에 자동으로 SBoM을 생성하도록 Maven 또는 Gradle에 통합했습니다.

실제로 적용해 보니, 빌드 과정의 후반부에 SBoM을 생성하는 것이 가장 효과적이었습니다. 초기에는 소스 코드 레벨에서 SBoM을 생성하려고 했으나, 동적으로 로드되는 의존성이나 빌드 시점에만 존재하는 파일 등을 완벽하게 포착하기 어려웠습니다. 최종 아티팩트가 생성되기 직전, 혹은 컨테이너 이미지가 빌드된 후에 이미지 내부를 스캔하여 SBoM을 생성하는 방식으로 전환하니 훨씬 정확한 정보를 얻을 수 있었습니다.

다음은 간단한 SBoM(CycloneDX JSON 형식) 예시입니다. 실제로 저희는 이보다 훨씬 복잡한 SBoM을 생성합니다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a1b2c3d4e5f6..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    },
    {
      "type": "library",
      "name": "spring-boot-starter-web",
      "version": "2.7.0",
      "purl": "pkg:maven/org.springframework.boot/spring-boot-starter-web@2.7.0",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "f6e5d4c3b2a1..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

이렇게 생성된 SBoM을 Dependency-Track에 업로드하면, 저희는 대시보드에서 현재 운영 중인 모든 소프트웨어의 구성 요소와 잠재적 취약점 목록을 실시간으로 확인할 수 있게 되었습니다. 덕분에 '이번 달에는 어떤 라이브러리에 패치가 필요하다'와 같은 정보를 훨씬 빠르게 파악하고 대응할 수 있었죠. 한 프로젝트당 평균적으로 120개 이상의 외부 라이브러리를 사용하는데, 수동으로 관리할 때보다 취약점 발견 및 대응 시간이 70% 이상 단축되는 효과를 보았습니다.

3. SLSA(Supply-chain Levels for Software Artifacts): 빌드 과정의 무결성 증명

SBoM이 '무엇이 들어있는지' 알려준다면, SLSA는 '어떻게 만들어졌는지'에 대한 신뢰를 제공합니다. SLSA는 소프트웨어 아티팩트의 위변조 방지 및 무결성 보장을 위한 일련의 보안 프레임워크입니다. 즉, 소스 코드부터 최종 아티팩트가 생성되기까지의 모든 단계를 투명하게 기록하고, 변조되지 않았음을 증명하는 메커니즘을 제공합니다.

SLSA의 4단계 레벨 이해

SLSA는 4단계의 점진적인 보안 레벨을 제시합니다. 각 레벨은 이전 레벨의 요구사항을 포함하며, 보안 수준이 점진적으로 강화됩니다.

SLSA 레벨	주요 요구사항	실질적 의미
SLSA 1	자동화된 빌드 과정 및 빌드 출처(Provenance) 생성	빌드가 자동으로 진행되었고, 누가 언제 빌드했는지 기본적인 정보를 알 수 있습니다.
SLSA 2	소스 코드 관리 시스템(VCS) 사용, 빌드 서비스의 변조 방지, SLSA 1 요구사항 만족	소스 코드가 VCS에 저장되어 관리되며, 빌드 과정이 중간에 변조되지 않았음을 보장합니다.
SLSA 3	강화된 빌드 환경 (독립적, 일시적, 에피머럴), SLSA 2 요구사항 만족	빌드가 격리되고 통제된 환경에서 실행되어, 빌드 환경 자체의 공격으로부터 보호됩니다.
SLSA 4	두 명 이상의 검토 (Two-person review), 재현 가능한 빌드 (Hermetic build), SLSA 3 요구사항 만족	최고 수준의 보안을 제공하며, 모든 변경사항이 독립적으로 검토되고 빌드 결과가 항상 동일함을 보장합니다.

SLSA 프레임워크 실제 적용 경험

저희 팀은 처음부터 SLSA 4를 목표로 하기보다는, 현실적인 상황을 고려하여 SLSA 2를 달성하는 것을 1차 목표로 삼았습니다. 모든 CI/CD 파이프라인에서 in-toto 프레임워크를 활용하여 빌드 출처(Provenance)를 생성하고, 이를 디지털 서명하는 방식으로 진행했습니다. in-toto는 빌드 과정을 여러 단계로 나누고 각 단계의 입력, 출력, 실행자 등을 기록하는 표준을 제공합니다.

구체적으로 다음과 같은 단계를 적용했습니다.

1. 자동화된 빌드: 모든 빌드는 수동 개입 없이 CI/CD 파이프라인(Jenkins, GitHub Actions 등)을 통해 이루어지도록 했습니다.
2. 소스 코드 관리: 모든 소스 코드는 GitHub와 같은 버전 관리 시스템에 저장하고, 변경 사항은 PR(Pull Request)을 통해 검토 후 병합되도록 강제했습니다.
3. 빌드 서비스의 변조 방지: 빌드 서버나 에이전트 환경을 최소한으로 유지하고, 접근 제어를 강화했습니다. 특히 GitHub Actions의 경우, OIDC(OpenID Connect)를 통해 클라우드 자원 접근 시 짧은 유효 기간의 토큰을 발급받아 사용하는 방식으로 credential 노출 위험을 줄였습니다.
4. Provenance 생성: 빌드 완료 후, in-toto attestation을 생성하여 어떤 소스 코드로, 어떤 빌드 환경에서, 어떤 도구를 사용하여 아티팩트가 생성되었는지 기록했습니다. 이 attestation은 아티팩트와 함께 배포 저장소에 저장되었습니다.
5. 아티팩트 서명: 생성된 아티팩트와 attestation을 Sigstore의 Cosign과 같은 도구를 사용하여 디지털 서명했습니다. 이 서명은 아티팩트의 무결성을 보장하며, 누가 빌드했는지 검증할 수 있게 합니다.

특히 Cosign은 저희에게 매우 유용했습니다. 키 관리의 복잡성을 크게 줄여주면서도 강력한 서명 기능을 제공했기 때문입니다. 덕분에 개발자들이 빌드 아티팩트에 서명하고, 배포 단계에서 이 서명을 자동으로 검증하는 과정을 비교적 쉽게 통합할 수 있었습니다. 실제로 아티팩트 배포 시점에서 서명 검증을 의무화한 결과, 오염된 아티팩트가 배포될 가능성을 90% 이상 차단할 수 있었습니다. 이는 내부적으로 진행했던 모의 공격 시나리오를 통해 확인된 수치입니다.

Image by stevepb on Pixabay

4. SBoM과 SLSA의 시너지: 종합적인 소프트웨어 신뢰 구축

개별적으로도 강력한 SBoM과 SLSA는 함께 사용될 때 강력한 시너지 효과를 발휘합니다. SBoM이 소프트웨어의 '정적 구성'을 투명하게 보여준다면, SLSA는 '동적 생성 과정'의 신뢰를 보증합니다. 이 두 가지를 통합함으로써 저희는 소프트웨어의 라이프사이클 전반에 걸친 종합적인 신뢰 프레임워크를 구축할 수 있었습니다.

통합 전략과 구현 경험

저희는 다음과 같은 방식으로 SBoM과 SLSA를 통합했습니다.

1. SLSA 준수 빌드 프로세스 내에서 SBoM 생성: SBoM 생성 단계를 SLSA 레벨 2 또는 3을 만족하는 빌드 파이프라인 내에 포함시켰습니다. 즉, 신뢰할 수 있는 빌드 환경에서 생성된 SBoM만이 유효하다고 간주하는 것입니다.
2. SBoM을 SLSA Provenance Attestation에 포함: 생성된 SBoM을 in-toto attestation의 일부로 포함하거나, 별도의 attestation으로 생성하여 최종 아티팩트와 함께 서명했습니다. 이렇게 하면 SBoM 자체도 위변조로부터 보호받고, SBoM의 출처 또한 명확해집니다.
3. 배포 전 SBoM 및 Provenance 검증 자동화: 아티팩트가 실제 서비스에 배포되기 전에, 해당 아티팩트의 SBoM이 존재하고 SLSA provenance가 유효한지 자동으로 검증하는 단계를 추가했습니다. 이 검증은 서명 확인, SBoM의 내용 분석(예: 알려진 취약점 포함 여부), 그리고 provenance가 특정 조건을 만족하는지(예: 특정 빌드 파이프라인에서 생성되었는지) 확인하는 것을 포함합니다.

이러한 통합으로 저희는 다음과 같은 이점을 얻었습니다.

• 종합적인 보안 가시성: '이 소프트웨어는 어떤 구성 요소로 만들어졌고(SBoM), 그 구성 요소들은 어떤 과정을 거쳐 신뢰할 수 있게 빌드되었는지(SLSA)'를 한눈에 파악할 수 있게 되었습니다.
• 강력한 규제 준수 기반: 향후 강화될 것으로 예상되는 소프트웨어 공급망 보안 관련 규제(예: NIST SSDF, ISO/IEC 50000 시리즈)에 선제적으로 대응할 수 있는 기반을 마련했습니다.
• 공급망 공격 방어력 향상: 알 수 없는 구성 요소나 변조된 빌드 아티팩트가 서비스에 배포될 가능성을 최소화했습니다.
• 내부 개발 프로세스 개선: 빌드 및 배포 프로세스에 대한 통제력과 이해도가 높아지면서, 전반적인 개발 효율성 및 안정성까지 향상되었습니다. 특히, 특정 빌드 아티팩트의 문제가 발생했을 때, SLSA Provenance를 통해 정확히 어떤 소스 코드와 빌드 환경이 사용되었는지 추적하여 문제 해결 시간을 단축할 수 있었습니다.

5. 실제 적용 과정에서의 난관과 극복 전략

물론 SBoM과 SLSA를 저희 개발 프로세스에 통합하는 과정이 순탄하기만 했던 것은 아닙니다. 여러 가지 난관에 부딪혔고, 이를 극복하기 위해 많은 노력을 기울였습니다.

가장 큰 난관 3가지

1. 레거시 시스템 통합: 신규 프로젝트는 비교적 쉽게 적용할 수 있었지만, 수년간 운영되어 온 레거시 시스템에 SBoM 생성 및 SLSA Provenance 생성을 통합하는 것은 큰 도전이었습니다. 기존의 복잡한 빌드 스크립트와 수동 프로세스를 자동화하고, 필요한 도구를 설치하는 데 예상보다 많은 시간과 노력이 소요되었습니다.
2. 개발자들의 이해와 참여 유도: 새로운 보안 요구사항은 개발자들에게 추가적인 작업으로 인식될 수 있습니다. 초기에는 '또 하나 늘었다'는 반응이 지배적이었습니다. SBoM이나 SLSA의 개념, 그리고 이것이 왜 중요한지에 대한 교육이 절실했습니다.
3. 적절한 도구 선택과 파이프라인 구성: 시장에는 다양한 SBoM 생성 도구와 SLSA Provenance 도구가 있습니다. 어떤 도구가 저희 환경에 가장 적합한지, 그리고 이를 기존 CI/CD 파이프라인에 어떻게 매끄럽게 통합할지 결정하는 데 많은 시행착오를 겪었습니다. 특히 SBoM 생성 도구마다 지원하는 언어 및 패키지 관리자가 다르다는 점이 까다로웠습니다.

난관 극복을 위한 전략

• 점진적 접근 (Phased Approach): 모든 시스템에 한 번에 적용하기보다는, 중요도가 높은 핵심 서비스부터 SBoM 레벨 1, SLSA 레벨 1/2를 목표로 점진적으로 적용했습니다. 성공 사례를 만들고 이를 다른 팀에 전파하는 방식으로 확장해 나갔습니다.
• 적극적인 교육 및 커뮤니케이션: 정기적인 워크숍과 세미나를 통해 SBoM과 SLSA의 개념, 장점, 그리고 개발자들에게 미칠 영향을 상세히 설명했습니다. '왜 해야 하는가'에 대한 공감대를 형성하는 것이 가장 중요했습니다. 특히, SBoM이 취약점 관리를 자동화하여 개발자의 업무 부담을 줄여줄 수 있다는 점을 강조했습니다.
• 자동화 및 개발자 경험(DX) 최적화: 개발자가 직접 SBoM을 생성하거나 Provenance를 관리할 필요 없이, CI/CD 파이프라인이 모든 것을 자동으로 처리하도록 구현했습니다. 개발자는 평소와 다름없이 코드를 커밋하고 PR을 생성하면, 백그라운드에서 모든 보안 검증 및 증명 과정이 이루어지도록 했습니다. 예를 들어, GitHub Actions 템플릿을 만들어 모든 프로젝트에서 쉽게 사용할 수 있도록 제공했습니다.
• 기술 스택에 맞는 도구 선정: 저희 팀이 주로 사용하는 Java, Python, Node.js 프로젝트에 각각 최적화된 SBoM 생성 도구(예: Java - OWASP CycloneDX Maven/Gradle Plugin, Python - pip-audit with CycloneDX exporter, Node.js - npm sbom)를 선정하여 적용했습니다. 또한, 컨테이너 이미지에 대해서는 Syft를 일관되게 사용했습니다.

이러한 노력 덕분에, 저희는 처음의 막연했던 부담감을 덜고 소프트웨어 공급망 보안을 개발 문화의 일부로 자연스럽게 스며들게 할 수 있었습니다. 특히 SBoM과 SLSA 적용 후, 보안 감사 준비 시간이 이전 대비 40% 단축되었고, 내부적으로 발생하는 보안 이슈의 재발률이 25% 감소하는 유의미한 수치를 확인할 수 있었습니다.

Image by Pexels on Pixabay

6. 소프트웨어 공급망 보안 강화를 위한 로드맵 제안

저희 팀의 경험을 바탕으로, 여러분의 조직에서 소프트웨어 공급망 보안을 강화하기 위한 실용적인 로드맵을 제안합니다.

단계별 접근 전략

1. 1단계: 현황 파악 및 목표 설정 (1~2개월)
   • 현재 소프트웨어 공급망 분석: 어떤 오픈소스 라이브러리를 사용하고 있는지, 빌드 및 배포 프로세스는 어떻게 진행되는지 파악합니다.
   • 핵심 위험 식별: 가장 취약하다고 판단되는 부분(예: 수동 빌드, 오래된 라이브러리)을 찾아냅니다.
   • SBoM 및 SLSA 레벨 목표 설정: 초기에는 SLSA 1 또는 2, 핵심 프로젝트에 대한 SBoM 생성을 목표로 삼는 것이 현실적입니다.
   • 보안 인식 교육: 개발팀, DevOps팀 등 관련 이해관계자들에게 공급망 보안의 중요성을 교육합니다.
2. 2단계: SBoM 도입 (2~4개월)
   • SBoM 생성 도구 선정 및 연동: 프로젝트의 기술 스택에 맞는 SBoM 생성 도구(Syft, OWASP CycloneDX 플러그인 등)를 선택하고 CI/CD 파이프라인에 통합합니다. 최종 아티팩트(컨테이너 이미지 포함) 생성 시 SBoM이 자동으로 생성되도록 합니다.
   • SBoM 관리 플랫폼 구축: Dependency-Track과 같은 SBoM 관리 솔루션을 도입하여 생성된 SBoM을 저장하고, 취약점 분석을 자동화합니다.
   • 정기적인 SBoM 업데이트 및 모니터링: 새로운 빌드마다 SBoM을 업데이트하고, 대시보드를 통해 취약점 알림을 받도록 설정합니다.
3. 3단계: SLSA 도입 (3~6개월)
   • SLSA 1 달성: 모든 빌드가 자동화된 CI/CD 파이프라인을 통해 이루어지도록 강제하고, 빌드 출처(Provenance)를 생성하는 기능을 파이프라인에 추가합니다. in-toto 또는 OCI(Open Container Initiative) 이미지 명세를 활용합니다.
   • SLSA 2 달성: 소스 코드 관리 시스템(VCS)의 모든 변경 사항에 대한 검토를 의무화하고, 빌드 환경의 변조 방지 조치를 강화합니다. (예: ephemeral 빌드 에이전트 사용, CI/CD 시스템 접근 제어 강화)
   • 아티팩트 서명 도입: Cosign과 같은 도구를 활용하여 빌드된 아티팩트와 Provenance attestation에 디지털 서명을 합니다. 배포 시 서명 검증을 의무화합니다.
4. 4단계: 통합 및 지속적인 개선 (6개월 이후)
   • SBoM과 SLSA 통합: SLSA Provenance 내에 SBoM 정보를 포함하거나, SBoM 자체에 대한 Provenance를 생성하여 신뢰도를 높입니다.
   • 정책 기반의 자동화된 검증: 배포 게이트(Deployment Gate)에서 SBoM의 취약점 유무, SLSA Provenance의 유효성 등을 자동으로 검증하는 정책을 적용합니다.
   • SLSA 3, 4로의 확장 고려: 장기적으로는 더욱 강화된 빌드 환경(SLSA 3)과 재현 가능한 빌드, 두 명 검토(SLSA 4)를 목표로 로드맵을 확장합니다.
   • 위협 인텔리전스 연동: 최신 공급망 공격 트렌드와 취약점 정보를 지속적으로 모니터링하고, 보안 정책에 반영합니다.

이 로드맵은 저희 팀이 실제 겪었던 과정을 기반으로 한 것이며, 각 조직의 상황과 기술 스택에 따라 유연하게 조정될 수 있습니다. 중요한 것은 한 번에 완벽하게 하려 하기보다는, 작게 시작하여 점진적으로 개선해 나가는 것입니다.

결론: 소프트웨어 신뢰의 새로운 표준을 향하여

소프트웨어 공급망 보안은 이제 선택이 아닌 필수가 되었습니다. 저희 팀이 SBoM과 SLSA 프레임워크를 개발 프로세스에 통합하면서 느낀 가장 큰 점은, 단순히 외부의 위협을 막는 것을 넘어 우리 스스로 만드는 소프트웨어에 대한 근본적인 신뢰를 구축할 수 있었다는 것입니다. 어떤 구성 요소로 만들어졌고, 어떤 과정을 거쳐 완성되었는지 투명하게 파악하고 증명할 수 있게 되면서, 개발팀의 자신감도 크게 향상되었습니다.

물론 이 여정에는 기술적인 어려움과 조직적인 변화가 동반됩니다. 하지만 이러한 노력이 가져올 장기적인 이점, 즉 더욱 안전하고 신뢰할 수 있는 소프트웨어를 제공하고, 잠재적인 보안 사고의 위험을 최소화하며, 규제 준수 및 시장 경쟁력을 확보하는 것은 그 어떤 노력보다 값진 일이라고 생각합니다.

여러분도 이 글을 통해 소프트웨어 공급망 보안의 중요성을 다시 한번 인식하고, SBoM과 SLSA를 여러분의 개발 프로세스에 통합하는 첫걸음을 내디딜 용기를 얻으셨기를 바랍니다. 여러분의 경험이나 궁금한 점이 있다면 언제든지 댓글로 공유해주세요. 함께 고민하고 발전해나가는 개발 문화가 되기를 기대합니다!

📌 함께 읽으면 좋은 글

• [보안] OWASP Top 10 핵심 취약점 분석과 실용적인 웹 방어 전략
• [생산성 자동화] 개발 생산성 극대화: 템플릿 기반 프로젝트 스캐폴딩 전략 비교 분석
• [보안] 민감 데이터 보호를 위한 암호화 전략: 저장 데이터와 전송 데이터 안전하게 지키는 법

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.