DevSecOps란?

DevSecOps는 개발의 모든 단계에 보안 조치를 통합하여 CI/CD 파이프라인의 속도를 늦추지 않으면서 취약점을 조기에 해결할 수 있도록 보장합니다.

DevSecOps는 보안 테스트와 조치를 소프트웨어 개발 프로세스에 통합하는 것이 중요함을 잘 보여줍니다. 보안을 조기 단계로 옮기면 보안 취약점의 대가를 치르지 않고도 빠른 전달을 보장할 수 있습니다.

CI 서버를 사용해야 하는 이유

DevSecOps는 DevOps 방법론을 기반으로 하는 소프트웨어 개발 접근 방식입니다. 'DevOps'가 '개발'과 '운영'을 결합한 것이라면 'DevSecOps'라는 용어는 개발, 보안 및 운영을 결합한 것입니다. '보안'이라는 단어가 추가된 것은 소프트웨어 개발 수명 주기의 모든 단계에 보안 고려사항을 통합하는 것이 중요함을 나타냅니다.

DevSecOps 3종 결합체

DevSecOps의 목표는 코드 베이스에 보안 취약점이 없는 상태로 팀이 소프트웨어를 더욱 빠르게 효율적으로 제공할 수 있도록 하는 것입니다. 이 전략은 조직과 사용자를 사이버 공격으로부터 보호합니다.

DevSecOps와 DevOps 비교

DevOps 방법론은 품질을 향상하고 버그를 줄이는 동시에 소프트웨어를 보다 빠르게 전달하도록 고안되었습니다. 애자일 물결에 바탕을 둔 DevOps는 소프트웨어 개발 및 전달에 대한 기존의 폭포수 방식이 가진 문제점을 해결하기 위해 개발되었습니다.

수년이 걸릴 수 있는 설계, 개발, 통합, 테스트 및 릴리스의 선형적인 프로세스와 달리 DevOps는 팀이 이러한 과정을 더 빠르고 더 자주 진행할 것을 권장합니다. 이를 실현하기 위해 DevOps는 전달 시간을 단축하고 신속한 피드백을 제공하여 지속적 개선의 주기를 생성하는 강력하고 자동화된 CI/CD 프로세스를 지지합니다.

DevSecOps는 DevOps와 어떻게 다를까요? 실제로 DevOps는 보안을 배제하려는 의도가 전혀 없었습니다. 그러나 DevOps 움직임이 개발 팀과 운영 팀 간의 경계를 허물어뜨리는 데 도움이 된 반면, 정보 보안 팀은 일반적으로 고립된 상태로 남았습니다. DevSecOps라는 용어는 SecDevOps, DevOpsSec, Rugged DevOps 등 다른 여러 버전과 함께 이를 해결하기 위해 도입되었습니다.

'DevSecOps'라는 용어를 사용하면 소프트웨어 개발 및 배포 프로세스에 보안을 고려하도록 팀을 상기시킬 수 있습니다. 여기에는 다음이 포함됩니다.

  • 보안 문제에 대한 공동의 이해와 책임의 문화를 확대합니다.
  • CI/CD 파이프라인의 자동화된 테스트 체계에 보안 검사를 구축합니다.
  • 모든 종속성과 CI/CD 파이프라인 자체를 포함한 소프트웨어 공급망을 보호합니다.
DevSecOps 실행

'시프트 레프트' 테스트가 버그를 더 쉽고 빠르게 찾아 수정할 수 있게 해주듯이, 보안 조치도 개발 프로세스의 조기에 이행하면 통합하기가 더 쉽고 효과적입니다.

DevSecOps가 중요한 이유

소프트웨어 보안 취약성이 지니는 잠재적 영향력은 상상 이상입니다.

소프트웨어 보안이 침해되면 재정적 피해와 평판 손상이 발생할 뿐만 아니라 내부 문서와 고객의 개인정보를 포함한 방대한 양의 민감한 데이터가 유출됩니다. 관할 지역에 따라 사용자 데이터 유출은 심각한 재정적 불이익과 법률적 책임을 야기할 수 있습니다.

이러한 문제에도 불구하고 소프트웨어 보안에 대한 기존의 접근 방식은 보안을 자산이 아닌 거추장스러운 것으로 느끼게 만들 수 있습니다. 보안 감사와 보고는 작업 진행을 더디게 하고 최신 기능을 출시해 사용자에게 전달하는 데 방해가 됩니다. 그러나 소프트웨어 개발 수명 주기(SDLC)에서 보안의 중요성을 간과한다면 다음 사이버 공격이 주요 뉴스에 보도될 수 있습니다.

이와 같은 취약점 공격 사례는 뉴스 헤드라인을 장식하지만 발단은 대수롭지 않은 실수에 불과합니다. 코드를 작성하는 것은 인간이고, 인간은 실수하기 마련이므로 취약성이 존재합니다. 때로 이러한 실수는 이전에 누군가 이미 저지른 것이어서 제대로 살피기만 한다면 알아차리기 쉽습니다. 하지만 때로는 이전에 볼 수 없었던 형태로 여러 요인들의 결합되어 새로운 보안 위협이 제기될 수도 있습니다.

문제가 더 복잡해지는 이유는 오픈소스 및 독점 소프트웨어를 막론하고 거의 모든 소프트웨어에 종속성이 통합되며 타사 코드에 취약성이 없다는 보장이 없기 때문입니다. 따라서 소프트웨어 공급망을 보호하는 일은 소스 코드 자체의 보안을 평가하는 것만큼 중요합니다.

그렇다면 SDLC에 보안을 어떻게 접목해야 할까요? DevSecOps 접근 방식에는 더 빠르고 안정적인 출시를 가능하게 했던 원칙이 동일하게 적용됩니다. 즉, 보안을 조기 단계로 이동하여 문제점을 초반에 자주 해결하는 것입니다.

시프트 레프트 테스트

얼핏 보면, 보안을 조기 단계로 이동한다는 것은 보안 팀에서 소프트웨어를 테스트하고 검토할 수 있도록 CI/CD 프로세스에 단계를 추가하기만 하면 되는 것처럼 들릴 수 있습니다.

수동 보안 테스트를 할 수 있는 곳이 있긴 하지만(나중에 설명), 보안 요구 사항에 대한 작업을 CI/CD 프로세스의 마지막 단계로 제한하면 다음과 같은 여러 가지 이유로 신속하고 정기적인 피드백의 이점을 놓칠 수 있습니다.

  • 수동 테스트에는 시간이 많이 걸리므로 배포 속도를 늦추거나 보안 테스트를 일부 릴리스로 제한해야 합니다.
  • 보안 문제가 발견될 때쯤이면 해당 코드를 작성한 사람은 이미 다른 작업으로 넘어갔을 테니, 해결책이나 권장 사항을 구현하기가 더 어려워질 것입니다.
  • 마지막으로, 보안 테스트를 프로세스의 한 단계로 제한하면 보안 팀과 조직의 나머지 팀 사이에 '우리와 그들'이라는 사고방식이 생겨납니다. 이는 어느 쪽에도 원하는 바, 즉 유용하고 안전한 소프트웨어를 출시하는 데 도움이 되지 않습니다.
보안 테스트는 CI/CD 프로세스에 어떻게 통합해야 할까요?

시프트 레프트 보안 테스트를 구현하는 방법

그렇다면 보안에 대한 시프트 레프트 접근 방식은 실제로 무엇을 의미할까요? 상황에 따라 다른 솔루션이 필요하겠지만 다음 도구와 기술은 SDLC 전반에 보안을 통합하는 데 도움을 줄 수 있습니다.

보안 담당자 지정

책임을 공유하는 문화는 중요하지만 개발팀의 모두가 소프트웨어 보안에 책임감을 가져야 한다고 말하는 것만으로는 부족합니다. 최신 공격 벡터 및 악성코드 개발 동향을 파악하는 것은 상근 직원이 필요한 일이며 모두가 동일한 수준의 전문성을 유지할 것이라고 기대해서는 안 됩니다.

다기능 팀에 보안 담당자를 불러와 다른 사람을 지도하고 모범 사례를 공유하도록 장려하면 보안 전문가와 협력을 위한 문화를 이해시키고 촉진하는 데 좋습니다.

보안을 설계상 제약 조건으로 설정

이상적으로는 코드를 작성하기 전에 보안을 먼저 고려해야 합니다. 보안을 사용자 스토리에 통합하고, 백로그 리뷰 회의 중 제기하며, 각 스프린트 계획 시 논의해야 합니다. 새로운 기능의 처리 방식을 모색할 때 그로 인해 어떤 위험이 발생할 수 있으며 위험을 완화하는 방법을 논의하는 데에도 시간을 할애해야 합니다.

STRIDE와 같은 위협 모델링 전략을 채택하거나 OWASP 치트 시트 등의 도구를 사용하면 새로운 기술을 배우는 동안 예상대로 진행할 수 있습니다. 설계 단계에서 보안을 고려하더라도 모든 것을 포착할 수는 없지만, 여전히 좋은 출발점이며 DevSecOps 문화의 촉진에 도움이 됩니다.

STRIDE 위협 모델링

자동화된 테스트에 보안 포함

자동화는 DevOps의 핵심 원칙입니다. 이를 통해 작업 속도가 빨라지고 일관성 있는 작업 수행이 보장되어 사람들이 더 창의적인 작업에 집중할 수 있게 됩니다. 사용자에게 정기적으로, 자주 소프트웨어를 제공하려면 파이프라인에 자동화된 보안 테스트를 추가해야 합니다.

자동화된 유닛 테스트, 통합 테스트 및 엔드투엔드 테스트를 작성할 때 보안 기능은 다른 기능만큼 중요한 것으로 고려해야 합니다. 팀에서 이미 보안 요구 사항을 사용자 스토리에 통합하고 설계 프로세스의 일부로 위협 모델에 대해 논의하고 있다면 보안 기능을 커버하는 테스트를 추가하는 것은 그러한 관행의 자연스러운 연장선입니다.

CI/CD 프로세스에 보안 테스트 도구 추가

직접 작성하는 테스트 외에도 코드 품질에 대한 신뢰를 구축하는 데 유용한 보안 테스트 도구가 다양하게 존재합니다. 기존의 보안 검사 도구는 자동화된 CI/CD 파이프라인에 적합하지 않았지만, 이제는 자동화를 위해 설계된 CI/CD 보안 테스트 도구를 사용할 수 있습니다. 이러한 도구는 CI/CD 파이프라인에 통합되어 대시보드를 통해 결과를 보고하거나 버그 추적 도구에 직접 제공할 수 있습니다. 모든 자동화된 테스트와 마찬가지로 최대한 빨리 피드백을 제공하도록 테스트를 구성하는 것이 좋습니다.

정적 애플리케이션 보안 테스트(SAST) 도구는 정적 코드 분석을 수행하여 소스 코드에서 버퍼 오버플로 및 SQL 삽입 가능성 등의 알려진 보안 결함을 확인합니다. 정적 분석은 소스 코드에서 실행되므로 변경 사항 커밋 즉시 CI/CD 파이프라인에서 조기에 수행할 수 있습니다.

SAST 도구는 언어별로 다르며 일부는 IDE에 통합되어 작성할 때 지속적인 피드백을 제공하거나 요청 시 테스트를 수행하는 옵션을 제공합니다. 또한 SAST 도구는 취약성이 포함된 특정 코드 줄로 개발자를 안내하여 대상이 명확한 지침을 제시하므로 이슈를 더 빨리 수정할 수 있습니다. 그러나 긍정오류가 문제가 될 수 있으므로 모든 SAST 결과가 관련성 낮은 노이즈가 되지 않게 하려면 일부 경고는 끄거나 해제할 필요가 있습니다.

CI/CD에서 SAST 도구 사용

동적 애플리케이션 보안 테스트(DAST)는 SAST와 긴밀하게 연결됩니다. DAST는 실행 중인 애플리케이션에 대한 블랙박스 테스트 방식을 사용하여 교차 사이트 스크립팅, 명령어 및 SQL 인젝션, 안전하지 않은 서버 구성 등의 알려진 취약점을 확인합니다. DAST 도구를 사용하려면 애플리케이션을 빌드하고 테스트 환경에 배포해야 하므로 일반적으로 CI/CD 파이프라인의 후반부에서 사용됩니다.

소프트웨어 공급망 보호

사이버 공격이 가능한 부분은 널렸습니다. 악의적인 공격자는 널리 사용되는 소프트웨어에서 보안 결함을 찾아내는 경우가 많습니다. 이를 비롯해 기타 이와 유사한 다른 공격은 소프트웨어 공급망을 보호하는 것이 얼마나 중요한지 일깨워 주는 중요한 사례입니다.

그런데 '소프트웨어 공급망'이란 무엇일까요? 간단히 말하면 소프트웨어 개발 및 제공과 관련된 모든 것입니다. 모든 소프트웨어 개발에는 재사용 가능한 구성 요소와 라이브러리부터 IDE, 프레임워크 및 빌드 도구에 이르기까지 다른 소프트웨어가 필요합니다. 소프트웨어 공급망 보안에는 사용자가 사용하는 소프트웨어의 보안을 평가하고 개발 프로세스를 보호하는 것이 포함됩니다.

평가는 소프트웨어 구성 또는 구성 요소 분석(SCA) 도구를 사용하여 수행할 수 있습니다. SCA 도구는 사용자가 추가한 종속성을 크롤링할 뿐 아니라 해당 종속성의 종속성도 공급망에서 재귀적으로 크롤링해야 합니다. 특히 프로젝트에 종속성이 얼마나 자주 추가되는지를 고려할 때 이는 컴퓨터에 가장 적합한 작업의 완벽한 예시입니다.

소프트웨어 공급망

일부 SCA 도구는 CI/CD 파이프라인의 일부로 자동 실행되며, IDE 플러그인으로도 지원되어 즉시 피드백을 제공할 수 있습니다. 정적 및 동적 보안 테스트와 마찬가지로 SCA 테스트도 도구가 인식하는 취약점에 한정될 수 있으므로, 선택한 도구가 새로운 취약점 공격에 따라 정기적으로 업데이트되며 제품 및 조직과 관련성이 있는 영역을 커버하는지 확인해야 합니다.

레드팀 불러오기

레드팀의 개념은 전쟁 게임에서 비롯되었으며, 자사의 방어력과 약점을 파악하기 위해 시뮬레이션 공격에서 팀원이 적의 역할을 수행하는 것입니다. 동일한 접근 방식이 소프트웨어 개발에 사용되며 큰 효과를 발휘했으며, 때로는 침투 테스트 또는 윤리적 해킹의 형식으로 진행되기도 하여 새롭고 예상치 못한 악용 사례를 찾기도 했습니다.

레드팀은 효과적인 작업을 위해 테스트 중인 시스템 개발에 참여할 수 없습니다. 탐색 테스트와 마찬가지로 레드팀의 테스터는 참신하게 사고하고 의도하지 않은 방식으로 소프트웨어를 사용해야 합니다.

레드팀은 스테이징 환경(이상적으로 프로덕션과 최대한 유사한 환경) 또는 라이브 프로덕션 시스템에서 작업할 수 있습니다. 후자를 선택한다면 소프트웨어의 오류 모드에 대한 신뢰 또는 매우 관대한 사용자(및 고위 임원)가 필요할 것입니다.

모든 취약점을 버그로 취급

DevSecOps 접근 방식에는 소프트웨어 보안에 책임이 있는 모든 사람이 포함됩니다. 그러므로 이제 보안 문제를 "일반적" 버그와 구분하는 사고는 중단해야 합니다. 시스템에서 발견한 모든 오류 또는 취약점은 다른 모든 문제와 동일한 백로그에 속하며, 그와 마찬가지로 우선순위가 지정되어야 합니다.

보안 책임자뿐만 아니라 전체 팀이 취약점을 해결해야 할 책임을 져야 합니다. 이를 통해 모든 사람이 보안 지식과 전문성을 구축하여 현재 코드 베이스와 향후 프로젝트에서 이러한 기술을 이용할 수 있게 됩니다.

프로덕션 모니터링

SDLC의 이전 단계에서 수행한 모든 노력에도 불구하고 해커가 라이브 시스템의 취약점을 찾아낼 위험이 여전히 존재합니다. 조직과 사용자 모두를 보호하기 위해 여전히 방화벽과 모니터링 도구에 투자할 가치가 있습니다. 런타임 애플리케이션 자체 보호(RASP) 도구는 최신 방어 도구로 의심스러운 동작을 자동으로 탐지하고 차단합니다.

마무리

  • DevOps 접근 방식에는 빌드 대상을 개선하고 변경 사항을 더 빠르게 출시할 수 있도록 설계된 정기적인 피드백 루프가 포함됩니다.
  • 보안을 조기 단계로 이동한다는 것은 SDLC의 모든 단계에서 팀 전체의 보안을 고려한다는 것을 의미합니다.
  • CI/CD 파이프라인에 보안을 적용한다는 것은 애플리케이션의 보안에 대한 피드백을 정기적으로 받고 나머지 기능과 동일한 방식으로 개선할 수 있음을 의미합니다.
  • 소프트웨어 공급망을 보호하는 것은 애플리케이션 코드를 보호하는 것만큼 중요합니다. 알려진 취약점을 확인하고 보호하면 알려진 취약점 공격에 무방비 상태로 노출되는 대신 소프트웨어가 공격에 맞춰 대비될 수 있습니다.
  • 모든 새로운 취약점을 이후 분류하여 수정하고 테스트할 버그로 취급하면 시간이 지날수록 소프트웨어가 더욱 강력하게 발전합니다.
  • DevOps와 DevSecOps는 도구와 프로세스 못지않게 문화와도 관련이 있습니다. 소프트웨어 개발 프로세스에 보안을 포함하려면 공동 책임의 문화가 필요합니다.