https://www.youtube.com/watch?v=Pkc-FQ00MB8
1. 이건 꼭 알아야 한다[^1]
[? 질문] DevSecOps는 무엇이며, DevOps와 무엇이 같고 무엇이 다른가[^2]
[= 답] DevOps와 DevSecOps는 모두 “더 빠른 시간에 더 많은 가치를 지닌 애플리케이션을 만들기 위한 자동화된 소프트웨어 라이프사이클과 빌트인 퀄리티”라는 공통 목표를 가지며, DevSecOps는 그 큰 틀(DevOps) 안에서 보안 정책의 자동화된 시행, 위협의 조기 탐지/예방/제어를 개발 수명주기 전반에 내재화하는 데 더 초점을 둔다.[^2]
[? 질문] DevSecOps를 도입하려는 조직은 “어디서부터 어떻게” 시작해야 하는가(특히 엔터프라이즈에서 결과를 측정/관리하며)?[^3]
[= 답] AWS 프로페셔널 서비스 관점에서는 **DevSecOps Assessment(현황 분석·수치화)**로 시작해, 그 결과로 액션 아이템 도출 → 비즈니스 목표와 정렬된 목표/기간/우선순위 정의(에픽 단위) → 스크럼 기반의 반복적 계획·개발·리뷰로 점진 구현을 수행하고, 한 사이클로 끝내지 않고 다시 Assessment로 돌아가 지속 반복/개선한다.[^3]
[? 질문] “보안 때문에 개발을 못한다/생산성이 떨어진다”는 피드백이 나오지 않으면서도, 개발 단계에서 보안 테스트를 자동화·운영하려면 어떤 구조가 도움이 되는가?[^4]
[= 답] PR(풀 리퀘스트) 생성/업데이트/삭제 이벤트를 기점으로 EventBridge + Step Functions로 정적 애플리케이션 보안 테스트(SAST) 워크플로우를 오케스트레이션하고, Lambda로 SonarQube 프로젝트 생성/결과 분석/PR 코멘트·승인상태 업데이트를 수행하며, CodeBuild로 테스트 실행·상태 폴링(예: 10초마다)·재실행을 자동화하고, 결과는 Security Hub(통합 뷰)와 SNS(빠른 피드백)로 전달하며, PR 병합/삭제 시 테스트 환경을 자동 정리하여 운영 부담을 줄인다.[^4]
2. 큰 그림[^5]
이 발표는 조직이 레거시에서 클라우드로 마이그레이션하거나 애플리케이션을 클라우드 네이티브로 현대화하는 과정에서, DevSecOps를 어떻게 정의하고, 현실 조직에서 어떤 단계로 도입 여정을 설계하며, 실제로 CI/CD 파이프라인에 보안 테스트를 자동화하면서 발생하는 문제를 AWS 관리형 서비스 조합으로 개선하는 방법을 설명한다.[^5]
- DevOps/DevSecOps의 목표는 동일하며, 목표 달성을 위해 자동화된 소프트웨어 라이프사이클과 빌트인 퀄리티(품질 내장)가 필요하다고 강조한다.[^2]
- DevSecOps는 개발 수명주기 전반에 보안 테스트/정책을 초기부터 포함시키고, 위협 탐지·예방·대응·자동화를 통해 통제력을 얻는 접근으로 설명된다.[^6]
- 도입 방법론(Assessment→목표/범위→반복적 구현)과 함께, PR 이벤트 기반으로 EventBridge·Step Functions·Lambda·CodeBuild·SonarQube·Security Hub·SNS를 엮어 SAST를 자동화한 데모를 통해 “생산성 저하” 문제를 줄이는 구현 예를 제시한다.[^7]
3. 하나씩 살펴보기[^8]
3.1 세션 소개와 대상: “DevSecOps/DevOps 파이프라인을 이미 해본 사람”을 전제로 함[^8]
발표자는 AWS 프로페셔널 서비스 팀의 애플리케이션 아키텍트로서, 고객이 AWS 서비스를 잘 활용할 수 있도록 돕는 역할을 한다고 소개한다.[^8] 이어서 요즘 어디서나 DevOps 이야기가 빠지지 않으며, 그 연장선에서 화제가 되는 “DevSecOps(발표에서 ‘Dev 3…’로 발음되지만 맥락상 DevSecOps)”를 오늘 다룰 것이라고 말한다.[^9]
또한 이 세션은 기초 입문이 아니라, 이미 AWS 환경에서 워크로드를 운영해 봤거나 DevOps를 위한 CI/CD 파이프라인을 구축해 본 사람을 대상으로 진행한다고 전제한다.[^10] 즉, “DevSecOps가 무엇인지”만 정의하는 데서 끝나는 것이 아니라, 실제 프로젝트에서 어떻게 접근하고 무엇을 겪었는지(여정/문제/개선)까지 공유하는 구성이다.[^10]
발표 흐름은 크게 다음 순서로 안내된다.[^11]
- DevOps와 DevSecOps 개념 정리[^11]
- 고객 프로젝트에서 DevSecOps 여정을 어떻게 접근했는지 단계 공유[^11]
- 여정 중 겪었던 챌린지와 지속 개선 팁[^11]
- 데모로 노하우를 보여주며 마무리[^11]
3.2 “현대화(Modernization)”의 맥락에서 DevOps/DevSecOps가 왜 필수가 되었는가[^12]
발표는 “DevSecOps는 무엇인가”를 묻기 전에, 먼저 고객들의 큰 흐름을 배경으로 깐다.[^12] 많은 고객이 기존 레거시 환경의 시스템을 클라우드로 마이그레이션하고 있으며, 더 나아가 기존 애플리케이션을 현대화하려는 추세가 강하다고 말한다.[^12]
여기서 “현대화”는 단순히 인프라를 옮기는 것만이 아니라, 애플리케이션을 클라우드 네이티브하게 구축하여 비즈니스 요구사항을 빠르게 반영할 수 있게 만드는 목적을 갖는다고 설명한다.[^13] 이를 위해 컨테이너나 서버리스처럼 더 빠르게 배포 가능한 성향의 새로운 기술을 선택하게 되며, 애플리케이션 성격에 따라 적합한 아키텍처를 선택해야 한다는 단서를 붙인다.[^14]
그런데 발표자는 “새로운 아키텍처/기술 말고 또 무엇이 필요할까?”라는 질문을 던지고, 그 답으로 DevOps를 제시한다.[^15]
[? 질문] 클라우드 네이티브 현대화를 위해 컨테이너/서버리스 같은 신기술만 도입하면 충분한가?[^15]
[= 답] 아니다. 더 빠른 가치 전달을 위해서는 DevOps, 더 나아가 현대화 추세에서는 DevSecOps가 선택이 아닌 필수로 자리잡았다고 본다.[^16]
이 지점에서 DevOps와 DevSecOps를 “공통 목표는 같지만 초점이 다르다”는 프레임으로 정리하며 다음 파트(정의)로 넘어간다.[^17]
3.3 DevOps 정의: 기술만이 아니라 “문화·철학·방식·도구”의 조합[^18]
발표에서 DevOps는 “애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화, 철학, 방식, 도구의 조합을 모두 포함한다”고 정의한다.[^18] 여기서 발표자가 특히 강조하는 메시지는 “DevOps는 단순한 기술(파이프라인 자동화) 보유 여부로 판단할 수 없다”는 점이다.[^19]
- DevOps는 자동화된 배포 파이프라인만으로 ‘잘 하고 있다’고 보기 어렵다.[^19]
- DevOps를 하려면 “우리가 일을 하는 방식”부터 변화가 필요하다는 의미라고 말한다.[^19]
즉, 도구로 CI/CD를 깔았더라도, 조직의 협업 방식·프로세스·책임 분배·품질 내장 방식이 함께 바뀌지 않으면 DevOps의 취지(빠른 가치 전달)가 달성되지 않는다는 맥락을 깔아둔다.[^19]
또한 DevOps/DevSecOps의 공통 목표를 “더 빠른 시간에 더 많은 가치를 지닌 애플리케이션을 만들어 내는 것”이라고 정리하고, 이를 위해 “개발 과정에서 내부 퀄리티가 보장되도록 빌트인 퀄리티가 내장된 자동화된 소프트웨어 라이프사이클이 필요하다”고 설명한다.[^20] 그리고 이 공통 목표 위에서 DevOps는 어느 영역에, DevSecOps는 어느 영역에 더 초점을 맞추는지가 다르다고 이해하면 된다고 연결한다.[^21]
3.4 DevSecOps 정의: DevOps의 연장선에서 “보안 정책의 자동화된 시행”을 문화/방식/도구로 달성[^22]
발표는 “그럼 DevSecOps는 무엇일까요?”라고 전환하며, DevSecOps가 DevOps와 “크게 다르지 않다”고 먼저 못 박는다.[^22] 다만 DevOps의 연장선상에서, 보안 정책의 자동화된 시행을 달성하기 위해 기술력과 더불어 문화·방법·도구를 모두 포함한다고 설명한다.[^22]
정리하면, DevSecOps는 DevOps라는 큰 틀 안에서 “보안 영역을 중요하게 다루는 것”으로 제시된다.[^23] 궁극적으로 DevSecOps가 이루고자 하는 바는 자동화된 소프트웨어 라이프사이클 위에서 다음 능력을 향상시키는 것이라고 한다.[^24]
- 위협을 자연스럽게 탐지[^24]
- 탐지된 위협을 사전에 예방[^24]
- 위협을 제어(통제)할 수 있는 능력 향상[^24]
이후 발표자는 “DevSecOps를 통해 이루고자 하는 것”을 조금 더 상세히 쪼개서 4가지 필요 요소로 제시한다.[^25]
3.5 DevSecOps가 지향하는 4가지 구성요소: 더 빠른 보안 테스트, 예방 우선순위, 반응형 제어, 전 과정 자동화[^25]
발표자는 기존 DevOps가 “민첩한 개발”에 초점이 컸다면, DevSecOps는 “위협 탐지·예방을 자동화해 관리함으로써 통제권을 얻는 것”을 목적으로 한다고 대비한다.[^25] 이를 위해 필요한 것들을 4가지로 나눈다.[^26]
-
더 빠른 테스트가 필요하다.[^26]
- 여기서 테스트는 “보안과 관련된 테스트”를 의미한다고 명시한다.[^26]
-
예방 우선순위를 선정해야 한다.[^27]
- 아무리 많은 테스트를 수행하더라도, 결과에 따른 우선순위를 지정할 기준이 필요하다고 말한다.[^27]
- (즉, ‘다 고치자’가 아니라 무엇을 먼저 막고 고칠지의 기준이 필요하다는 문제의식이다.)[^27]
-
반응형 제어를 통한 대응이 필요하다.[^28]
- 자동화된 지속적 테스트는 위협이 큰 문제가 되기 전에 식별하는 데 도움이 되며,[^28]
- 식별 이후에 보안 위협에 대응할 수 있도록 프로세스와 도구를 제공해야 한다고 말한다.[^28]
-
마지막으로 이 모든 과정은 매뉴얼이 아닌 자동화가 필요하다.[^29]
- 보안 제어 및 테스트는 개발 수명주기의 모든 곳에 “초기부터” 포함되어야 한다고 강조한다.[^29]
이 네 가지를 종합하면, “개발한 애플리케이션을 보안 관점에서 빌트인 퀄리티(품질 내장)로 만들기 위한 라이프사이클을 생성하는 것”이라고 결론을 내린다.[^30]
[!IMPORTANT] 빌트인 퀄리티의 핵심 맥락[^20]
발표는 DevOps/DevSecOps를 ‘속도 vs 보안’의 제로섬으로 보지 않고, 자동화된 라이프사이클에 품질(보안 포함)을 “내장”해 더 빠른 가치 전달을 가능케 하려는 관점으로 전개한다.[^20]
3.6 DevSecOps를 “본격적으로” 하려면 무엇을 봐야 하나: Security of the pipeline vs Security in the pipeline[^31]
발표자는 DevSecOps를 시작할 때 살펴볼 항목이 다양하지만, 오늘은 크게 2가지를 말하겠다고 한다.[^31]
- Security of the pipeline: 파이프라인 자체의 보안[^31]
- Security in the pipeline: 파이프라인 워크플로우를 통해 관리되는 소프트웨어 보안 전반[^31]
발표는 두 개념을 예로 구분한다.[^32]
- 자동화된 CI/CD 파이프라인을 IaC 기반으로 생성했다면,
- “코드의 보안”과
- 파이프라인에서 사용하는 “암호화 키 등”은 Security of the pipeline 범주에 포함된다고 든다.[^32]
- 그 파이프라인 위에 SonarQube 같은 도구를 연계해 애플리케이션 취약점을 파악하는 항목은 Security in the pipeline에 포함된다고 말한다.[^33]
다만 이 두 항목에는 하위 항목이 굉장히 많고, 오늘은 전부 다루지 않을 예정이라고 선을 긋는다.[^34] 이후 발표는 “전반 개요는 봤고, 이제 실제 조직에서 어디서부터 시작하나?”로 넘어간다.[^35]
3.7 DevSecOps 체계가 없는 조직에서의 시작점: 엔터프라이즈는 “프로젝트”와 “측정 가능한 결과”가 필요[^35]
발표자는 DevSecOps가 잡혀 있지 않은 조직에서 이를 적용하려면 “어디서부터 어떻게 시작해야 할까”를 문제로 제기한다.[^35] 특히 엔터프라이즈 레벨에서는 DevOps/DevSecOps 도입이 선언으로 끝나지 않고, 실제로 관련 프로젝트가 진행되어야 하고, 그에 따른 결과가 필요하다고 말한다.[^36]
그러면 자연스럽게 “그 결과를 어떻게 측정할 수 있나?”가 다음 질문이 된다.[^37]
[? 질문] DevSecOps 도입 프로젝트의 “결과”를 무엇으로, 어떻게 측정할 수 있는가?[^37]
[= 답] AWS 프로페셔널 서비스 팀은 DevSecOps 여정의 시작을 DevOps/DevSecOps Assessment로 잡고, 현 상황을 분석하고 수치화해 그 기반 위에서 개선 액션을 도출하며, 이후 재평가에도 지표로 활용한다.[^38]
이제부터 발표는 구체적인 “여정의 단계(프로세스)”를 1단계부터 설명한다.[^39]
3.8 (1단계) DevOps/DevSecOps Assessment: 인터뷰→분석→채점→레이더 차트→액션 아이템 도출[^39]
발표에 따르면 1단계인 Assessment에서는 조직 문화, 보안, 아키텍처 등 여러 관점에서 인터뷰를 진행하고 그 결과를 분석한다.[^39] 분석 결과는 채점 기준에 따라 “수치화된 점수”로 도출되며, 이를 통해 현재 상황을 객관적으로 평가할 수 있다고 말한다.[^40]
이 점수는 단지 ‘진단’에서 끝나는 것이 아니라, 추후 다시 DevSecOps를 수행했을 때 “얼마나 발전했는지”를 알 수 있는 지표로도 사용할 수 있다고 한다.[^41] 또한 평가된 현재 상황으로부터 다음 단계로 나아가기 위한 “Todo list 같은 액션 아이템”이 함께 도출된다고 설명한다.[^42]
Assessment를 실제 수행하면, 각 카테고리별 수치화된 레이더 차트와 현재 상황, 그리고 액션 아이템이 도출된다는 산출물을 언급한다.[^43] (화면 예시를 보여주며 “보시는 것처럼”이라고 말하는 부분이 있어, 실제 발표 슬라이드에 레이더 차트 예시가 있었음을 전제한다.)[^43]
3.9 (2단계) 목표와 범위 정하기: 비즈니스 목표 정렬, 기간 지정, 액션 아이템을 에픽으로 묶고 큰 우선순위 결정[^44]
2단계는 “목표와 범위를 정하기”다.[^44] 발표자는 Assessment 결과를 바탕으로 비즈니스와 일치하는 상세 목표를 정하고, 목표 달성 기간을 지정한다고 말한다.[^44]
또한 Assessment에서 노출된 액션 아이템들을 “함께 묶어서 실행할 수 있도록” 분류하고, 목표 기간 동안 개선할 범위를 정한다고 한다.[^45] 이때 분류 단위가 “에픽(Epic)”으로 제시된다.[^46]
예시로, “두 달 동안 빠른 서비스 런칭을 위해 개발 속도 향상과 기본적인 취약점 스캐너를 목표로 설정”했다면, 분류된 에픽의 큰 우선순위가 정의될 수 있다고 설명한다.[^46]
여기서 발표자가 강조하는 우선순위 원칙은 다음과 같다.[^47]
- 우선순위는 개발자 관점/운영자 관점의 필요가 아니라, 조직의 목표·비즈니스 목표와 일치하는 것이 우선되어야 한다.[^47]
그리고 우선순위에 따라 파이프라인 라이프사이클 자동화, 정책 분석 테스트 자동화 등이 다음 단계(계획·개발·리뷰)에서 순차적으로 구현될 것이라고 연결한다.[^48] 또한 2단계에서는 “큰 우선순위”를 정하고, 에픽 하위의 많은 액션 아이템 레벨의 상세 우선순위 설정은 3단계에서 이루어진다고 구분한다.[^49]
3.10 (3~5단계) 계획-개발-리뷰의 반복: 스크럼으로 2개월 목표를 2주 스프린트×8회로 쪼개 점진적으로 구현[^50]
발표는 3단계부터 5단계까지를 “실제로 설정한 목표를 달성하기 위해 계획하고 개발하고 리뷰하는 과정”이라고 설명하며, 반복적인 실행이 필요하다고 말한다.[^50]
DevOps의 문화적 부분까지 모두 적용하려면 작은 단위로 점진적으로 반복하면서 지속적 발전을 위한 “흐름 형성”이 필요하다고 말한다.[^51] 그 이유로 “파이프라인도 하나의 프로덕트라는 관점”에서 지속 발전이 필요하기 때문이며, ‘한 번에 짠 하고 만들고 끝’이 아니라 협업 기반으로 계속 개선해야 한다고 말한다.[^52]
이 반복을 수행하기 위해 스크럼 같은 개발 방법론을 사용한다고 하고,[^53] 스크럼을 “애자일 개발 방법론 중 하나로 작은 단위로 지속적으로 개발할 수 있는 프레임워크”라고 설명한다.[^53]
앞서 든 “2달 목표” 예시를 스크럼으로 진행한다면, 2달을 2주 단위 스프린트로 나눠 총 8번의 계획-개발-리뷰를 반복함으로써, 지속적으로 개발되는 내용이 비즈니스 목표와 방향을 맞춰가게 된다고 설명한다.[^54]
[!TIP] “파이프라인도 프로덕트”로 본다는 뜻[^52]
파이프라인을 한 번 구축하면 끝나는 도구로 보지 않고, 요구사항 변화·보안 요구·운영 피드백에 따라 계속 기능이 추가/조정되는 “제품”처럼 백로그를 두고 개선해야 한다는 관점이다.[^52]
3.11 점진적 파이프라인 발전 예시: CodeCommit → 트리거 → CodeBuild(빌드/테스트) → CodeDeploy(배포) → 멀티계정/로깅/보안/외부툴 연계[^55]
발표자는 “점진적 개발을 통해 파이프라인을 프로덕트로서 지속 발전시켜야 한다”며 예시 흐름을 보여준다.[^55] 시작점은 “최초 로컬 개발 환경에서 진행하던 내용들을 공통 CI/CD 파이프라인으로 만들어 나가려 한다”는 상황이다.[^55]
발표가 제시하는 단계적 확장 예시는 다음과 같은 순서로 전개된다.[^56]
- 개발팀이 공통으로 사용할 수 있는 AWS CodeCommit 리포지토리를 구성한다.[^56]
- 리포지토리에 커밋/변경이 발생하면 파이프라인이 트리거되도록 설정한다.[^56]
- 이후 AWS CodeBuild로 자동 빌드·테스트 단계를 추가한다.[^57]
- 마지막으로 AWS CodeDeploy로 배포 단계까지 추가한다.[^57]
- 그 다음에는 멀티 어카운트 전략을 이용한 배포 전략을 취할 수 있고,[^58] 로깅을 강화하거나 보안 요소를 추가할 수 있다.[^58]
- SonarQube 같은 외부 툴을 연계할 수도 있다.[^58]
발표자는 즉시 “이 흐름이 정답은 아니며” 구현 순서는 선택이라고 말한다.[^59] 파이프라인을 먼저가 아니라 보안 요소부터 구성할 수도 있다고 한다.[^59] 다만 중요한 메시지는 “처음부터 완벽한 파이프라인의 큰 그림을 가지고 있는 곳은 없다”는 것이고,[^60] 필요한 것들을 지속적으로 발전시켜야 한다는 점을 기억하라고 강조한다.[^60]
3.12 한 사이클로 끝이 아니다: 비즈니스 변화→파이프라인 변화→다시 Assessment로 반복 개선[^61]
발표자는 “처음 만든 파이프라인은 절대 완벽할 수 없다”고 재강조한다.[^61] 심지어 “보안을 하더라도 완벽해질 수 없다”고 말하는데, 그 이유는 비즈니스 요구사항이 계속 변화하고 개발 등(개발 방식/구현)이 변화하기 때문이라고 설명한다.[^62]
따라서 파이프라인도 지속적으로 변화해야 하며,[^63] 1단계부터 5단계까지 한 사이클을 진행해도 끝이 아니라, 더 나은 문화와 파이프라인을 만들고 전체 사이클을 개선하기 위해 1단계(Assessment)부터 지속 반복해야 한다고 결론내린다.[^63]
이로써 첫 발표자(고원경)는 DevSecOps 여정(정의→도입 단계)을 마무리하고, 다음 발표자(김대곤)가 고객 여정에서 겪은 문제들과 개선 방법(데모 포함)을 이어간다고 소개한다.[^64]
3.13 (문제 제기) “Shift Security Left”를 하다 보니 생긴 현실 문제: 통합, 결과 통합 뷰, 빠른 보안 피드백, 도구 도입 의사결정 시간/비용[^65]
두 번째 발표자는 AWS 프로페셔널 서비스 팀의 클라우드 아키텍트로 자신을 소개한다.[^66] 그는 앞 발표자가 DevSecOps 여정을 설명했고, 자신은 여정에서 마주친 문제들과 지속 개선을 위해 했던 내용들을 공유하겠다고 말한다.[^67]
그가 제시하는 출발점은 “기존에는 운영 배포 전 혹은 검증 환경에서 보안 테스트 및 리뷰가 이루어졌다”는 상황이다.[^65] 하지만 이 방식은 문제를 발견하고 해결하기까지 시간과 비용이 많이 들기 때문에, “Shift Security Left” 개념을 바탕으로 가능한 빨리 보안 위험 요소를 제거하고자 노력했다고 말한다.[^65]
즉, 개발 단계부터 보안 테스트를 수행해 더 빠르고 적은 비용으로 위험 요소를 해결하고자, 점진적으로 CI/CD 파이프라인을 고도화해 나갔다고 한다.[^68] 그러나 시간이 지나며 “보안 때문에 개발을 못한다”, “개발 생산성이 떨어진다”는 피드백이 점점 발생하기 시작했는데, 그 배경에는 아래와 같은 고민(문제)이 있었다고 정리한다.[^69]
-
개발 단계부터 보안 테스트를 위해 다양한 툴과 통합해야 했다.[^70]
- 그리고 그 툴들을 기존 파이프라인에 어떻게 통합해야 개발 속도에 영향을 최소화하고 손쉽게 자동화할 수 있을지 고민했다.[^70]
-
여러 툴에서 나오는 테스트 결과를 통합된 플랫폼에서 모아 볼 수 없을까 고민했다.[^71]
-
발견된 취약점이 “실제로 조치가 필요한 취약점인지/관련 없는지”를 정보보안 조직으로부터 빠르게 피드백받고 싶었다.[^72]
-
상용 테스트 솔루션을 구매/도입하는 의사결정 시간이 걸리므로, 오픈소스를 이용해 빠르게 테스트 환경을 자동 구성할 수 있으면 좋겠다고 생각했다.[^73]
이 문제들을 해결하기 위해 어떤 구조를 만들었는지 다음 파트에서 제시한다.[^74]
3.14 (해결 방향) EventBridge + Step Functions로 “정적 애플리케이션 보안 테스트 자동화 워크플로우” 오케스트레이션[^74]
발표자는 앞서의 고민을 개선/고도화하기 위해, 기존 파이프라인 구조에서 Amazon EventBridge와 AWS Step Functions를 사용해 “정적 애플리케이션 보안 테스트 자동화 워크플로우”를 구축했다고 말한다.[^74]
구체적으로는 다음 흐름을 제시한다.[^75]
- EventBridge가 CodeCommit의 Pull Request 생성/삭제/업데이트 이벤트를 필터링한다.[^75]
- 필터링된 이벤트로 Step Functions를 트리거한다.[^75]
- Step Functions가 정적 보안 테스트 워크플로우 전체(환경 구성→테스트 실행→결과 리포팅→정리)를 오케스트레이션한다.[^76]
이제 Step Functions 워크플로우의 상세 단계를 순서대로 설명한다.[^76]
3.15 Step Functions 워크플로우 상세(1): PR 생성 시 테스트 환경 구성—SonarQube 프로젝트 생성, 키 저장, CodeBuild 프로젝트 생성[^76]
가장 먼저 “테스트 환경을 구성하는 단계”가 나온다고 설명한다.[^76] PR이 새롭게 생성되면 테스트 환경을 구성한다.[^76]
- Lambda 함수를 통해 SonarQube 프로젝트를 생성한다.[^77]
- 생성한 프로젝트의 프로젝트 키를 저장한다.[^77] (발표 후반에 “Secrets Manager에 키/토큰 저장”을 말하므로, 저장소는 Secrets Manager로 이해 가능)[^78]
- 다음으로 테스트를 위한 CodeBuild 프로젝트를 생성한다.[^79]
이 파트는 “PR 최초 생성 시”에 수행되는 환경 부트스트랩(프로비저닝) 단계로 제시된다.[^76]
3.16 Step Functions 워크플로우 상세(2): 테스트 실행—CodeBuild로 실행하고 “10초마다 상태 확인”으로 완료 여부 확인[^79]
테스트 환경이 구성이 되면 테스트 실행 단계로 넘어간다.[^79] 생성된 CodeBuild 프로젝트를 통해 테스트가 실행된다.[^79] 그리고 Step Functions가 10초마다 테스트 상태를 확인해 완료 여부를 확인한다고 말한다.[^80]
또한 PR 업데이트 이벤트에 대해서는 “따로 테스트 환경을 구성하지 않고 바로 테스트 실행 단계가 수행”된다고 설명한다.[^81] 즉, PR 생성 때 만들어 둔 환경(예: SonarQube 프로젝트, CodeBuild 프로젝트)을 재사용하고, 업데이트마다 테스트만 재수행하는 구조로 제시된다.[^81]
3.17 Step Functions 워크플로우 상세(3): 결과 리포팅—분석 후 PR 코멘트/승인여부 업데이트, SNS 및 Security Hub로 전달[^82]
테스트가 완료되면 결과 리포팅 단계로 넘어간다.[^82]
- Lambda를 통해 테스트 결과를 분석한다.[^82]
- 분석 결과를 바탕으로 PR에 댓글(코멘트)을 작성한다.[^82]
- 해당 PR에 대한 승인 여부를 업데이트한다.[^82]
- 또한 SNS 및 Security Hub로 테스트 결과를 전달한다고 말한다.[^83]
즉 결과가 개발 워크플로우(코드 리뷰/병합 승인)와 보안 운영 관점(통합 플랫폼, 알림) 양쪽으로 흘러가도록 설계되었다.[^83]
3.18 Step Functions 워크플로우 상세(4): 정리(Cleanup)—PR 병합/삭제 시 SonarQube/Secrets/CodeBuild 리소스 삭제[^84]
PR이 모든 조건을 만족해 병합되었거나, 혹은 다른 이유로 PR이 삭제되었을 경우 “테스트 환경을 정리”한다.[^84]
정리 대상은 다음과 같이 열거된다.[^85]
- 생성된 SonarQube 프로젝트(발표에선 “써너… 프로젝트”로 발음)[^85]
- Secrets Manager에 저장된 프로젝트 키 및 토큰 값[^85]
- CodeBuild 프로젝트[^85]
이로써 PR 생애주기(생성/업데이트/병합·삭제)에 따라 환경을 만들고, 재사용하고, 끝나면 지우는 “수명주기 기반 자동화”를 구현했음을 설명한다.[^84]
3.19 데모(워크플로우 구조 확인): 이벤트로 트리거→상태 확인→환경 구성→테스트→리포팅→정리[^86]
발표자는 데모로 자세히 보자고 한 뒤, 먼저 Step Functions 워크플로우가 어떻게 구성됐는지 요약해 보여준다.[^86]
- EventBridge에서 Step Functions가 트리거됨[^86]
- 1단계: PR 상태 확인[^86]
- 이벤트에 따라 테스트 환경 구성[^87]
- 환경 구성 후 테스트 시작, 종료되면 결과 리포팅[^87]
- PR 삭제 이벤트는 테스트 정리 단계 수행[^87]
또한 Step Functions의 Workflow Studio를 사용하면 드래그앤드롭 방식으로 워크플로우 생성/편집이 가능하고, 유효성 검증을 통해 자동으로 코드를 생성할 수 있다고 언급한다.[^88] 그리고 새롭게 추가된 AWS SDK 통합 기능으로 200개 이상의 AWS 서비스와(또는) 1000개 이상의 AWS API를 직접 통합해 워크플로우를 구축할 수 있다고 설명한다.[^89] (발표에 나온 수치 표현을 그대로 따르면 “200개 이상의 서비스, 1000개 이상의 … API”를 강조한다.)[^89]
3.20 데모(레포/브랜치/취약 코드 준비): CodeCommit, main/develop, DB 안전하지 않은 접근·무한 반복 유발 코드 포함[^90]
데모를 위한 소스 코드 설명으로 넘어가며, 소스 리포지토리는 CodeCommit을 사용하고 “main”과 “develop” 두 브랜치가 존재한다고 말한다.[^90] main에서 “developer(발표 자막상 디벨로퍼…)” 브랜치를 생성하고, 그 브랜치 소스에는 다음 문제가 있는 코드가 커밋돼 있는 상태라고 설명한다.[^91]
- 안전하지 않은 방법으로 데이터베이스에 접속하는 코드[^91]
- 무한 반복을 유발하는 코드[^91]
이 변경을 main에 병합하기 위해 PR을 생성해 보겠다고 한다.[^91]
3.21 데모(PR 생성): 소스/대상 브랜치 지정→제목/설명→변경 확인→PR 생성→EventBridge가 이벤트 발생→Step Functions 트리거[^92]
발표자는 PR 생성 과정을 단계적으로 보여준다.[^92]
- 소스 브랜치와 대상 브랜치를 지정하고 비교 버튼 클릭[^92]
- 제목 및 설명 추가[^93]
- 코드 변경 사항 확인 후 PR 생성 버튼 클릭[^93]
PR이 새롭게 생성되면 EventBridge를 통해 이벤트가 발생하고, 정적 보안 테스트를 위한 Step Functions가 트리거된다고 설명한다.[^94] Step Functions는 PR 상태를 확인하고, 테스트 환경 구성이 필요하면 자동으로 만들고 CodeBuild로 테스트를 진행한다고 말한다.[^95]
3.22 데모(테스트 실행/폴링): CodeBuild 상태를 “10초마다 확인”, SonarQube 프로젝트/토큰이 환경변수로 주입됨[^96]
테스트 진행 단계에서는 10초마다 CodeBuild 상태를 확인해 완료 여부를 확인한다고 다시 강조한다.[^96] 이어서 실제로 생성된 CodeBuild 프로젝트로 이동해 상태를 확인해 보자고 한다.[^97]
CodeBuild 프로젝트의 “페이즈 세부 정보”를 통해 구성 값이 잘 들어가 있는지 확인하는데,[^98] 여기서 SonarQube 프로젝트 키/토큰 값이 환경 변수를 통해 주입되어 있음을 확인할 수 있다고 말한다.[^98]
그리고 CodeBuild가 Lambda를 통해 생성된 SonarQube 프로젝트와 통신하여 테스트를 수행하며, 프로젝트의 모든 단계가 성공(또는 완료)한 것을 확인할 수 있다고 설명한다.[^99]
3.23 데모(결과 리포팅): Lambda가 결과 분석→PR에 요약 댓글 업데이트→에러면 승인 미업데이트[^100]
Step Functions에서 테스트 완료가 확인되면 Lambda로 테스트 결과를 분석하고 리포팅 단계로 간다고 말한다.[^100] 이후 방금 생성했던 PR로 돌아가 상태를 확인한다.[^101]
- 댓글로 요약된 테스트 결과가 업데이트되어 있다.[^101]
- 테스트 결과가 “에러 상태”이기 때문에, PR 승인 여부는 업데이트되지 않았다고 설명한다.[^101]
즉, 실패/취약점 발견 시에는 병합 게이트(승인)로 이어지지 않게 만들어, 개발자가 수정하도록 유도하는 흐름을 보여준다.[^101]
3.24 데모(Security Hub에서 이슈 확인): 무한 반복 코드, 안전하지 않은 DB 접근 코드가 이슈로 탐지됨[^102]
다음으로 Security Hub로 이동해 어떤 이슈가 발생했는지 확인한다.[^102] Security Hub에서:
- 무한 반복을 유발하는 코드 관련 이슈[^103]
- 안전하지 않은 DB 접근 코드 관련 이슈[^103]
가 발견되었음을 확인할 수 있다고 말한다.[^103] 여기서 Security Hub가 “통합된 플랫폼에서 결과를 보고 싶다”는 고민(앞서 제시한 문제 2)을 해결하는 수단으로 시연되는 셈이다.[^71]
3.25 데모(코드 수정→PR 업데이트): 커밋하면 업데이트 이벤트로 테스트 재실행, 기존 테스트 환경 재사용[^104]
탐지된 취약점을 처리하기 위해 코드를 수정한 다음 커밋하여 PR을 업데이트하겠다고 한다.[^104] 작성자 이름/이메일/커밋 메시지를 작성해 developer 브랜치 변경사항을 커밋하는 과정을 보여준다.[^105]
코드가 변경되었음을 확인한 뒤 PR로 이동해 업데이트 상태를 확인한다.[^106] PR 상태가 업데이트되면 EventBridge에 의해 Step Functions가 다시 트리거되어 정적 보안 테스트가 실행된다고 말한다.[^106]
여기서 중요한 동작 차이는 “기존에 테스트 환경을 구성해 놓았기 때문에 추가 환경 구성을 하지 않고 CodeBuild로 테스트를 다시 진행”한다는 점이다.[^107] 즉 PR 업데이트는 재프로비저닝 없이 재실행에 초점을 둔 최적화 흐름으로 설계된다.[^81]
3.26 데모(재테스트 성공→승인 업데이트→병합 가능): 결과 OK면 승인 처리되어 병합 버튼 활성화[^108]
CodeBuild는 기존에 생성된 SonarQube 프로젝트와 통신하여 테스트를 수행하고, 프로젝트의 모든 단계가 성공한 것을 확인할 수 있다고 한다.[^108] Step Functions가 완료를 확인하면 Lambda가 결과 분석 후 리포팅을 수행했다고 말한다.[^109]
다시 PR로 이동해 상태를 확인하면:[^110]
- 댓글로 요약된 테스트 결과가 업데이트됨[^110]
- 테스트 결과가 “OK 상태”이기 때문에 PR의 승인 여부가 “승인”으로 업데이트됨[^110]
그 결과 PR의 병합 버튼이 활성화되며, 버튼을 클릭해 developer 브랜치 내용을 main 브랜치에 반영(병합)하겠다고 한다.[^111] 작성자 이름/이메일을 입력하고 PR 병합 버튼을 클릭하여 병합을 수행한다.[^112]
3.27 데모(병합/브랜치 삭제→정리 워크플로우 실행): 병합 이벤트로 Step Functions 트리거, 테스트 환경 자동 정리, CodeBuild 리소스 삭제 확인[^113]
PR 상태가 병합으로 업데이트되었음을 확인하고,[^113] developer 브랜치가 삭제된 것도 확인할 수 있다고 말한다.[^113] PR 상태 변경(병합)으로 인해 이벤트가 발생하여 Step Functions가 다시 트리거되고, 정적 보안 테스트 워크플로우 중 “테스트 환경 정리 단계”가 수행되었다고 설명한다.[^114]
그 뒤 실제 CodeBuild 프로젝트로 이동해 해당 리소스가 삭제되었음을 확인할 수 있다고 말하며, 이것으로 Step Functions 기반 정적 애플리케이션 보안 테스트 데모를 마친다.[^115]
3.28 데모로 연결한 “개선 효과” 정리: 통합 용이(Step Functions), 통합 뷰(Security Hub), 빠른 피드백(SNS), 오픈소스 통합(CodeBuild)로 시간/예산 제약 완화[^116]
발표자는 데모를 통해 앞서 언급한 문제들을 어떻게 개선할 수 있었는지 다시 연결한다.[^116]
- Step Functions를 통해 AWS의 다양한 서비스들과 손쉽게 통합할 수 있었다(문제 1: 다양한 툴 통합의 부담 완화).[^^116]
- 테스트 결과를 통합 플랫폼에서 보고 싶다는 고민은 Security Hub로 개선할 수 있었다(문제 2 해결).[^^117]
- SNS를 통해 빠른 피드백이 가능하도록 개선했다(문제 3의 “빠른 피드백” 강화).[^^118]
- CodeBuild에 오픈소스를 통합하여 제한된 시간/예산 문제를 개선해 볼 수 있었다(문제 4 해결 방향).[^^118]
마지막으로 이 세션이 청중의 DevSecOps 여정에도 도움이 되길 바란다고 말하며 감사 인사와 피드백 요청으로 마무리한다.[^119]
4. 핵심 통찰[^120]
- DevSecOps는 DevOps의 “다른 것”이 아니라, 같은 목표(빠른 가치 전달)를 위해 보안을 자동화된 라이프사이클에 내장하는 확장이다.[^2]
- DevSecOps의 실행 단위는 도구(파이프라인) 하나가 아니라, 문화/방식/도구의 조합이며 “파이프라인도 프로덕트”처럼 계속 진화해야 한다.[^19]
- 엔터프라이즈에서 DevSecOps는 선언이 아니라 측정(Assessment)→목표/범위/우선순위→반복 구현→재평가의 운영체계로 접근해야 한다.[^38]
- “Shift Security Left”는 개발 생산성을 해치기 쉬우므로, PR 이벤트 기반 자동화·결과 통합·빠른 피드백·환경 자동 정리 같은 운영 설계가 같이 들어가야 지속 가능해진다.[^69]
- EventBridge + Step Functions는 PR 생애주기(생성/업데이트/병합/삭제)에 따라 SAST를 오케스트레이션하기에 적합하며, Workflow Studio/AWS SDK 통합으로 확장성 있는 자동화를 만들 수 있다는 메시지를 준다.[^88]
- 실행 시사점(발표 내용 기반)
- 조직 도입은 Assessment로 현황을 수치화하고 액션 아이템을 뽑는 것부터 시작한다.[^38]
- 목표/기간을 먼저 정하고, 액션 아이템을 에픽으로 묶어 비즈니스 목표 기반 우선순위를 정한다.[^47]
- PR 이벤트를 중심으로 “환경 구성-테스트-리포팅-정리”의 수명주기를 자동화해 개발자 체감을 개선한다.[^84]
5. 헷갈리는 용어 정리[^121]
DevOps: 애플리케이션/서비스를 빠르게 제공하도록 조직 역량을 높이는 문화·철학·방식·도구의 조합.[^18]
DevSecOps: DevOps의 연장선에서 보안 정책의 자동화된 시행을 달성하기 위해 기술+문화+방법+도구를 포함하며, 자동화된 SDLC에서 위협 탐지·예방·제어 능력 향상을 지향.[^22]
빌트인 퀄리티(Built-in Quality): 개발 과정/라이프사이클에 품질(보안 포함)을 “나중 점검”이 아니라 “처음부터 내장”해 자동화된 SDLC에서 보장하려는 관점.[^20]
Security of the pipeline: 파이프라인 자체(IaC, 키/암호화 등)의 보안.[^31]
Security in the pipeline: 파이프라인 워크플로우로 수행/관리되는 애플리케이션 보안(예: SonarQube 취약점 탐지) 전반.[^31]
Shift Security Left: 배포 직전/검증환경에서 하던 보안 테스트를 개발 단계로 당겨(왼쪽으로 이동) 더 빠르고 적은 비용으로 위험 요소를 제거하려는 접근.[^65]
Epic(에픽): 여러 액션 아이템을 묶어 실행 가능한 큰 단위로 분류한 목표/작업 묶음(발표에서 목표/범위 설정 단계의 산출로 제시).[^45]
PR(풀 리퀘스트, 발표에서는 ‘플리캐스트’ 등으로 표기): 브랜치 변경을 다른 브랜치로 병합하기 위한 요청 단위로, 생성/업데이트/병합/삭제 이벤트를 트리거로 워크플로우를 실행.[^75]
SAST(정적 애플리케이션 보안 테스트): 소스/빌드 산출물을 정적으로 분석해 취약점 등을 탐지하는 테스트로, Step Functions 워크플로우로 자동화 대상이 됨.[^74]
참고(콘텐츠 정보)[^122]
- 제목: DevSecOps, 어디까지 구성해봤니?[^122]
- 발표: 고원경(어플리케이션 아키텍트, AWS) / 김대곤(클라우드 아키텍트, AWS)[^122]
- 행사/출처 채널: Amazon Web Services Korea (AWS Summit Korea 2022)[^122]
- 길이: 29분 0초[^122]
- 링크: https://www.youtube.com/watch?v=Pkc-FQ00MB8[^122]
[^1]: @[00:11] “AWS Summit Korea에 오신 것을 환영합니다”로 시작해 DevSecOps 주제를 예고하고 전체 흐름을 소개하는 세션 도입부.
[^2]: @[02:30] “DevOps와 DevSecOps는 공통의 목표… 더 빠른 시간에 더 많은 가치… 빌트인 퀄리티… 자동화된 소프트웨어 라이프사이클” + @[03:47] “DevSecOps는… 보안 정책에 자동화된 시행…”
[^3]: @[07:08] “체계가 잡혀있지 않은 조직… 어디서부터” + @[07:32] “Assessment부터” + @[07:49] 목표/에픽/기간/우선순위 + @[11:06] 반복 실행(계획/개발/리뷰) + @[14:21] 다시 1단계부터 반복.
[^4]: @[16:06] 생산성 저하 피드백 문제 제기 + @[17:37] EventBridge/Step Functions로 워크플로우 구축 + @[18:19]~@[19:56] 환경 구성/실행/리포팅/정리 + @[28:00] 개선효과 연결.
[^5]: @[01:01] 세션 흐름(개념→여정 단계→팁/데모) + @[01:31]~@[02:22] 현대화 배경과 DevSecOps 필요성.
[^6]: @[04:35]~@[05:41] DevSecOps 목적(통제권), 빠른 테스트/예방 우선순위/반응형 제어/자동화, SDLC 초기부터 포함.
[^7]: @[17:37]~@[28:17] 데모 아키텍처 요소와 문제 해결 연결(통합/통합 뷰/피드백/오픈소스).
[^8]: @[00:16] 발표자 소개(프로페셔널 서비스, 애플리케이션 아키텍트) 및 역할 설명.
[^9]: @[00:32]~@[00:41] “DevOps… DevSecOps… 이야기해보려고”.
[^10]: @[00:45] “워크로드 운영… CI/CD 파이프라인 구축… 대상”.
[^11]: @[01:01]~@[01:14] “흐름… DevOps/DevSecOps… 여정 단계… 팁/데모”.
[^12]: @[01:31]~@[01:43] 레거시→클라우드 마이그레이션/현대화 추세.
[^13]: @[01:43]~@[01:55] 현대화 목적(클라우드 네이티브로 빠른 비즈니스 요구 반영).
[^14]: @[01:55]~@[02:10] 컨테이너/서버리스, 아키텍처 선택 필요.
[^15]: @[02:10]~@[02:22] “새로운 기술 말고 또 무엇… 바로 DevOps”.
[^16]: @[02:22] “DevOps, DevSecOps는 선택 아닌 필수”.
[^17]: @[02:55]~@[03:06] 공통 목표 기반으로 초점이 다르다는 설명.
[^18]: @[03:10] DevOps 정의(문화/철학/방식/도구).
[^19]: @[03:31]~@[03:44] “자동화된 배포 파이프라인만으로 DevOps 잘한다 보기 어렵… 일하는 방식 변화 필요”.
[^20]: @[02:43]~@[02:55] “빌트인 퀄리티… 자동화된 소프트웨어 라이프사이클”.
[^21]: @[02:55]~@[03:06] DevOps/DevSecOps 차이는 초점 영역.
[^22]: @[03:47]~@[04:06] DevSecOps 정의(보안 정책 자동화 시행, 기술+문화/방법/도구).
[^23]: @[04:06]~@[04:13] “DevOps 큰 틀에서 보안 영역을 중요”.
[^24]: @[04:13]~@[04:30] 위협 탐지/예방/제어 능력 향상.
[^25]: @[04:35]~@[04:51] DevOps(민첩) 대비 DevSecOps(통제권) 목적.
[^26]: @[04:51]~@[05:00] “첫째 더 빠른 테스트… 보안 테스트”.
[^27]: @[05:00]~@[05:11] “둘째 예방 우선순위… 기준 필요”.
[^28]: @[05:11]~@[05:28] “셋째… 지속적 테스트로 조기 식별… 대응 프로세스/도구”.
[^29]: @[05:28]~@[05:41] “마지막… 자동화 필요… SDLC 초기부터 포함”.
[^30]: @[05:41]~@[05:41] “빌트인 퀄리티… 라이프사이클 생성” 취지.
[^31]: @[06:00]~@[06:19] 두 항목(Security of / in the pipeline) 소개.
[^32]: @[06:29] IaC로 파이프라인 생성 시 코드 보안/암호화 키 등은 Security of the pipeline 예시.
[^33]: @[06:44] SonarQube로 취약점 파악은 Security in the pipeline 예시.
[^34]: @[06:54]~@[06:59] 하위 항목 많아 오늘 다루지 않음.
[^35]: @[07:08] “체계 없는 조직… 어디서부터”.
[^36]: @[07:17] 엔터프라이즈 도입은 프로젝트/결과 필요.
[^37]: @[07:27] “결과를 어떻게 측정”.
[^38]: @[07:32]~@[07:49] “Assessment로 시작… 분석/수치화… 액션 아이템 도출”.
[^39]: @[08:31]~@[08:44] 문화/보안/아키텍처 인터뷰 및 분석.
[^40]: @[08:44]~@[08:55] 채점 기준 기반 수치화 점수, 객관 평가.
[^41]: @[08:55]~@[09:04] 추후 발전 지표로 활용.
[^42]: @[09:04]~@[09:14] 액션 아이템(Todo) 도출.
[^43]: @[09:14]~@[09:27] 레이더 차트/현재상황/액션아이템 산출물.
[^44]: @[09:27]~@[09:41] 목표·기간 설정(비즈니스 정렬).
[^45]: @[09:41]~@[09:54] 액션 아이템 묶기/범위 설정.
[^46]: @[09:54]~@[10:11] 2개월 목표 예시, 에픽/우선순위 정의.
[^47]: @[10:11]~@[10:25] 우선순위는 비즈니스 목표 정렬이 우선.
[^48]: @[10:25]~@[10:39] 우선순위 따라 자동화/정책분석/테스트 자동화 구현.
[^49]: @[10:39]~@[10:54] 큰 우선순위(2단계) vs 상세 우선순위(3단계).
[^50]: @[10:54]~@[11:06] 3~5단계 계획/개발/리뷰 반복.
[^51]: @[11:06]~@[11:17] 문화까지 적용하려면 점진 반복/흐름 형성 필요.
[^52]: @[11:17]~@[11:29] “파이프라인도 하나의 프로덕트… 지속 발전”.
[^53]: @[11:29]~@[11:42] 스크럼 소개(애자일 프레임워크).
[^54]: @[11:47]~@[12:08] 2달을 2주 스프린트로 나눠 8번 반복.
[^55]: @[12:08]~@[12:19] 점진적 발전 예시 예고.
[^56]: @[12:19]~@[12:44] CodeCommit 구성, 커밋 발생 시 트리거.
[^57]: @[12:49]~@[13:02] CodeBuild 빌드/테스트, CodeDeploy 배포 단계 추가.
[^58]: @[13:02]~@[13:13] 멀티 어카운트 배포/로깅 강화/보안 요소/외부툴 연계.
[^59]: @[13:17]~@[13:30] 정답 아님, 보안 먼저 구성도 가능, 순서 선택.
[^60]: @[13:36]~@[13:41] 처음부터 완벽한 큰 그림 가진 곳 없음, 지속 발전 필요.
[^61]: @[13:48]~@[13:56] 처음 만든 파이프라인은 완벽 불가.
[^62]: @[14:01]~@[14:08] 비즈니스 요구 변화→개발 등 변화, 보안도 완벽 불가.
[^63]: @[14:13]~@[14:33] 파이프라인 지속 변화, 사이클 반복(다시 1단계부터).
[^64]: @[14:40]~@[14:40] 다음 발표자에게 챌린지/개선 공유를 넘김.
[^65]: @[15:17]~@[15:28] 기존 보안 테스트 위치(배포 전/검증환경) + 문제(시간/비용) + Shift Security Left.
[^66]: @[14:56]~@[15:03] 김대곤 소개.
[^67]: @[15:03]~@[15:17] 여정의 문제/지속 개선 공유 예고.
[^68]: @[15:46] 개발 단계 보안 테스트, CI/CD 고도화.
[^69]: @[16:00]~@[16:17] “보안 때문에 개발 못함/생산성 저하” 피드백이 늘어난 배경.
[^70]: @[16:17]~@[16:43] 다양한 툴 통합/개발 속도 영향 최소화/자동화 고민.
[^71]: @[16:43]~@[16:54] 결과를 통합 플랫폼에서 보고 싶음.
[^72]: @[16:54]~@[17:08] 정보보안 조직으로부터 빠른 피드백 필요.
[^73]: @[17:08]~@[17:29] 상용 솔루션 도입 의사결정 시간, 오픈소스로 자동 구성 희망.
[^74]: @[17:37]~@[17:47] EventBridge + Step Functions로 SAST 자동화 워크플로우 구축.
[^75]: @[17:47] EventBridge로 PR 이벤트 필터링 후 Step Functions 트리거.
[^76]: @[18:06]~@[18:29] 워크플로우 설명 시작, PR 생성 시 환경 구성.
[^77]: @[18:29]~@[18:37] Lambda로 SonarQube 프로젝트 생성, 키 저장.
[^78]: @[19:43]~@[19:56] Secrets Manager에 프로젝트 키/토큰 저장 후 삭제 대상으로 언급.
[^79]: @[18:37]~@[18:48] CodeBuild 프로젝트 생성 및 테스트 실행.
[^80]: @[18:48]~@[18:59] “10초마다 테스트 상태 확인”.
[^81]: @[18:59]~@[19:11] PR 업데이트 이벤트는 환경 구성 없이 테스트 실행.
[^82]: @[19:11]~@[19:26] 결과 분석 후 PR 코멘트/승인여부 업데이트.
[^83]: @[19:26]~@[19:33] SNS 및 Security Hub로 결과 전달.
[^84]: @[19:33]~@[19:43] PR 병합/삭제 시 환경 정리 단계.
[^85]: @[19:43]~@[19:56] SonarQube 프로젝트, Secrets Manager 값, CodeBuild 프로젝트 삭제.
[^86]: @[20:01]~@[20:15] 데모: EventBridge로 트리거, PR 상태 확인.
[^87]: @[20:15]~@[20:28] 이벤트별 환경 구성, 테스트, 리포팅, 삭제 이벤트 정리.
[^88]: @[20:40]~@[20:53] Workflow Studio 드래그앤드롭/유효성 검증/코드 생성.
[^89]: @[20:53]~@[21:13] AWS SDK 통합(200+ 서비스, 1000+ API) 언급.
[^90]: @[21:17]~@[21:24] CodeCommit, main/develop 브랜치.
[^91]: @[21:24]~@[21:38] unsafe DB 접근 코드, 무한 반복 유발 코드 포함.
[^92]: @[21:54]~@[22:01] 브랜치 지정/비교.
[^93]: @[22:01]~@[22:20] 제목/설명/변경 확인/PR 생성.
[^94]: @[22:20]~@[22:37] PR 생성 이벤트 발생, Step Functions 트리거.
[^95]: @[22:37]~@[22:50] 상태 확인 후 환경 자동 생성, CodeBuild로 테스트.
[^96]: @[22:50]~@[23:00] 10초마다 CodeBuild 상태 확인.
[^97]: @[23:00]~@[23:05] CodeBuild 프로젝트로 이동해 상태 확인.
[^98]: @[23:05]~@[23:13] 페이즈 세부정보로 구성값 확인, SonarQube 토큰 환경변수.
[^99]: @[23:21]~@[23:36] CodeBuild가 SonarQube와 통신해 테스트 수행, 성공 확인.
[^100]: @[23:36]~@[23:49] 완료 확인 후 Lambda로 결과 분석/리포팅.
[^101]: @[23:49]~@[24:10] PR 댓글 업데이트, 에러 상태로 승인 미업데이트.
[^102]: @[24:10]~@[24:18] Security Hub로 이동.
[^103]: @[24:18]~@[24:37] 무한 반복/unsafe DB 접근 이슈 확인.
[^104]: @[24:37]~@[24:49] 취약점 처리 위해 코드 수정 후 커밋/PR 업데이트.
[^105]: @[24:49]~@[25:08] 커밋 작성자/이메일/메시지 입력.
[^106]: @[25:08]~@[25:33] PR 업데이트로 이벤트 발생, Step Functions 재트리거.
[^107]: @[25:33]~@[25:46] 기존 환경 재사용, 추가 구성 없이 CodeBuild 재실행.
[^108]: @[25:46]~@[26:04] SonarQube와 통신해 테스트, 성공 확인.
[^109]: @[26:04]~@[26:17] Lambda로 결과 분석/리포팅 수행.
[^110]: @[26:17]~@[26:34] PR 댓글 업데이트, OK면 승인 업데이트.
[^111]: @[26:34]~@[26:45] 병합 버튼 활성화, 병합 진행.
[^112]: @[26:45]~@[26:58] 작성자 정보 입력 후 병합.
[^113]: @[26:58]~@[27:04] 병합 상태 업데이트, 브랜치 삭제 확인.
[^114]: @[27:04]~@[27:20] 병합 이벤트로 Step Functions 트리거, 테스트 환경 정리 수행.
[^115]: @[27:20]~@[27:43] CodeBuild 리소스 삭제 확인, 데모 종료.
[^116]: @[27:51]~@[28:07] Step Functions로 다양한 서비스 통합 용이.
[^117]: @[28:07]~@[28:17] Security Hub로 통합 플랫폼에서 취약점 확인.
[^118]: @[28:17]~@[28:31] SNS 빠른 피드백, CodeBuild에 오픈소스 통합으로 시간/예산 문제 개선.
[^119]: @[28:31]~@[28:54] 세션 마무리(도움/감사/피드백 요청).
[^120]: @[02:30]~@[02:55] 공통 목표/빌트인 퀄리티 + @[11:17] 파이프라인=프로덕트 + @[07:32] Assessment 기반 측정 + @[17:37] 워크플로우 자동화 데모 종합.
[^121]: @[03:10] DevOps 정의 + @[03:47] DevSecOps 정의 + @[06:06] of/in 구분 + @[15:28] Shift Security Left 맥락.
[^122]: 사용자 제공 메타데이터(제목/채널/길이/링크) 및 영상 정보: “DevSecOps, 어디까지 구성해봤니? … AWS Summit Korea 2022”, Amazon Web Services Korea, 29:00, https://www.youtube.com/watch?v=Pkc-FQ00MB8