소프트웨어 공급망 보안 핵심: 의존성 취약점 관리와 SBOM 생성 완벽 가이드

소프트웨어 공급망 보안의 중요성을 이해하고, 의존성 취약점 관리부터 SBOM 생성 및 활용까지 실질적인 가이드를 통해 안전한 소프트웨어 개발 환경을 구축하는 방법을 알아봅니다.

소프트웨어 공급망 보안 핵심: 의존성 취약점 관리와 SBOM 생성 완벽 가이드

소프트웨어 개발 과정에서 외부 의존성에 대한 불안감을 느껴본 적이 있으신가요? 수많은 오픈소스 라이브러리와 서드파티 컴포넌트 위에 구축되는 현대 소프트웨어는 편리함을 제공하지만, 동시에 새로운 보안 위협의 문을 열어줍니다. 마치 거대한 퍼즐 조각을 맞추는 것처럼 다양한 부품으로 이루어진 소프트웨어에서 단 하나의 취약한 조각이 전체 시스템을 무너뜨릴 수 있는 상황은 더 이상 낯선 이야기가 아닙니다. 이러한 문제를 해결하고 안전한 소프트웨어 생태계를 구축하기 위한 핵심 전략, 바로 소프트웨어 공급망 보안과 그 중심에 있는 의존성 취약점 관리 그리고 SBOM(Software Bill of Materials)에 대해 알아보겠습니다.

📑 목차

• 소프트웨어 공급망 보안, 왜 중요해졌을까?
• 의존성 취약점, 어디서 발생할까?
• 의존성 취약점 관리의 첫걸음: 식별 및 분석
• 수동 분석 vs 자동화 도구
• 효과적인 의존성 취약점 관리 전략
• 개발 단계별 보안 통합 (Shift Left)
• 패치 및 업데이트 관리
• 내부 정책 및 거버넌스 수립
• SBOM (Software Bill of Materials)이란 무엇이며 왜 필요한가?
• SBOM이 필요한 이유
• 표준 SBOM 형식: SPDX와 CycloneDX
• SBOM 생성 및 활용 실전 가이드
• SBOM 생성 도구 활용
• CI/CD 파이프라인에 SBOM 생성 통합
• SBOM 활용 전략
• 성공적인 소프트웨어 공급망 보안을 위한 제언

Image by marcinjozwiak on Pixabay

소프트웨어 공급망 보안, 왜 중요해졌을까?

과거에는 하나의 거대한 모놀리식 애플리케이션을 직접 개발하는 방식이 주를 이루었습니다. 하지만 마이크로서비스 아키텍처와 오픈소스 생태계의 폭발적인 성장으로 인해, 대부분의 소프트웨어는 이제 수십, 수백 개의 외부 라이브러리와 프레임워크에 의존합니다. 프로젝트의 약 80~90%가 오픈소스 컴포넌트로 구성된다는 보고도 심심치 않게 찾아볼 수 있습니다. 이는 개발 속도를 비약적으로 향상시키고 혁신을 가속화했지만, 동시에 예측하기 어려운 새로운 유형의 보안 위험을 초래했습니다.

소프트웨어 공급망 공격은 더 이상 이론적인 위협이 아닙니다. 실제 많은 조직이 자신들이 사용하는 서드파티 컴포넌트나 개발 도구의 취약점을 통해 침해당하는 사례를 경험했습니다. 공격자들은 최종 소프트웨어 제품이 아닌, 그 제품을 만드는 과정의 약한 고리를 노립니다. 예를 들어, 오픈소스 저장소에 악성 코드를 삽입하거나, 자주 사용되는 라이브러리의 개발 환경을 침해하여 배포되는 모든 소프트웨어에 악성 코드를 심는 방식입니다. 이러한 공격은 파급력이 매우 크며, 탐지하고 복구하는 데 막대한 시간과 비용이 소요됩니다.

의존성 취약점, 어디서 발생할까?

• 직접 의존성 (Direct Dependencies): 프로젝트가 직접 사용하는 라이브러리나 패키지에서 발생하는 취약점입니다. 예를 들어, 웹 프레임워크의 특정 버전에서 발견된 RCE(원격 코드 실행) 취약점이 여기에 해당합니다.
• 전이적 의존성 (Transitive Dependencies): 프로젝트가 직접 사용하는 라이브러리가 또 다른 라이브러리를 의존하고, 그 라이브러리에 취약점이 있는 경우입니다. 수십, 수백 개의 전이적 의존성을 일일이 관리하는 것은 사실상 불가능하며, 대부분의 취약점은 여기서 발생합니다.
• 오래된 라이브러리 (Outdated Libraries): 보안 패치가 적용되지 않은 오래된 버전의 라이브러리를 사용하면서 발생하는 취약점입니다. 새로운 취약점이 발견되더라도 업데이트가 이루어지지 않아 계속해서 위험에 노출됩니다.
• 악성 패키지 (Malicious Packages): 공격자가 정상적인 라이브러리를 위장하거나, 타이포스쿼팅(typosquatting) 방식으로 유사한 이름의 악성 패키지를 배포하여 개발자가 실수로 설치하도록 유도하는 경우입니다.

이러한 문제들로 인해, 개발자들은 단순히 코드를 잘 작성하는 것을 넘어, 사용하는 모든 컴포넌트의 안전성을 보장해야 하는 새로운 과제에 직면했습니다. 이것이 바로 소프트웨어 공급망 보안이 소프트웨어 개발의 필수적인 요소로 자리매김하게 된 이유입니다.

의존성 취약점 관리의 첫걸음: 식별 및 분석

문제를 해결하기 위한 첫 단계는 문제가 무엇인지 정확히 아는 것입니다. 소프트웨어 의존성 취약점 관리 역시 마찬가지입니다. 우리 소프트웨어가 어떤 구성 요소로 이루어져 있는지, 각 구성 요소에 알려진 취약점은 없는지 정확하게 식별하고 분석해야 합니다.

수동 분석 vs 자동화 도구

소프트웨어 프로젝트에 포함된 모든 의존성을 수동으로 파악하고, 각 의존성의 보안 취약점을 일일이 검색하는 것은 비현실적입니다. 특히 수십, 수백 개의 전이적 의존성을 고려하면 더욱 그렇습니다. 다행히 이러한 과정을 자동화해주는 SCA(Software Composition Analysis) 도구들이 있습니다.

SCA 도구는 프로젝트의 소스코드, 바이너리, 패키지 관리 파일(예: package.json, pom.xml, requirements.txt 등)을 분석하여 사용된 오픈소스 컴포넌트 목록을 식별하고, 알려진 취약점 데이터베이스(예: NVD - National Vulnerability Database, OSV - Open Source Vulnerabilities)와 비교하여 잠재적인 보안 문제를 찾아냅니다. 또한, 오픈소스 라이선스 정보를 분석하여 라이선스 충돌 문제도 식별할 수 있습니다.

널리 사용되는 SCA 도구는 다음과 같습니다.

• OWASP Dependency-Check: 오픈소스 도구로, 다양한 언어 및 빌드 시스템을 지원하며 NVD를 기반으로 취약점을 탐지합니다. CI/CD 파이프라인에 통합하기 용이합니다.
• Snyk: 상용 SCA 도구로, 실시간 취약점 탐지, 자동화된 패치 권고, 개발자 워크플로우 통합에 강점을 가집니다. 특정 언어 및 프레임워크에 대한 깊이 있는 분석을 제공합니다.
• WhiteSource (Mend): 또 다른 상용 SCA 도구로, 포괄적인 오픈소스 관리 및 보안 기능을 제공하며, 라이선스 준수 및 정책 시행에 특화되어 있습니다.

다음은 오픈소스와 상용 SCA 도구의 일반적인 비교입니다.

특징	OWASP Dependency-Check (오픈소스)	Snyk, WhiteSource 등 (상용)
비용	무료	유료 (구독 기반)
지원 언어/생태계	다양한 언어 지원 (Java, .NET, Node.js, Python 등)	더 넓고 깊이 있는 언어/프레임워크 지원
취약점 데이터베이스	NVD 중심	자체 큐레이션된 DB + NVD/OSV 등 통합
탐지 정확도 및 범위	일반적인 취약점 탐지	더 높은 정확도, 전이적 의존성 상세 분석, 컨텍스트 기반 조언
개발자 워크플로우 통합	CI/CD 플러그인 등 연동 가능	IDE 플러그인, Git 통합, 자동 PR 생성 등 고도화된 통합
라이선스 관리	기본적인 라이선스 정보 제공	정책 기반의 자동화된 라이선스 규정 준수 검사
보고서 및 대시보드	기본적인 보고서 생성	풍부한 대시보드, 리포팅, 감사 추적 기능

조직의 규모, 예산, 요구사항에 따라 적절한 SCA 도구를 선택하는 것이 중요합니다. 작은 프로젝트나 예산이 제한적인 경우 OWASP Dependency-Check로 시작하여 기본적인 보안 검증을 수행하고, 더 고도화된 관리와 자동화가 필요한 경우 상용 솔루션을 고려해볼 수 있습니다.

효과적인 의존성 취약점 관리 전략

단순히 취약점을 식별하는 것을 넘어, 이를 체계적으로 관리하고 해결하는 전략이 필요합니다. 개발 수명 주기 전반에 걸쳐 보안을 통합하는 접근 방식이 필수적입니다.

개발 단계별 보안 통합 (Shift Left)

보안은 개발 프로세스의 마지막 단계에서 추가되는 것이 아니라, 기획 단계부터 배포까지 모든 단계에 걸쳐 고려되어야 합니다. 이를 'Shift Left'라고 부릅니다. 취약점을 개발 초기 단계에서 발견할수록 수정 비용과 노력이 크게 절감됩니다. 버그 발견 시점이 배포 단계에 가까워질수록 수정 비용이 10배, 100배 이상 증가한다는 연구 결과도 있습니다.

• 개발 환경: 개발자는 IDE(통합 개발 환경) 플러그인을 통해 코드를 작성하는 동안 실시간으로 의존성 취약점을 감지하고 해결할 수 있어야 합니다.
• 코드 저장소: Git 등의 코드 저장소에 푸시(push)하기 전에 정적 분석 도구와 SCA 도구를 연동하여 취약점을 검사하고, 특정 임계치 이상의 취약점이 발견되면 커밋(commit)을 거부하는 정책을 적용할 수 있습니다.
• CI/CD 파이프라인: 빌드 및 배포 파이프라인에 SCA 스캔 단계를 필수적으로 포함해야 합니다. 새로운 코드가 병합될 때마다, 또는 주기적으로 전체 의존성 트리를 스캔하여 취약점을 탐지하고, 빌드를 중단하거나 경고를 발생시킬 수 있습니다.

# CI/CD 파이프라인에서 Snyk CLI를 사용하는 예시 (YAML)
stages:
  - build
  - test
  - security_scan

build-job:
  stage: build
  script:
    - npm install
    - npm run build

security-scan-job:
  stage: security_scan
  script:
    - snyk auth YOUR_SNYK_TOKEN
    - snyk test --severity-threshold=high --json > snyk_report.json
    - snyk monitor # 지속적인 모니터링을 위해 프로젝트 스냅샷 전송
  allow_failure: false # 심각한 취약점 발견 시 빌드 실패

패치 및 업데이트 관리

취약점이 발견되면 신속하게 패치하거나 업데이트하는 것이 중요합니다. 이를 위한 체계적인 프로세스를 수립해야 합니다.

• 정기적인 스캔: 최소한 주 1회 또는 새로운 배포 전에 모든 의존성을 스캔하여 최신 취약점 정보를 반영해야 합니다.
• 위험 기반 우선순위: 모든 취약점을 동시에 해결할 수는 없습니다. CVSS(Common Vulnerability Scoring System) 점수, 익스플로잇 가능성, 비즈니스 영향도 등을 고려하여 가장 위험도가 높은 취약점부터 우선적으로 해결합니다.
• 자동화된 업데이트: Dependabot(GitHub), Renovate(GitLab/GitHub)와 같은 도구를 활용하여 의존성 업데이트를 자동화하고, 새로운 버전이 출시될 때마다 자동으로 풀 리퀘스트(Pull Request)를 생성하도록 설정할 수 있습니다.
• 내부 정책 수립: 사용 가능한 오픈소스 컴포넌트 목록을 관리하고, 특정 버전 이하의 라이브러리 사용을 금지하는 등의 내부 보안 정책을 수립하여 시행합니다.

내부 정책 및 거버넌스 수립

기술적인 해결책 외에도 조직 차원의 정책과 거버넌스가 중요합니다.

• 보안 챔피언 프로그램: 각 개발 팀 내에 보안 전문가를 양성하여, 팀원들이 보안 모범 사례를 따르도록 돕고 보안 이슈를 신속하게 해결하는 역할을 부여합니다.
• 오픈소스 사용 정책: 어떤 오픈소스를 사용할 수 있는지, 어떤 라이선스 정책을 따라야 하는지 명확히 정의합니다. 승인된 컴포넌트 목록을 만들고, 새로운 오픈소스를 도입할 때는 보안 및 라이선스 검토 프로세스를 거치도록 합니다.
• 정기적인 보안 교육: 개발자들이 최신 보안 위협과 방어 기술에 대한 인식을 높일 수 있도록 정기적인 교육을 제공합니다.

Image by analogicus on Pixabay

SBOM (Software Bill of Materials)이란 무엇이며 왜 필요한가?

SBOM(Software Bill of Materials)은 소프트웨어에 포함된 모든 구성 요소에 대한 상세 목록입니다. 마치 식품의 성분표처럼, 소프트웨어가 어떤 오픈소스 라이브러리, 서드파티 컴포넌트, 내부 개발 모듈 등으로 이루어져 있는지 명확하게 명시하는 문서입니다. SBOM은 소프트웨어의 "재료 목록"이라고 생각할 수 있습니다.

SBOM에는 일반적으로 다음과 같은 정보가 포함됩니다.

• 컴포넌트 이름 및 버전
• 벤더 정보
• 컴포넌트 해시 값 (무결성 검증용)
• 라이선스 정보
• 컴포넌트 간의 관계 (종속성 그래프)

SBOM이 필요한 이유

SBOM은 소프트웨어 공급망 보안의 투명성을 확보하고, 위협에 대한 대응 능력을 강화하는 데 필수적입니다.

1. 투명성 확보: 소프트웨어에 무엇이 포함되어 있는지 명확하게 알 수 있습니다. 이는 특히 외부에서 소프트웨어를 받아서 사용하는 경우, 그 소프트웨어의 잠재적인 위험을 평가하는 데 큰 도움이 됩니다.
2. 취약점 관리 효율화: 새로운 제로데이(zero-day) 취약점이 발견되었을 때, SBOM을 통해 우리 시스템에 해당 취약점을 가진 컴포넌트가 포함되어 있는지 신속하게 파악하고 대응할 수 있습니다. 수동으로 모든 의존성을 검색하는 것보다 훨씬 빠르고 정확합니다.
3. 라이선스 준수: 오픈소스 컴포넌트의 라이선스 정보를 포함하므로, 라이선스 의무를 정확히 이행하고 법적 분쟁을 예방할 수 있습니다.
4. 규제 준수: 일부 국가에서는 중요한 인프라에 사용되는 소프트웨어에 대한 SBOM 제공을 의무화하는 추세입니다. 이는 보안 규제 준수의 핵심 요소가 되고 있습니다.
5. 사고 대응 시간 단축: 보안 사고 발생 시, SBOM은 문제의 근원을 파악하고 영향을 받는 부분을 식별하는 데 결정적인 역할을 하여, 사고 대응 시간을 크게 단축시킵니다.

표준 SBOM 형식: SPDX와 CycloneDX

SBOM은 특정 형식에 따라 작성됩니다. 현재 가장 널리 사용되는 두 가지 주요 표준 형식은 SPDX(Software Package Data Exchange)와 CycloneDX입니다.

특징	SPDX	CycloneDX
초점	라이선스 준수 및 저작권 정보에 더 강점	보안 취약점 관리 및 공급망 분석에 더 강점
주요 사용처	법률 및 라이선스 컴플라이언스, 장기적인 소프트웨어 자산 관리	DevSecOps 워크플로우, 취약점 인텔리전스, 공격 표면 관리
유연성	더 포괄적이고 다양한 정보 표현 가능	가볍고 자동화에 최적화된 구조
데이터 형식	JSON, YAML, XML, Tag-Value 등	JSON, XML
강점	정교한 라이선스 정보, 관계 표현	보안 중심의 컴포넌트 및 서비스 정보, BOM-Link 지원

두 표준 모두 장단점이 있으며, 조직의 주요 목표(라이선스 준수 또는 보안 위협 관리)에 따라 선택하거나, 두 가지 모두를 활용하여 보완적인 정보로 사용하는 경우도 있습니다.

Image by makabera on Pixabay

SBOM 생성 및 활용 실전 가이드

SBOM의 중요성을 이해했다면, 이제 실제로 SBOM을 생성하고 활용하는 방법을 알아보겠습니다.

SBOM 생성 도구 활용

수동으로 SBOM을 작성하는 것은 매우 어렵고 오류 발생 가능성이 높습니다. 다행히 다양한 자동화 도구들이 존재합니다.

• Syft: Anchore에서 개발한 오픈소스 CLI 도구로, 컨테이너 이미지, 파일 시스템 등에서 소프트웨어 컴포넌트 목록을 빠르고 정확하게 생성합니다. SPDX, CycloneDX 포맷을 모두 지원합니다.
• Tern: Linux Foundation에서 지원하는 오픈소스 도구로, 주로 컨테이너 이미지 내의 소프트웨어 패키지를 분석하여 SBOM을 생성합니다.
• Microsoft SBOM Tool: Microsoft에서 개발한 도구로, 다양한 언어 및 빌드 시스템을 지원하며, 특히 .NET 환경에 강점을 가집니다.
• SCA 도구 연동: Snyk, WhiteSource 등 상용 SCA 도구 중 상당수는 SCA 스캔 결과와 함께 SBOM을 생성하는 기능을 제공합니다.

예를 들어, Syft를 사용하여 현재 디렉토리의 프로젝트에 대한 SPDX 형식의 SBOM을 생성하는 명령어는 다음과 같습니다.

# Syft 설치 (예: Homebrew 사용)
brew install syft

# 현재 디렉토리의 프로젝트에 대해 SPDX JSON 형식의 SBOM 생성
syft dir:. -o spdx-json=sbom.spdx.json

# Docker 이미지에 대한 CycloneDX JSON 형식의 SBOM 생성
syft docker:nginx:latest -o cyclonedx-json=nginx-sbom.json

이 명령어는 `sbom.spdx.json`이라는 파일을 생성하며, 이 파일에는 프로젝트의 모든 의존성 정보가 포함됩니다.

CI/CD 파이프라인에 SBOM 생성 통합

SBOM은 소프트웨어가 빌드될 때마다 자동으로 생성되고 업데이트되어야 합니다. 이를 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인에 통합하는 것이 가장 효율적입니다.

1. 빌드 단계에 포함: 소프트웨어가 빌드되는 과정에서 SBOM 생성 도구를 실행하여 해당 빌드 아티팩트(예: Docker 이미지, JAR 파일, 실행 파일)에 대한 SBOM을 생성합니다.
2. SBOM 저장소: 생성된 SBOM 파일은 빌드 아티팩트와 함께 버전 관리 시스템(예: Git)에 저장하거나, 별도의 SBOM 관리 시스템에 저장하여 추적 가능하도록 합니다.
3. 자동 검증: SBOM이 성공적으로 생성되었는지, 누락된 정보는 없는지 자동으로 검증하는 단계를 추가할 수 있습니다.

# CI/CD 파이프라인에 SBOM 생성 단계를 추가하는 예시 (GitLab CI)
stages:
  - build
  - generate_sbom
  - deploy

build_app:
  stage: build
  script:
    - docker build -t my-app:latest .
  artifacts:
    paths:
      - . # 빌드 결과물을 다음 스테이지에서 사용하기 위해

generate_sbom:
  stage: generate_sbom
  script:
    - syft docker:my-app:latest -o spdx-json=my-app-sbom.spdx.json
    - ls -l my-app-sbom.spdx.json # SBOM 파일이 생성되었는지 확인
  artifacts:
    paths:
      - my-app-sbom.spdx.json # 생성된 SBOM 파일을 아티팩트로 저장

deploy_app:
  stage: deploy
  script:
    - echo "Deploying my-app:latest with its SBOM..."
    - # 배포 로직 (예: Kubernetes 배포)

SBOM 활용 전략

생성된 SBOM은 단순히 보관하는 것을 넘어, 다음과 같이 적극적으로 활용해야 합니다.

• 지속적인 취약점 모니터링: 새로운 취약점(CVE)이 발표될 때마다 SBOM을 기반으로 우리 소프트웨어에 해당 취약점이 포함된 컴포넌트가 있는지 자동으로 검사합니다. 예를 들어, Grype와 같은 도구는 SBOM을 입력받아 취약점을 스캔할 수 있습니다.
• 라이선스 규정 준수 검사: SBOM에 포함된 라이선스 정보를 기반으로 조직의 라이선스 정책에 위배되는 컴포넌트가 없는지 검사합니다.
• 외부 감사 및 규제 준수: 외부 감사나 규제 기관의 요청 시, 소프트웨어의 구성 요소에 대한 투명한 정보를 제공하여 신뢰도를 높입니다.
• 공격 표면 분석: SBOM을 통해 소프트웨어의 전체적인 구성 요소를 파악하고, 잠재적인 공격 벡터를 식별하여 선제적으로 방어 전략을 수립합니다.
• 타사 공급업체 관리: 소프트웨어를 구매하거나 외부 공급업체로부터 솔루션을 도입할 때, 해당 공급업체에 SBOM을 요청하여 사용하는 소프트웨어의 보안 상태를 평가하는 기준으로 삼습니다.

성공적인 소프트웨어 공급망 보안을 위한 제언

소프트웨어 공급망 보안은 단일 도구나 일회성 프로젝트로 완성되지 않습니다. 이는 지속적인 노력과 조직 문화의 변화를 요구하는 여정입니다.

• 보안은 모두의 책임: 개발자, QA 엔지니어, 운영팀, 보안팀 등 모든 이해관계자가 보안에 대한 인식을 공유하고 각자의 역할에서 책임을 다해야 합니다.
• 지속적인 모니터링 및 개선: 소프트웨어 환경은 끊임없이 변화하므로, 한번 구축된 보안 시스템이라도 정기적으로 검토하고 최신 위협에 맞춰 개선해야 합니다. 새로운 취약점, 새로운 공격 기법, 새로운 컴포넌트가 계속해서 등장하기 때문입니다.
• 위협 모델링: 개발 초기 단계부터 소프트웨어의 잠재적인 위협 요소를 식별하고, 각 위협에 대한 대응 방안을 설계하는 위협 모델링을 습관화해야 합니다.
• 벤더 리스크 관리: 외부에서 도입하는 모든 소프트웨어 및 서비스 공급업체에 대한 보안 리스크 평가를 수행하고, 계약 시 보안 요구사항을 명확히 명시해야 합니다. SBOM 요청은 이러한 벤더 리스크 관리의 중요한 부분이 될 수 있습니다.
• 자동화의 생활화: 수동 작업은 오류를 유발하고 효율성을 떨어뜨립니다. SCA, SBOM 생성, 취약점 패치 권고 등 가능한 모든 보안 관련 프로세스를 자동화하여 개발 워크플로우에 녹여내야 합니다.

소프트웨어 공급망 보안은 더 이상 선택 사항이 아닌 필수 사항입니다. 의존성 취약점 관리와 SBOM 생성 및 활용을 통해 여러분의 소프트웨어를 더욱 안전하게 보호하고, 잠재적인 위협으로부터 비즈니스를 지켜나가시길 바랍니다.

핵심 요약:

• 현대 소프트웨어는 오픈소스 의존도가 높아 소프트웨어 공급망 보안이 매우 중요합니다.
• SCA 도구를 활용하여 의존성 취약점을 자동으로 식별하고 관리해야 합니다.
• Shift Left 원칙에 따라 개발 초기 단계부터 보안을 통합하고, CI/CD 파이프라인에 자동화된 보안 검사를 포함해야 합니다.
• SBOM(Software Bill of Materials)은 소프트웨어 구성 요소를 투명하게 보여주는 목록으로, 취약점 대응 및 규제 준수에 필수적입니다.
• Syft, Tern 등 도구를 이용해 SBOM을 생성하고, CI/CD에 통합하여 지속적으로 활용해야 합니다.
• 성공적인 공급망 보안은 지속적인 모니터링, 문화적 변화, 그리고 자동화를 통해 이루어집니다.

여러분의 조직에서는 어떤 도구나 전략을 사용하고 계신가요? 댓글로 공유해주세요!

📌 함께 읽으면 좋은 글

• [커리어 취업] 개발자 연봉 협상 성공 전략: 시장 가치 파악부터 제안 수락까지
• [보안] 컨테이너 보안 마스터하기: Docker, Kubernetes 취약점 관리부터 런타임 보호까지
• [보안] OAuth 2.0과 OpenID Connect로 안전한 사용자 인증 및 인가 시스템 설계 전략

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