Xygeni 로고 화이트
무료로 시작
데모 예약

무슨 문제가 생길 수 있을까요? CI/CD pipelines?

차례

꼭 읽어야 할 게시글

최근 관심 있는 게시물

지속적 통합 및 지속적 배포CI/CD) pipeline자동화는 현대적인 방식으로 소프트웨어를 개발하는 모든 소프트웨어 조직의 기반입니다. 자동화는 강력한 기능을 제공하지만, 대부분의 개발자는 자동화에 수반되는 책임감을 간과합니다.

개발자네, 저희가 가져갑니다. CI/CD 보안 진지하게 검토하고 코드 관리자를 강력하게 관리하세요. commit합병 전의 일자리 및 pipeline이러한 시스템은 고위 직원들이 관리하며, 기밀 유출을 방지하는 책임을 맡고 있습니다. pipeline그리고 그 도구는 해당 분야에 정통한 사람들이 설치했습니다. 무엇이 잘못될 수 있겠습니까?

개발자님께, CI/CD 시스템은 복잡합니다. 넓은 공격 표면은 악의적인 행위자들을 끌어들입니다. 항상 경계하고 절대 과신해서는 안 됩니다.

기본 설정이 그대로 유지되는 경우가 있는데, 이는 해커들에게 절호의 기회가 됩니다. 이러한 설정에는 치명적인 취약점이 존재할 수 있습니다. CI/CD pipeline 소스, 시스템 구성 또는 프로세스 및 컨텍스트 주변 pipeline 그리고 그것이 어떻게 시작되는지.

이번 글에서는 악당의 입장이 되어 보겠습니다. 우리가 악당의 생각을 읽는다고 상상해 보세요. 엠3엠3N70 (메멘토 모리?) 그리고 늪지대 분노 어딘가 다크 웹 어딘가에, 아마도 비서구권 언어로 되어 있겠지만, 악이 전 세계에 퍼져 있다는 사실을 결코 간과해서는 안 됩니다.

 

옛날에는 참 쉬웠는데…

엠3엠3N70: 옛날 좋았던 시절로 돌아가 보자. 우리 사업은 정말 쉬웠지… 제로데이 취약점은 손쉽게 잡을 수 있었고, 앱은 취약점이 도처에 널려 있어서 악용하기 쉬웠고, 우리는 순식간에 횡적 이동도 할 수 있었어.

늪지대 분노젠장! 아직도 멍청한 사람들이 있긴 하지만, 세상은 변했어. 대기업들이 앱 보안에 굉장히 신경을 쓰거든.

엠3엠3N70네. 하지만 요즘 바보들은 개발자들이죠. 저희는 개발자들이 쓰는 도구를 그대로 사용하는 게 더 쉬웠어요. 특히 CI는 정말 보물창고 같아요! 클라우드 액세스 토큰 같은 것들이요. SCM 자격 증명, 프로덕션 데이터베이스 암호, SSH 개인 키, 다른 CI 사용자 자격 증명… 지루한 개발 작업에서 핵심 업무로 넘어가는 것은 오히려 쉬웠습니다.

소프트웨어 구축, 테스트 및 배포를 위한 자동화 CI/CD 해당 도구는 종종 명령에 비밀 정보를 단계적으로 전달해야 합니다. 그리고 이러한 비밀 정보가 유출되어 심각한 결과를 초래하는 경우가 많습니다.

Pipeline그들은 때때로 유출되는 비밀이 필요합니다.

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

어쩌면 좋았던 옛 시절은 Git 히스토리에서 무언가를 찾는 것이었을지도 모릅니다. .env (개발자가 추가하는 것을 잊었습니다) .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

GitHub 워크플로에서 사용되었습니다. .github/deploy.yaml 다음과 같은 내용이 포함되어 있었습니다.

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: 와! AWS 키가 제대로 작동했네! 먼저 앱에 사소한 변경 사항을 적용해 테스트해보고, 그 사람들이 눈치채지 못하는 사이에 함정을 추가했지. 대박! 정말 멋진 캠페인이었어…

악의적인 공격자는 AWS 키를 사용하여 악성코드가 포함된 변조된 애플리케이션을 업로드한 다음, 해당 자격 증명으로 배포 명령을 실행했습니다. 유출된 비밀 키와 그 안에 포함된 정보는 다음과 같습니다. pipeline"정말 대단한 캠페인이었어!"라는 말은 아마도 영화 '메멘토'가 불쌍한 피해자에게 엄청난 피해를 입혔다는 뜻일 겁니다.

Memento에서 알려주는 것은 AWS 액세스 키 예시처럼 비밀 정보가 유출된 경우, 해당 비밀 정보를 폐기(키를 주기적으로 갱신)해야 한다는 것입니다. 바로언제나 무언가가 있습니다. 노출 창 누출 사이 commit 그리고 비밀스러운 무효화; Git 기록을 다시 쓰는 것은 어렵습니다. (가장 강력한 권위주의 국가조차도 그러한 역사 왜곡을 시도했지만 소용이 없었고) 아마도 효과적이지 못했을 것이다 (우리 편이 비밀 유출이 담긴 저장소를 미리 복제해 두었을 수도 있다). commit). 즉시 키를 돌리고, 노출 시간 동안 대상 계정의 활동 로그를 읽으면서 기도하세요!

아마도 조직들은 장기 기밀 사용을 금지합니다 CI/CD pipelines그리고 임시 자격 증명으로 교체하세요. GitHub Actions에서 AWS 키를 사용한 이전 예시에서는 임시 자격 증명을 사용하는 것이 더 안전합니다. OpenID Connect(OIDC) 제공업체 작업에 필요한 단기 자격 증명을 얻기 위해서입니다.

늪지대 분노정말 운이 좋으셨네요! 예전에는 공개적으로 접근 가능한 S3 버킷에서도 하드코딩된 키가 포함된 스크립트를 유출하는 게 흔한 수법이었어요. 버킷 안의 객체들을 훑어보면서 grep 명령어로 흥미로운 것들을 찾아내기만 하면 됐죠.

때때로 배포에 사용되는 영역(이 예에서는 AWS S3 버킷)이 구성 오류(탐지되지 않음)로 인해 외부에서 읽기 가능하도록 열려 있는 경우가 있었습니다. 늪지대 분노 사용했던 방식은 대략 다음과 같았습니다.

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

해당 버킷은 보안 취약점을 자동으로 검사할 수 있는 프로비저닝 템플릿에서 생성되었을 가능성이 높습니다.

해당 도구의 기본 설정은 우리에게는 장난감과 같았습니다.

구체적인 예를 들어 설명해 보겠습니다. 젠킨스가장 인기 있는 CI 도구 중 하나입니다.

늪지대 분노Jenkins의 "보안 활성화" 체크박스를 기억하시나요? 얼마나 많은 조직들이 편의상 이 기능을 활성화하지 않았는지 아시나요? 그리고 그런 "누구나 무엇이든 할 수 있습니다"권한 조합을 기본값으로 설정하시겠습니까? 그리고 그런 성가신 Jenkins 플러그인들, 예를 들어... GitHub OAuth 플러그인설정을 담당한 사람이 "인증된 모든 사용자에게 읽기 권한 부여"와 "GitHub 저장소 권한 사용"을 모두 선택해서 우리가 그들의 모든 프로젝트에 접근할 수 있게 되었습니다.

(젠킨스, 당신을 예시로 들어서 미안해요 😉)

보안 원칙을 철저히 (심지어 중독될 정도로) 숙지하십시오. 그중 하나는 다음과 같습니다. 기본적으로 보안 설정됨 원칙: 제어 기능은 가능한 한 가장 안전한 설정으로 기본 설정되어야 합니다. 보안은 시스템에 내장되어야 합니다. CI/CD 도구와 pipeline처음부터 보안을 최우선으로 고려하여 설계해야 하며, 나중에 덧붙이는 고려 사항이어서는 안 됩니다. 하지만 사용자 친화성과 편의성은 보안과 상충되는 경우가 많습니다.

Jenkins의 경우 내장 인증 기능이 너무 취약합니다. Jenkins에 내장된 인증 메커니즘은 절대 사용하지 마세요.타사 메커니즘(SAML, LDAP, Google 등)과 역할 기반 권한 부여 전략(RBAC) 플러그인을 사용하는 것이 좋습니다. 그리고 사용 시 극도로 주의해야 합니다. admin 계정입니다.

직업과 관련된 모든 사항을 잘 처리하세요. pipeline Jenkins의 파일은 처리됩니다. 다른 파일들도 마찬가지입니다. 코드형 구성 플러그인 그리고 젠킨스 설정에 적용되는 구성 파일들이 있습니다.

자체 호스팅에서 이전 CI/CD 시스템을 클라우드 기반 SaaS 시스템으로 전환하면 조직 네트워크 내에서 수평 이동이 가능해지므로 잠재적 위험이 일부 제거되지만, 기존 내부 시스템과 외부화된 시스템 간의 외부 연결을 설정해야 하는 등의 새로운 위험이 추가됩니다. CI/CD 도구입니다.

조직은 노력해야 합니다cis경화 과정에서 적절한 주의를 기울입니다. CI/CD 가장 제한적인 설정부터 시작하여 필요한 최소한의 권한만 부여하면서 시스템을 점진적으로 개방합니다. pipeline 단계.

보안 설정 CI/CD 도구 개발은 복잡한 작업이 될 수 있습니다. 많은 도구에는 플러그인이나 확장 프로그램이 포함되어 있는데, 여기에 취약점이 많고 업데이트가 필요합니다.

이러한 복잡한 도구의 경우 보안 구성 오류를 탐지하는 스캐너나 벤치마크가 도움이 될 수 있습니다.

코드 삽입 pipeline 재미와 이익을 위한 명령

엠3엠3N70혹시 신뢰할 수 없는 코드 체크아웃을 사용해 보신 적이 있나요? 이러한 취약점이 있는 작업과 스크립트는 명령 주입 공격에 취약합니다.

이 섹션에서는 다음을 보여줍니다. pipeline 그 자체에 악의적인 공격자가 임의 코드 실행을 주입할 수 있도록 하는 코딩 오류가 있을 수 있습니다. pipeline 변경하지 않고 pipeline 출처 자체예를 들어 PR을 사용하는 경우

첫 번째 예시는 다음과 같습니다. 불행한 GitHub 워크플로:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

결합 pull_request_target 신뢰할 수 없는 PR을 명시적으로 체크아웃하는 워크플로 트리거는 저장소 손상으로 이어질 수 있는 위험한 관행입니다. 예시에서 불행하게도 다음과 같은 상황이 발생했습니다.

  • pull_request_target 이 이벤트는 기본적으로 외부 포크에서도 대상 저장소 및 대상 저장소 비밀에 대한 쓰기 권한을 가지며, PR의 대상 저장소 컨텍스트에서 실행됩니다.
  • 신뢰할 수 없는 저장소인 소스에서 PR 코드를 확인하세요.
  • PR이 관리하는 콘텐츠에 대해 작동할 수 있는 스크립트를 실행합니다. 예를 들어 다음과 같은 경우입니다. npm install예산 및
  • 트리거에 조건을 사용하지 않음 pull_request_target 이 이벤트는 PR에 '이 PR은 검토되었습니다'와 같은 레이블이 지정된 경우에만 실행됩니다(외부 사용자는 PR에 레이블을 지정할 수 없습니다).

두 번째 예시는 신뢰할 수 없는 입력(문제, 댓글 등)을 사용합니다. pull request)를 전달된 인수의 소스로 사용합니다. pipeline 표현식을 통한 명령입니다. 이것이 바로 그것입니다. pipeline OS 명령어 주입 취약점 버전입니다.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

실행 작업은 템플릿을 기반으로 임시 셸 스크립트를 생성합니다. $ 대체되어 셸 명령 주입에 취약해졌습니다. 가짜 GitHub 계정을 가진 공격자는 제목으로 이슈를 생성할 수 있습니다. a"; bad_code_goes_here;#그리고 쾅! 

늪지대 분노아, 저 사람들은 단순히 이슈를 제기하는 것만으로도 명령 주입 공격의 문을 열어준 거였군요…

GitHub Actions에는 코드 실행 취약점이 있었습니다. 예를 들어, 가지라 댓글이제 수정되었습니다. 읽어보세요. GitHub 워크플로에서 신뢰할 수 없는 입력값 사용 자세한 사항.

이 이야기의 교훈은 다음과 같습니다. 신뢰할 수 없는 출처에서 가져온 PR을 검토하지 않고는 절대로 체크아웃하거나 빌드하지 마십시오. 여기서 '신뢰할 수 없음'은 출처에 대한 엄격한 인증 절차가 없는 한, 잠재적으로 해킹당한 개발자 계정을 의미할 수 있습니다.

 

의도치 않은 악성코드 배포가 발생했습니다!

지속적인 배포 이는 자동화의 절정이지만, 적절한 승인 통제 장치가 부족하면 그 절정이 좌절될 수 있습니다. pipeline 흐름.

소스로부터의 완전 자동화 배포의 위험성 commit 운영 시스템에 대한 보안 취약점에는 악성 코드가 탐지되지 않고 운영 환경에 배포될 가능성뿐만 아니라 배포 과정의 오류로 인해 중단이나 장애가 발생할 가능성이 포함됩니다.

이러한 위험을 완화하기 위해 조직에서는 배포 프로세스에 "하드 브레이크"를 구현하는 것이 권장되는 경우가 많으며, 이는 다음과 같은 사항을 요구합니다. 인간의 승인 최종 환경에 릴리스가 배포되기 전입니다.

그들은 문을 닫고 있어요

늪지대 분노: 그 즐거운 기본 비밀번호들 CI/CD 도구들이 삭제되고 있습니다. 접근하려면 /var/lib/jenkins/secrets/initialAdminPassword 이제는 더 이상 필요 없는 방식입니다. 수많은 도구들이 2FA(이중 인증) 기능을 제공하고 있으며, 코로나19 팬데믹으로 인해 2FA가 널리 보급되었고, 심지어 가장 게으른 개발자조차도 이를 사용하고 있습니다!

엠3엠3N70우리는 2FA(이중 인증)와 싸우고 있지만, 그렇게 쉬운 일은 아닙니다. 2FA를 무력화하기 위한 스피어 피싱 공격은 쉽지 않습니다. “Scatter Swine”은 Twilio와 협력했습니다.WebAuthn 키를 사용하는 경우에는 훨씬 더 어렵습니다. 적어도 시도해 볼 수는 있습니다. MFA를 우회하기 위해 쿠키를 훔치세요하지만 개발자의 영역에 접근해야 합니다.

다중 요소 인증(MFA)은 인증 비밀 정보 유출 위험을 줄이는 데 있어 올바른 방향으로 나아가는 좋은 단계입니다. 대부분의 최신 DevOps 도구는 MFA를 지원합니다. 또한 WebAuthn/U2F 환경에서 인증 키를 사용합니다(참조). FIDO2 프로젝트)는 제대로 관리한다면 DevOps에서 다단계 인증(MFA)을 위한 최선의 선택일 수 있습니다.

늪지대 분노데브옵스 담당자들이 깨어나고 있어요. 그들은 "최소 권한 원칙"을 뼈저리게 믿고 있죠. 그리고 더 이상 코드만 짜는 사람들이 아니에요. 이제는 리뷰어들에게 딱 걸려들거든요.

사실, pipeline이제 저희 시스템은 몇 년 전보다 훨씬 더 강력해졌습니다. 취약한 동작과 스크립트가 제거되었고, 은밀하게 숨겨진 드로퍼까지 탐지할 수 있도록 추가적인 보안 테스트 단계가 적용되었습니다. commit우리가 탈취한 s와 소포들.

독자 여러분께 질문드립니다. 소스 코드에서 소프트웨어를 빌드하고 프로덕션 환경에 배포하는 과정은 위험한 작업일까요? 여러분의 DevOps 팀이 이러한 단계에 있다고 보십니까? 옛날 좋았던 시절 악당들을 위해서요?

최종 권고

어디서부터 시작해야 할까요? CI/CD pipeline에스?

여기서 첫 번째 권장 사항은 간단합니다. 신중하게 리뷰 pipelines (그들은) 임계 보안 문제를 위해 리소스(자원)를 검토해야 합니다. 검토는 비용이 많이 들지만 필수적이며 제대로 수행되어야 합니다. 검토자는 무엇을 살펴봐야 하는지 알고 있어야 합니다. 각 단계에서 오류를 확인해야 합니다.

자동화된 악성코드 스캐너를 갖춘 전문가 검토자들의 조합이 도움이 될 수 있을지도 모릅니다.

두 번째 권장 사항은 다음과 같습니다. 개발자들이 글을 쓰도록 교육하세요 pipeline보안을 유지하고 관리합니다.고려해야 할 사항:

  • 내부 서비스 및 클라우드 서비스와의 인증을 올바르게 처리하고, 장기간 보관해야 하는 자격 증명 관리의 번거로움을 피하는 방법.
  • 제한하는 방법 pipeline는 필요한 리소스 집합에만 접근할 수 있습니다. 최소 권한 원칙이 다시 한번 빛을 발합니다.
  • 만드는 방법을 단계별로 작성하는 방법 pipeline버전 고정처럼 재현 가능한 방식을 사용하고 명령 주입 취약점을 방지합니다.
  • 보안 관점에서 배포를 승인하는 방법(다른 방법도 있습니다!): 어떤 보안 방식을 사용해야 할까요? standards는 서로 일치해야 하며, 이에 상응하는 검사/게이트를 추가하는 방법은 무엇입니까? pipelines.

세 번째 권장 사항은 다음과 같습니다. 구성 CI/CD 시스템을 세심하게 관리하세요강력한 인증, 기본 비밀번호나 안전하지 않은 설정 사용 금지, 최소한의 권한 부여… 설치된 플러그인 및 확장 프로그램의 취약점을 주의 깊게 살펴보세요. 이는 향후 게시물에서 중점적으로 다룰 예정이니 기대해 주세요.

네 번째 권고사항은 다음과 같습니다. 레버리지를 활용하다 CI/CD pipeline보안 자동화를 위한 s소스 코드 분석 (SAST), 소스 구성 분석 (SCA), 기밀 정보 유출 스캔, 맬웨어 방지 도구, 컨테이너 보안 스캐너 또는 자동 런타임 탐지기(DAST 및 맬웨어)를 정기적으로 실행할 수 있습니다. pipeline그리고 귀 기관은 이를 시행할 수 있습니다. standard보안 스캐닝 관련 내용에 대하여 CI/CD.

이러한 도구들이 전문가 검토를 완전히 대체하는 것은 아니라는 점을 명심하십시오. 그렇지 않으면 잘못된 안도감을 가질 수 있습니다.

OWASP Top 10에 관심이 있으시다면, 최근에 나온 좋은 프로젝트가 있습니다. OWASP 탑 10 CI/CD 보안 위험.

면책 사항

(1) 이 게시물의 예시에서는 GitHub를 사용합니다. SCM클라우드 제공업체로는 AWS를, 그리고 GitHub Actions 또는 Jenkins를 사용합니다. CI/CD 도구일 뿐입니다. 다른 대안보다 약하거나 안전하지 않은 것은 아닙니다. 악의적인 의도는 전혀 없습니다! 이러한 도구들은 강력하며 적절하게 사용해야 합니다.

(2) 엠3엠3N70   늪지대 분노 등장인물들은 허구의 인물입니다. 실존 인물이나 단체(생존 또는 사망)와의 유사성은 순전히 우연의 일치일 뿐입니다… 하지만 정말 그럴까요?

더 읽으려면

sca-tools-software-composition-analysis-tools
소프트웨어 위험을 우선순위화하고, 해결하고, 보호하십시오.
무료 계정을 만드세요.
신용 카드가 필요하지 않습니다.
무료 회원 가입

소프트웨어 개발 및 제공을 안전하게 보호하세요

Xygeni 제품군과 함께

무료로 시작
제품 둘러보기를 해보세요
Xygeni 로고 화이트

© 2026 Xygeni. 모든 권리 보유.

링크 인 X 트위터 유튜브

제품

리소스

회사

이용약관