DevSecOps를 위한 CI/CD 보안: PR 리뷰.. 혹시 LGTM 하고 계신가요?

CI/CD 소프트웨어 혹은 파이프라인에 보안 문제가 발생하게 되면 소스 코드 혹은 인프라의 민감 정보가 노출될 수 있을 뿐 아니라, 서비스에 치명적인 피해가 발생할 수 있습니다. Jenkins와 Github Actions를 중심으로 CI/CD를 사용할 때에 발생할 수 있는 다양한 보안 문제와 안전하게 사용하기 위해 지켜야 할 내용에 대해 소개합니다.

Frontier Squad

Feb 12, 2024

DevSecOps를 위한 CI/CD 보안: PR 리뷰.. 혹시 LGTM 하고 계신가요?

Contents

개요 Tensorflow, Pytorch CI runner Attack in January, 2024 CI security issues & Remediation 1. Pipeline Command Injection 2. Credential Exposure 3. 3rd Party Dependency Security hardening 1. Controller Isolation 2. Signing Container Image 3. Immediate updates 4. Access Controls in CI Controller 마치며 Reference About Theori Security Assessment

개요

빠르게 변화하는 고객의 요구사항에 대응하기 위해 등장한 애자일 방법론은 현재 대다수의 소프트웨어 기업에서 채택하고 있습니다. 이러한 방향성과 함께, Continuous Integration (CI), Continuous Delivery (CD) 개념이 등장하면서 개발자가 작성한 코드에 대한 머지, 테스트, 그리고 배포 프로세스의 자동화가 중요한 이슈로 떠오르게 되었습니다.

지난 2023년 하반기 보안 사건 사고 포스팅에서 JetBrains TeamCity의 취약점으로 인해 발생한 보안 사고에 대해 소개해 드렸는데요! CI/CD 소프트웨어 혹은 파이프라인에 보안 문제가 발생하게 되면 소스 코드 혹은 인프라의 민감 정보가 노출될 수 있을 뿐 아니라, 공격자가 CI/CD 파이프라인을 통해 공격을 수행할 경우에는 실제 운영되고 있는 서비스에 치명적인 공격을 수행할 수 있습니다.

이러한 관점으로, 본 포스트에서는 Jenkins와 Github Actions를 중심으로 CI/CD를 사용할 때에 발생할 수 있는 다양한 보안 문제와 안전하게 사용하기 위해 지켜야 할 내용에 대해 소개합니다.

Tensorflow, Pytorch CI runner Attack in January, 2024

GPT를 필두로 인공지능에 대한 관심도가 높아지면서, 많은 기업들이 AI를 내재화하기 위해 노력하고 있습니다. TensorFlow와 PyTorch는 인공지능, 그 중에서도 머신러닝에 필수적으로 사용된다고 할 수 있을 정도로 사용빈도가 높고, 이는 나날이 증가하고 있습니다. 그러나 이러한 유명 프로젝트도 CI/CD 보안에 취약한 모습을 보일 정도로 최근까지 CI/CD는 해커에게 좋은 먹이감을 제공하고 있습니다.

지난 1월에 TensorFlow와 PyTorch에 PR (Pull Request)를 통해 CI 파이프라인인 워크플로우를 등록하거나 다른 워크플로우의 Command injection 취약점을 통해 CI 서버를 탈취하여, GITHUB_TOKEN, JENKINS_TOKEN 등의 중요 정보를 탈취하거나 레포지토리를 조작할 수 있음을 증명한 연구가 발표되었습니다.

연구에 따르면, 레포지토리에 PR을 통해 워크플로우를 등록할 수 있거나, 기존 워크플로우의 취약점을 트리거할 수 있는 경우 이와 같은 공격이 가능합니다.

물론 다수의 기업이 내부 서비스 소스코드에 PR을 요청하는 권한을 사내 인원으로 한정하고 있지만, 외부 라이브러리에 포함된 워크플로우를 그대로 사용하는 경우 이와 같은 공격이 가능하고, 사내 인원으로 한정하더라도 프로젝트별로 권한 관리 및 접근 제어가 미흡하거나 PR에 대하여 적절한 검토를 거치지않고 승인하는 문화가 만연한 경우가 많습니다.

최근 큰 이슈가 되었던 북한의 IT 인력 위장 취업 사례와 함께 민감 정보 유출 등 대부분의 보안 사고가 조직 내부에서 발생한다는 점을 함께 고려했을 때, 기업에서는 외부 공격자 뿐 아니라 내부자 관점의 공격 또한 중요한 이슈로 판단 및 대응해야 합니다.

CI security issues & Remediation

1. Pipeline Command Injection

CI에서 파이프라인을 정의할 때에는 주로 특정 파일에 script 언어를 사용합니다. Jenkins의 경우 Jenkinsfile이라는 파일에 Groovy Script를 작성해서 파이프라인을 명시하고, Github Actions의 경우에는 yaml 파일을 통해 워크플로우를 정의합니다. 이때, 파이프라인 정의에 공격자가 조작 가능한 입력값이 있다면 이는 파이프라인을 실행하는 CI 실행 환경에 임의 코드 실행을 야기할 수 있습니다.

Jenkins의 취약점 예시를 통해 좀 더 자세히 알아보겠습니다. Jenkins는 Groovy (Jenkinsfile)를 통해 파이프라인 과정을 정의할 수 있고, sh를 사용해 빌드 과정에 필요한 쉘 명령을 실행할 수 있습니다.

Groovy에서 문자열 선언에 큰따옴표(“)를 사용하는 경우 문자열 내부의 ${…}로 묶인 Groovy 표현식을 실행해 치환하고, 작은따옴표(‘)를 사용하는 경우 Groovy 표현식으로 판단하지 않습니다.

예를 들어 다음과 같은 Jenkinsfile이 있고, commitMessage 변수에 조작 가능한 커밋 메시지가 담겨있다고 해봅시다.

Jenkins는 /var/jenkins_home/workspace/{NAME}@tmp/durable-{random id}/script.sh 파일을 만들어 sh 명령을 처리합니다.

이때 ${commitMessage}에 Jenkins의 변수 값이 대입되어 script.sh 파일의 내용은 다음과 같습니다.

만약 commitMessage가 Hello’; whoami; echo ‘ 라면 어떤 일이 일어날까요?

이 경우 script.sh의 내용은 다음과 같습니다.

공식 문서는 다음과 같이 문자열을 작은따옴표(‘)로 선언하고 쉘의 환경 변수를 통해 적용하도록 권장하고 있습니다.

이때 script.sh 파일의 내용은 다음과 같습니다.

위와 같은 방법을 사용하면 커밋 메시지에 악의적인 명령을 주입하더라도 일반적인 쉘에서는 주입된 명령이 실행되지 않습니다.

다음은 Slack에 메시지를 전송하는 공식 문서의 예제입니다.

커밋 메세지의 예제와 마찬가지로, 위 Slack 메세지를 전송하는 예제도 유사한 취약점이 발생합니다. 공격자가 입력한 내용이 notifySlack에 사용되는 경우, 예를 들어 text의 내용이 ‘http://URL; whoami; echo’일 때 다음과 같은 명령이 실행됩니다.

공식 문서에도 취약점이 존재하는 만큼 이를 검열없이 사용하다보면 쉽게 발생할 수 있는 취약점이므로 주의하여 사용해야 합니다.

위 예시의 경우, 다음과 같이 환경 변수를 사용하여 취약점이 발생하지 않게 패치할 수 있습니다.

Slack에 메시지 전송이 필요한 경우 Slack Notification 플러그인을 사용할 수 있습니다. 쉘 명령이 아닌 Java의 HttpClient를 사용하여 전송하기 때문에 위와 동일한 취약점이 발생하지는 않습니다. 하지만 여러 Jenkins 플러그인에서 꾸준히 취약점이 발생하고 있으며, 다른 문제가 없다는 점을 보장할 수 없으므로 플러그인을 사용할 때에는 충분한 검수 후에 사용하여야 합니다.

추가로, GitHub Actions에서도 Jenkins에서와 비슷한 취약점이 발생할 수 있습니다.

위와 같은 워크플로우가 있을 때, Pull Request의 제목을 a”; ls $GITHUB_WORKSPACE”로 설정한 뒤 실행하면 ls 명령을 실행할 수 있습니다. 마찬가지로 환경 변수를 설정하여 쉘에서 값이 적용되도록 하여 해결할 수 있습니다.

이처럼 CI 파이프라인 스크립트에서 사용자의 입력을 이용할 때에는 환경 변수나 상황에 맞는 Builder를 사용하여 쉘 명령에 사용자의 입력이 직접 전달되지 않도록 해야합니다.

2. Credential Exposure

빌드 과정에서 API 키나 Private Key 등이 필요한 경우가 있을 수 있습니다. 이러한 크리덴셜이 콘솔에 노출되면, 공격자는 CI 빌드 콘솔 읽기 권한만 획득하여도 여타 다른 컴포넌트의 크리덴셜을 알 수 있으므로 lateral movement를 통해 다른 인프라에 공격을 수행할 수 있게됩니다. 따라서 크리덴셜이 빌드 콘솔에 노출되지 않도록 파일이나 환경 변수 등을 통해 관리하는 것이 바람직합니다.

이를 지원하기 위해 Jenkins에는 Manage Credentials에서 기능을 제공하고, Github Action의 경우에도 Action secrets and variables 탭에서 이를 관리할 수 있습니다.

해당 기능을 통해 파일이나 환경 변수로 관리되는 크리덴셜에 대한 접근 권한까지도 세부적으로 관리할 수 있습니다.

만약 정말 부득이하게 콘솔에 노출해야하는 경우라면, CI에 크리덴셜을 마스킹하는 함수를 사용할 수 있습니다. Jenkins의 경우, Jenkins Credentials Binding Plugin의 withCredentials는 저장소에 설정된 크리덴셜을 Groovy 변수와 쉘 환경 변수에서 사용할 수 있도록 해줍니다. 또한 크리덴셜의 출력이 발생해도 ****로 마스킹되어 쉘에서 노출되지 않습니다.

그러나, Base64 인코딩과 같이 크리덴셜 원본 값의 변형이 일어나는 경우 마스킹이 수행되지 않아 크리덴셜이 콘솔에 노출될 수 있으므로 이를 주의하여 사용하여야 합니다.

또한 문자열 안에서 크리덴셜을 사용하는 경우 작은따옴표(‘)를 사용할 것을 권장합니다. 앞서 1. Pipeline Command Injection 에서 설명드렸듯이 큰따옴표(“)를 사용하는 경우 Groovy에서 표현식이 치환됩니다. 이로 인해 크리덴셜이 그대로 치환되어 쉘에 노출될 가능성이 상승하게 됩니다.

O: sh ‘curl -d “$SECRET” http://localhost:1234'
X: sh “curl -d ‘$SECRET’ http://localhost:1234"

따라서 빌드 과정에서 필요한 크리덴셜들은 CI에서 제공하는 기능을 통해 파일 및 환경변수로 저장하고, 접근 권한을 제한적으로 설정할 것을 권장합니다. 크리덴셜이 콘솔에 출력되는 것이 부득이한 경우에는 마스킹 함수의 이용을 고려해볼 수 있고, 마스킹 함수의 사용이 추가적인 취약점을 발생시키지 않도록 주의하여 사용해야 합니다.

3. 3rd Party Dependency

직접 개발한 소프트웨어가 아닌 라이브러리, 코드 스니펫 등의 서드파티 리소스를 사용하면 생산성을 높일 수 있습니다. 하지만 서드파티에 위협이 존재하면 의존성을 가지고 있는 다른 소프트웨어도 함께 영향을 받게 됩니다. CI/CD에서도 워크플로우, 액션 재사용, 플러그인, 라이브러리 등의 서드파티 리소스를 사용할 수 있기 때문에 이 때 발생할 수 있는 문제를 이해하고 주의하여 사용해야 합니다.

GitHub Actions

GitHub의 CI/CD 플랫폼인 GitHub Actions는 작업을 정의하는 워크플로우와, 함수와 비슷하게 자주 사용되는 작업을 정의할 수 있는 액션 등으로 구성되어 있습니다.

워크플로우는 uses: org/repo/.github/workflows/{name}.yml@{hash or tag}, 액션은 uses: org/repo@{hash or tag}와 같은 형태로 재사용이 가능합니다.

액션은 마켓 플레이스에 등록이 가능하고, GitHub에서 인증된 개발자를 대상으로 인증 마크를 부여하고 있습니다. 그러나 인증 마크가 액션의 보안성이 검증되었음을 의미하지 않는다는 점을 유의하여야 합니다.

또한 워크플로우와 액션은 권한이 있는 레포지토리에 대해서 재사용이 가능합니다. 재사용 시 다음과 같은 위협이 발생할 수 있습니다.

공격자가 배포한 악성 행위를 수행하는 워크플로우, 액션 재사용
재사용 중인 워크플로우, 액션의 레포지토리 권한을 공격자가 탈취

워크플로우, 액션을 통해 악성 스크립트의 실행이 가능하기 때문에 임의 명령 실행, 민감 정보 탈취 등의 피해가 발생할 수 있습니다. 이를 방지하기 위해 악성 행위를 하는지, 취약점이 존재하는지 검수한 뒤 신뢰할 수 있는 워크플로우, 액션만 사용해야 합니다.

워크플로우와 액션을 사용할 때는 태그가 아닌 커밋 해시를 사용해야 합니다.

O: uses: actions/setup-node@d86ebcd40b3cb50b156bfa44dd277faf38282d12
X: uses: actions/setup-node@v4.0.1

태그를 사용하는 경우 워크플로우, 액션의 레포지토리를 탈취한 공격자가 악성 스크립트를 커밋한 뒤, 기존의 태그를 지우고 악성 커밋에 동일한 태그를 설정할 수 있습니다. 기존의 태그가 새로운 악성 커밋을 가리키게 되므로 신뢰할 수 있던 워크플로우, 액션이더라도 악성 행위가 수행될 수 있습니다.

Jenkins 플러그인

https://plugins.jenkins.io/ 에는 약 1900개 이상의 Jenkins 플러그인이 등록되어 있습니다. Jenkins 플러그인에서는 꾸준히 취약점이 발생하고 있으며, jenkinsci 조직에 속한 플러그인이라도 유지보수가 되고 있지 않은 경우가 많습니다.

이를 Health Score 시스템을 통해 관리하는 것으로 보이지만 맹신해서는 안됩니다. 예를 들어, 9년 전부터 개발되지 않고 6년 전부터 동작하지 않는다는 이슈가 있는 Test In Progress 플러그인의 Health Score가 88%입니다.

jenkinsci 조직에서 관리중인 플러그인 레포지토리(https://github.com/jenkinsci/testInProgress-plugin)

Test In Progress 플러그인의 이슈(https://plugins.jenkins.io/testInProgress/issues/)

이처럼 서드파티 리소스를 사용할 때는 직접 관리할 수 없는 문제점이 발생할 수 있다는 점에 주의하고, 안전하게 사용하기 위해 검수 후 사용하는 것을 권고합니다. 또한 신뢰할 수 있는 것으로 알려져 있는 서드파티 리소스라도 언제든 취약점이 발생할 수 있으므로 주기적으로 확인하여 업데이트를 빠르게 적용해야 합니다.

Security hardening

1. Controller Isolation

CI는 Cloudbees, TeamCity와 같이 클라우드에서 호스팅하는 CI 컨트롤러를 사용할 수도 있으나, 다수의 기업에서는 CI 컨트롤러를 self hosting 하는 경우가 많습니다. 특히 오픈소스 Jenkins를 CI로 사용하는 기업의 경우에는 AWS 인스턴스에 Jenkins 서버를 올려 사용하거나, On-premise 서버에서 Jenkins 컨트롤러를 띄워 사용합니다. 이처럼 On-premise CI를 운영할 때에는 배포 환경과 서비스의 기능에 따라 노드를 분리 운영하는 것이 보안성 유지에 매우 중요합니다.

컨트롤러와 에이전트 노드 분리

CI는 빌드 파이프라인 태스크를 관리하는 컨트롤러 외에도 빌드 파이프라인이 실제로 실행되는 에이전트 노드가 있습니다. 컨트롤러는 에이전트에 실행될 파이프라인을 할당합니다.

컨트롤러

웹서버, 설정, 인증 등을 처리하고 CI 파이프라인 태스크를 에이전트에 할당하는 서비스

에이전트

빌드 파이프라인이 실행되는 환경

만약 컨트롤러와 에이전트가 같은 노드에서 실행된다면 에이전트 내의 빌드 파이프라인에 취약점이 발생했을 때에 컨트롤러의 권한으로 임의 코드를 실행할 가능성이 있습니다.

예를 들어 Jenkins는 에이전트를 별도로 설정하지 않은 경우에 기본적으로 빌트인 노드를 사용하여 빌드 파이프라인을 실행하도록 설정되어 있습니다. 이 빌트인 노드는 Jenkins 컨트롤러가 실행되는 노드이며, 이를 빌드 파이프라인에 사용한다는 것은 컨트롤러와 에이전트가 같은 환경에서 실행됨을 의미합니다. 따라서 Jenkins를 에이전트 노드 설정없이 기본 빌트인 노드로 사용한다면, 빌드 파이프라인에 취약점이 발생했을 때 Jenkins 자체에도 문제가 생길 수 있습니다.

따라서 취약점의 영향력을 완화하기 위해 컨트롤러와 에이전트 노드를 분리해야 합니다. 실제로 Jenkins에서도 이와 같은 이유로 빌트인 노드를 사용하는 것을 지양하라고 권고하고 있습니다.

배포 환경 별 노드 분리

개발 빌드와 운영 빌드가 하나의 컨트롤러에서 동작한다면, 개발 파이프라인에서 결함이 발생했음에도 불구하고 운영 파이프라인에 까지 영향을 미칠 수 있습니다.

예를 들어 개발 파이프라인에서 원격 코드 실행(Remote Code Execution, RCE) 취약점이 발생하여 Jenkins 컨트롤러의 권한으로 임의 코드를 실행한다면, 운영 파이프라인의 빌드 스크립트를 수정하여 서비스가 제대로 배포되지 않게 하거나 취약점이 있는 옛 버전의 서비스를 배포하는 등 실제 운영되고 있는 서비스에 치명적인 영향을 미칠 수 있습니다. 이처럼 개발 빌드와 운영 빌드가 하나의 컨트롤러에서 동작한다면, 개발 파이프라인에서 결함이 발생했음에도 불구하고 운영 파이프라인에 까지 영향을 미칠 수 있습니다.

이를 방지하기 위해 컨트롤러와 에이전트 노드를 분리할 뿐 아니라, CI 컨트롤러를 배포 환경 별로 분리해야 합니다.

2. Signing Container Image

일반적인 CD는 빌드 이미지가 허용된 이미지 레포지토리에 업로드되면, 어떠한 검증없이 업로드된 이미지를 자동 배포하는 경우가 많습니다. 그러나, 이러한 구조는 이미지 레포지토리와 CD 서비스가 서로 다른 주체로 관리됨에도 불구하고 서로를 완전 신뢰하여 둘 중 하나의 컴포넌트만 보안 결함이 발생하더라도 곧장 운영 서버 배포의 결함으로 이어질 수 있습니다.

그렇다면 공격자가 빌드 이미지 레포지토리에 이미지를 업로드할 수 있는 권한을 가졌다면, 운영 환경에 공격자의 이미지가 배포되는 것을 막기 위해 어떤 조치를 할 수 있을까요?

빌드 이미지가 정상적인 CI 파이프라인에서 만들어졌고, 변경되지 않았음을 검증하기 위해 디지털 서명을 사용할 수 있습니다.

출처: https://upbitcare.com/academy/education/blockchain/94

빌드 파이프라인의 모든 과정이 끝나고, 이미지 레포지토리에 빌드된 이미지를 업로드하기 전에 비밀키를 사용하여 이미지에 서명합니다. 이 때 사용하는 비밀 키는 여타 크리덴셜과 마찬가지로 CI 에서만 사용할 수 있도록 보호해야 합니다. 이후 배포 과정에서 공개키를 사용해 이미지의 유효성을 검증한 뒤, 검증에 성공한 경우에만 배포하고 실패하면 배포되지 않도록 하고 이를 즉각적으로 인지할 수 있도록 모니터링하는 것을 권고합니다.

이처럼 빌드 이미지 레포지토리와 CD 서비스가 서로 신뢰하지 않고, 검증하는 구조로 변경하면 공격자가 이미지 레포지토리의 업로드 권한을 탈취했다하더라도 정상적으로 CI를 통해 빌드되지 않은 이미지는 운영 서버에 배포되지 않아 공격의 영향을 최소화할 수 있습니다.

3. Immediate updates

CI 서비스도 여타 서비스와 마찬가지로 지속적으로 취약점이 발견되고 있습니다. 이러한 취약점은 대부분 Security Advisories를 통해 패치된 버전과 함께 공개됩니다.

만약 기업의 CI 도메인에 임의의 외부 공격자가 접근할 수 있다면, 알려진 1 day 취약점을 이용하여 공격을 시도할 수 있습니다. 올해 1월 24일에 공개된 CVE-2024–23897 취약점을 예로 들면, Jenkins를 CI로 사용하고 있는 기업이 최신 버전으로 업데이트 하지 않은 경우에 CI에 접근할 수 있는 공격자라면 누구나 해당 취약점을 악용하여 Jenkins 컨트롤러 노드의 모든 파일시스템을 읽을 수 있습니다. 이 외에도 작년에 큰 이슈가 되었던 JetBrains TeamCity의 원격 코드 실행이 가능한 CVE-2023–42793 등 CI에 대한 취약점은 지속적으로 공개되고 있을 뿐만아니라 공개된 취약점은 Proof of Concept (PoC) 코드도 함께 공개된 경우가 많기 때문에 공격 난이도가 상당히 낮습니다.

따라서 공개된 취약점을 이용한 공격에 노출되지 않도록 패치 버전이 배포되는 즉시 업데이트해야 합니다.

4. Access Controls in CI Controller

CI 컨트롤러에서는 에이전트 등록이나 빌드 파이프라인 등록 및 관리를 주로 담당합니다. 이에 따라 CI 컨트롤러에 대한 접근 제어도 필요한 사람에게만 한정적으로 접근할 수 있도록 설정해야 합니다. 각 컴포넌트에 접근할 수 있는 권한을 세분화하고, 최소한의 권한만 부여하는 것은 제로트러스트 관점의 보안 모델을 영위하기 위해서도 상당히 중요한 일입니다.

CI 컨트롤러는 빌드 파이프라인을 관리하는 관리자가 주로 접근하고 사용하므로, 일반 개발자에게는 컨트롤러에 대한 접근 권한이 필요하지 않은 경우가 많습니다. 따라서 CI 컨트롤러에 직접 접근이 필요한 사람에게만 권한을 부여하는 것이 보다 안전하게 CI를 관리하는 방법입니다.

또한, 기업과 관계없는 외부자의 접근을 차단하기 위해 네트워크 단의 접근 제어를 활용하기도 합니다. CI 도메인을 통해 컨트롤러에 접근가능하다면, 공개된 1-day 취약점이나 알려지지 않은 0-day 취약점을 통해 외부의 공격자가 공격을 시도할 가능성이 있으므로 내부망에서만 CI 컨트롤러에 접근 가능하도록 제한하는 것을 권장합니다. 설정 미흡으로 인해 CI 컨트롤러가 외부에 노출되는 경우를 미연에 방지하기 위해 외부 위협을 탐지할 수 있는 모니터링 툴을 사용할 수도 있습니다. (예, Xint | Exposure Management Platform )

마치며

지금까지 CI/CD 를 이용하면서 발생할 수 있는 위협과 대응 방안에 대해 알아보았습니다.

CI 파이프라인을 직접 작성하는 측면에서는 개발자나 소스코드 저장소 등 타 컴포넌트에서 전달되는 입력을 환경변수화하거나 상황에 맞는 Builder를 사용하여 입력이 직접 CI 에이전트에서 실행되지 않게 해야합니다. 또한, API key와 Private Key 등이 빌드 파이프라인에서 필요할 때에도 CI에서 제공하는 기능을 통해 파일이나 환경 변수 등을 통해 관리해야 합니다. 이 외에도 CI 파이프라인 작성 및 관리의 편의를 위해 도입하는 다수의 서드파티들은 생각외로 검증되지 않은 경우가 많아 도입 전에 보안 점검을 거치는 것이 중요합니다.

이처럼 CI는 내부에서 활용되는 도구라는 인식으로 인해 외부에 노출되는 서비스에 비해 상대적으로 낮은 보안성을 갖거나, 공격 표면이라고 생각하지 못하여 놓치는 경우가 많습니다. 그러나 모든 인프라가 서로 간의 상호작용을 신뢰하지 않는 제로 트러스트 구조를 구축하기 위해서 서비스 배포에 핵심적인 파이프라인을 담당하는 CI/CD 또한 높은 수준의 보안성을 가질 수 있도록 앞서 언급한 고려사항들을 적용하고, CI/CD 파이프라인 관련 PR에 대하여 보안적 검토를 고려해야 합니다.

본 포스팅을 통해 보안 요소를 서비스 배포 프로세스에 적용하여 DevSecOps를 구축함으로써 효율적이면서도 안전한 배포 프로세스를 도입하는데에 도움이 되었으면 합니다.

Reference

About Theori Security Assessment

티오리 Security Assessment 팀은 실제 해커들의 오펜시브 보안 감사 서비스를 통해 고객의 서비스와 인프라스트럭처를 안전하게 함으로써 비즈니스를 보호합니다. 특히, 더욱 안전한 세상을 위해 난제급 사이버보안 문제들을 해결하는 것을 즐기며, 오펜시브 사이버보안의 리더로서, 공격자보다 한발 앞서 대응하고 불가능하다고 여겨지는 문제를 기술중심적으로 해결합니다.

Security Assessment팀의 오펜시브 보안 감사 서비스에 대해 더 궁금하시다면? contact@theori.io 로 문의 바랍니다.