DevSecOps란 무엇이며 CD에서 DevSecOps의 역할은?
DevSecOps(데브섹옵스)는 보안과 소프트웨어 개발 수명주기(SDLC) 통합의 중요성을 강조합니다. 팀의 문화, 프로세스 및 도구에 보안을 구축하면 사일로를 방지할 수 있으며 신속한 전달이 보안 취약성을 높이지 않습니다.
DevOps 이해하기
본격적으로 보안 측면을 논의하기 전에 DevOps를 간략히 살펴보겠습니다.
애자일 소프트웨어 개발과 밀접한 연관이 있는 DevOps는 가치 있고 작동하는 소프트웨어를 사용자에게 효율적으로 제공한다는 공동의 목표를 모두가 공유하면서 소프트웨어 개발과 운영 간의 협업 문화를 구축하는 것입니다. 이를 실천하고자 DevOps는 전달 시간을 단축하고 신속한 피드백을 촉진하여 지속적 개선의 주기를 생성하는 강력하고 자동화된 프로세스를 지지합니다.
지금까지 별문제가 없었더라도 기차를 놓치지 않으려 열심히 달리는 때와 마찬가지로 소프트웨어 전달 프로세스를 가속화하는 경우 누락된 중요 사항은 없는지 확인하는 것이 좋습니다. 안타깝게도 주로 보안적 측면의 누락이 발생했으며, 이는 DevSecOps를 통해 해결하려는 목표입니다.
DevOps 보안
소프트웨어 보안 취약성이 지니는 잠재적 영향력은 상상 이상입니다.
재정적 손해나 평판 악화만의 문제가 아닙니다. 소프트웨어 보안 침해는 내부 문서부터 출시 이전의 제품 및 비밀번호 등 고객 개인정보에 이르는 엄청난 양의 민감한 데이터 유출을 초래했습니다. 관할 지역에 따라 사용자 데이터 유출은 심각한 재정적 불이익과 법률적 책임을 야기할 수 있습니다.
이 모든 사항에도 불구하고 개발팀에서 보안을 자산이 아닌 장애물로 간주하는 경우가 많습니다. 보안 감사 및 보고서는 진행 속도를 저해하고 최신 기능을 출시해 사용자에게 전달하는 데 방해가 됩니다. 하지만 이러한 사고방식이 공격자에겐 유리하게 작용합니다. SDLC에서 보안의 중요성을 간과하기로 선택한 경우 차세대 Wannacry나 Heartbleed가 파고들 수 있는 위험에 노출되는 것입니다.
이와 같은 취약점 공격 사례는 뉴스 헤드라인을 장식하지만 발단은 대수롭지 않은 실수에 불과합니다. 코드를 작성하는 것은 인간이고, 인간은 실수하기 마련이므로 취약성이 존재합니다. 그런 실수가 이전에 다른 사람들이 저지른 실수이며 (어디를 살펴봐야 할지 안다면) 쉽게 인식 가능한 경우도 있지만, 이전과는 완전히 다른 방식으로 다양한 요인이 복합적으로 작용하여 발생한 새로운 실수인 경우도 있습니다.
문제가 더욱 복잡해지는 이유는 오픈소스 및 독점 소프트웨어를 막론하고 거의 모든 소프트웨어에 종속성이 통합되며 타사 코드에 취약성이 없다는 보장도 없기 때문입니다.
그렇다면 SDLC에 보안을 어떻게 접목해야 할까요? DevSecOps 접근 방식은 협업, 책임 공유 및 자동화가 가능한 모든 것을 자동화하여 더 빠르고 안정적인 릴리스를 가능케 한 동일 원칙을 보안 관행에 적용하는 것입니다.
보안을 조기에 확인
워터폴 개발 프로세스의 경우 요구 사항 수집부터 시작하여 설계, 빌드, 통합 및 테스트 단계를 거쳐 마지막으로 (일반적으로 시작부터 몇 개월 또는 몇 년이 지난 후) 릴리스하는 선형 접근 방식을 취합니다.
일반적으로 테스트 단계에는 품질 보증, 보안 감사 및 수용 테스트로 구성된 긴 호흡의 수동 프로세스가 포함됩니다. "벽 너머로 물건 던지기"라고 조롱투로 불리는 프로세스에서 제품은 한 부서에서 다음 부서로 넘겨지고, 팀마다 긴 보고서를 작성합니다.
보안 보고서를 처리하고 발견된 내용과 및 권고 사항의 상세한 목록을 작성하는 정보 보안 팀에서 이 단계 중 하나를 담당합니다. 이와 같은 프로세스에서 코드베이스 변경이 필요한 경우가 잦았으며, 그 이후에도 모든 단계가 적절히 구현되었는지 확인하고자 소프트웨어의 개발 단계를 다시 거쳐야 했습니다. 이처럼 필요 이상으로 오랜 기간이 소요되는 프로세스를 생각하면 릴리스가 축하할 만한 큰 사건인 것도 당연합니다!
애자일 소프트웨어 개발, DevOps 무브먼트, 클라우드 컴퓨팅의 부상은 이 모든 것에 엄청난 변화를 불러왔습니다. 경쟁은 치열해졌고, 속도는 핵심이 되었습니다. 사용자의 요구 사항을 해결하지 않고 버그를 즉시 수정하지 않으면 사용자는 곧 그렇게 해줄 다른 공급업체를 찾을 것입니다. 많은 조직에서 CI/CD 파이프라인을 운영의 기반으로 삼아 정기적으로 가치를 전달하고 수정 사항을 신속히 적용하는 것이 표준으로 자리 잡았습니다.
DevSecOps라는 용어가 다른 의미를 지닐 수 있지만 DevOps에서 보안을 배제하려는 의도는 결코 없었습니다.
하지만 안타깝게도 현실에서는 개발팀과 운영팀 사이의 경계가 흐려지며, 정보보안팀과의 사일로만 남은 것이 일반적인 모습입니다. 이 문제 해결을 위한 노력의 일환으로, DevSecOps 및 SecDevOps, DevOpsSec, Rugged DevOps 등의 다양한 기타 버전이 함께 고안되었습니다.
DevSecOps는 처음부터 보안을 구축하고, 이해와 책임을 공유하는 문화를 보안 문제로 확장하고, 보안 검사를 CI/CD 파이프라인의 자동화된 테스트 체제에 통합하는 것의 중요성을 강조합니다. 운영과 마찬가지로 보안을 조기에 확인하면 제품이 완성된 후 추가하는 방식보다 보안 요구 사항과 모범 사례를 더욱 쉽게 통합할 수 있습니다.
DevSecOps에 보안 적용: 코드로서의 보안
초보자들은 보안을 조기에 확인하는 데 CI/CD 파이프라인의 한 단계로 보안 팀에서 소프트웨어를 테스트하는 것이면 충분하다고 생각하기 쉽습니다.
하단에서 논의할 내용처럼 수동 보안 테스트 단계가 필요한 경우도 물론 있지만, 보안 요구 사항에 대한 개입을 파이프라인의 마지막 단계로 제한하는 것은 소프트웨어를 다른 부서로 넘기고 보고서가 돌아올 때까지 기다리는 것과 거의 다를 바 없습니다.
가능한 결과는 다음 중 하나입니다. 구현에 너무 오랜 시간이 소요되어 권고 사항이 무시되는 것 혹은 전체 프로세스가 전적으로 중단되어 문제를 해결하고 위험을 평가하는 동안 릴리스가 무기한 지연되는 것입니다. 어느 결과든 보안팀과 조직의 다른 부서 사이의 갈등을 유발할 뿐이며 유용하고 안전한 소프트웨어의 릴리스라는 목표를 지향하는 데 도움이 되지 않습니다.
그렇다면 실제로 보안을 조기에 테스트하는 방법은 무엇일까요? 상황에 따라 다른 솔루션이 필요하겠지만 다음 도구와 기술은 SDLC 전반에 보안을 통합하는 데 도움을 줄 수 있습니다.
보안 담당자 지정
책임을 공유하는 문화는 중요하지만 개발팀의 모두가 소프트웨어 보안에 책임감을 가져야 한다고 말하는 것만으로는 부족합니다. 최신 공격 벡터 및 악성코드 개발 동향을 파악하는 것은 상근 직원이 필요한 일이며 모두가 동일한 수준의 전문성을 유지할 것이라고 기대해서는 안 됩니다. 다기능 팀에 보안 담당자를 불러와 다른 사람을 지도하고 모범 사례를 공유하도록 장려하면 보안 전문가와 협력을 위한 문화를 이해시키고 촉진하는 데 좋습니다.
보안을 설계상 제약 조건으로 설정
개발자들이 빌드 중인 소프트웨어의 보안에 대한 공동의 책임감을 가지려면 코드를 작성하기 전에 보안을 고려해야 합니다. 보안을 사용자 스토리에 통합하고, 백로그 리뷰 회의 중 제기하며, 각 스프린트 계획 시 논의해야 합니다. 새로운 기능의 처리 방식을 모색할 때 그로 인해 어떤 위험이 발생할 수 있으며 위험을 완화하는 방법을 논의하는 데에도 시간을 할애해야 합니다.
STRIDE와 같은 위협 모델링 전략을 채택하거나 OWASP 치트 시트 등의 도구를 사용하면 새로운 기술을 배우는 동안 예상대로 진행할 수 있습니다. 설계 단계에서 보안을 고려하더라도 모든 것을 포착할 수는 없지만, 여전히 좋은 출발점이며 DevSecOps 문화의 촉진에 도움이 됩니다.
파이프라인에 자동화된 보안 테스트 추가
자동화는 DevOps의 핵심 원칙입니다. 자동화를 통해 작업 속도를 높이고 일관성 있는 성과를 낼 수 있을 뿐 아니라 사람들은 창의력을 더 발휘할 수 있습니다. 사용자에게 정기적으로, 자주 소프트웨어를 제공하려면 파이프라인에 자동화된 보안 테스트를 추가해야 합니다.
자동화된 유닛 테스트, 통합 테스트 및 엔드투엔드 테스트를 작성할 때 보안 기능은 다른 기능만큼 중요한 것으로 고려해야 합니다. 팀에서 이미 보안 요구 사항을 사용자 스토리에 통합하고 설계 프로세스의 일부로 위협 모델에 대해 논의하고 있다면 보안 기능을 커버하는 테스트를 추가하는 것은 그러한 관행의 자연스러운 연장선입니다.
전문가의 도움받기
직접 작성하는 테스트 외에도 코드 품질에 대한 신뢰를 구축하는 데 유용한 보안 테스트 도구가 다양하게 존재합니다. 기존의 보안 스캔 도구는 자동화된 CI/CD 파이프라인에 적합하지 않았지만 이제 자동화를 위해 설계된 CI/CD 보안 테스트 도구를 사용할 수 있으며 이러한 도구는 파이프라인에 통합되어 대시보드를 통해 결과를 표시하거나 버그 추적 도구에 직접 통합되기도 합니다. 모든 자동화된 테스트와 마찬가지로 최대한 빨리 피드백을 제공하도록 테스트를 구성하는 것이 좋습니다.
정적 애플리케이션 보안 테스트(SAST) 도구는 정적 코드 분석을 수행하여 소스 코드에서 버퍼 오버플로 및 SQL 삽입 가능성 등의 알려진 보안 결함을 확인합니다. 정적 분석은 소스 코드에서 실행되므로 변경 사항 커밋 즉시 CI/CD 파이프라인에서 조기에 수행할 수 있습니다.
SAST 도구는 언어별로 다르며 일부는 IDE에 통합되어 작성할 때 지속적인 피드백을 제공하거나 요청 시 테스트를 수행하는 옵션을 제공합니다. 또한 SAST 도구는 취약성이 포함된 특정 코드 줄로 개발자를 안내하여 대상이 명확한 지침을 제시하므로 이슈를 더 빨리 수정할 수 있습니다. 그러나 긍정오류가 문제가 될 수 있으므로 모든 SAST 결과가 관련성 낮은 노이즈가 되지 않게 하려면 일부 경고는 끄거나 해제할 필요가 있습니다.
SAST는 동적 애플리케이션 보안 테스트(DAST)로 귀결됩니다. DAST는 실행 중인 애플리케이션에 대한 블랙박스 테스트 방식을 사용하여 교차 사이트 스크립팅, 명령어 및 SQL 인젝션, 안전하지 않은 서버 구성 등의 알려진 취약점을 확인합니다. DAST 도구를 사용하려면 애플리케이션을 빌드하고 테스트 환경에 배포해야 하므로 일반적으로 CI/CD 파이프라인의 후반부에서 사용됩니다.
종속성 확인
소프트웨어 구성 또는 구성 요소 분석(SCA)은 프로세스 초기에 실행 가능한 자동화된 보안 테스트의 또 다른 유형입니다. 상기 언급된 바와 같이 거의 모든 코드베이스에는 오픈소스 라이브러리 및 기타 구성 요소가 통합되어 있어 취약성이 초래될 수 있습니다.
SCA 도구는 사용자가 추가한 종속성을 크롤링할 뿐 아니라 해당 종속성의 종속성도 공급망에서 재귀적으로 크롤링해야 합니다. 특히 프로젝트에 종속성이 얼마나 자주 추가되는지를 고려할 때 이는 컴퓨터에 가장 적합한 작업의 완벽한 예시입니다.
일부 SCA 도구는 CI/CD 파이프라인의 일부로 자동 실행되며, IDE 플러그인으로도 지원되어 즉시 피드백을 제공할 수 있습니다. 정적 및 동적 보안 테스트와 마찬가지로 SCA 테스트도 도구가 인식하는 취약점에 한정될 수 있으므로, 선택한 도구가 새로운 취약점 공격에 따라 정기적으로 업데이트되며 제품 및 조직과 가장 관련성 높은 영역을 커버하는지 확인해야 합니다. 하지만 인간의 지원을 필요로 하는 예상치 못한 신종 취약점 공격이 발견되는 경우가 있습니다.
레드팀 불러오기
레드팀의 개념은 전쟁 게임에서 비롯되었으며, 자사의 방어력과 약점을 파악하기 위해 시뮬레이션 공격에서 팀원이 적의 역할을 수행하는 것입니다. 동일한 접근 방식이 소프트웨어 개발에 사용되며 큰 효과를 발휘했으며, 때로는 침투 테스트 또는 윤리적 해킹의 형식으로 진행되기도 합니다.
레드팀은 효과적인 작업을 위해 테스트 중인 시스템 개발에 참여할 수 없습니다. 탐색 테스트와 마찬가지로 레드팀의 테스터는 참신하게 사고하고 의도하지 않은 방식으로 소프트웨어를 사용해야 합니다.
레드팀은 스테이징 환경(이상적으로 프로덕션과 최대한 유사한 환경) 또는 라이브 프로덕션 시스템에서 작업할 수 있습니다. 두 번째 옵션을 선택하려면 제품의 오류 모드에 대한 높은 신뢰 또는 매우 관대한 사용자(및 C 레벨 임원!)가 필요할 것입니다.
모든 취약점을 버그로 취급
DevSecOps 접근 방식에는 소프트웨어 보안에 책임이 있는 모든 사람이 포함됩니다. 그러므로 이제 보안 문제를 "일반적" 버그와 구분하는 사고는 중단해야 합니다. 시스템에서 발견한 모든 오류 또는 취약점은 다른 모든 문제와 동일한 백로그에 속하며, 그와 마찬가지로 우선순위가 지정되어야 합니다.
이를 수정하는 책임은 보안 담당자만이 아닌 팀 전체의 몫입니다. 이와 같은 접근 방식을 취하면 팀 내에서 지식과 전문성을 구축하는 데 도움이 되며 기술을 다음 프로젝트에도 적용할 수 있습니다.
프로덕션을 지속적으로 모니터링
SDLC의 이전 단계에서 수행한 모든 노력에도 불구하고 해커가 라이브 시스템의 취약점을 찾아낼 위험이 여전히 존재합니다. 조직과 사용자 모두를 보호하기 위해 여전히 방화벽과 모니터링 도구에 투자할 가치가 있습니다. 런타임 애플리케이션 자체 보호(RASP) 도구는 최신 방어 도구로 의심스러운 동작을 자동으로 탐지하고 차단합니다.
마무리
보안을 조기에 확인하는 것은 SDLC의 모든 단계에서 팀 전체가 보안을 고려함을 의미합니다. DevOps 관행을 적용하면 해당 수명주기가 빈번히 반복되어 현실에서 소프트웨어의 작동 및 사용 방식에 대한 정기적 피드백을 제공합니다. CI/CD 파이프라인에 보안을 적용한다는 것은 애플리케이션의 보안에 대한 피드백을 정기적으로 받고 나머지 기능과 동일한 방식으로 개선할 수 있음을 의미합니다.
알려진 취약점을 확인하고 보호하면 알려진 취약점 공격에 무방비 상태로 노출되는 대신 소프트웨어가 공격에 맞춰 대비될 수 있습니다. 모든 새로운 취약점을 이후 분류하여 수정하고 테스트할 버그로 취급하면 시간이 지날수록 소프트웨어가 더욱 강력하게 발전합니다.
궁극적으로 DevOps와 DevSecOps에서 소프트웨어를 빠르게, 자주 제공할 수 있는 도구만큼이나 중요한 것은 문화입니다. 결국 사람이 Devops를 가능하게 만들기 때문입니다. 보안을 SDLC에 추가하기 위한 핵심은 비난의 대상을 찾기보다 책임을 공유하는 문화를 조성하는 것입니다. 누구나 보안 문제를 제기할 수 있고 스프린트 계획, 코드 검토, 수동 테스트 또는 라이브 시스템을 통해 모두의 의견이 수렴되어야 합니다. 또한 모두가 보안의 중요성을 인식하고 이를 구현하는 역할을 맡아야 합니다.