11,212 판독값

DevOps 파이프라인을 DevSecOps 파이프라인으로 전환하는 방법: Shift Left 개념 개요

~에 의해 Sofia Konobievska12m2023/09/08

너무 오래; 읽다

저는 Shift Left 개념이 무엇인지, 이것이 버그 수정 비용과 개발 시간을 줄이는 데 어떻게 도움이 되는지 설명했습니다. 개발 프로세스에서 보안 검사를 일찍 시작할수록 좋습니다. 그런 다음 DevSecOps 파이프라인 구조를 분해하고 파이프라인의 각 단계에서 어떤 보안 검사가 수행되는지 살펴보았습니다.

featured image - DevOps 파이프라인을 DevSecOps 파이프라인으로 전환하는 방법: Shift Left 개념 개요

안녕하세요, 해커눈입니다! 제 이름은 Sofia이고 DevOps/Cloud 엔지니어입니다. HackerNoon과 Aptible이 주최하는 콘테스트에 참가하기로 결정했습니다.

이 기사에서는 DevSecOps 파이프라인의 기능과 Shift Left의 개념에 대해 설명합니다. DevSecOps 파이프라인의 주요 단계, 소프트웨어 개발의 자동화된 보안 검사, 무료 오픈 소스 도구에 대해 알아봅니다. 또한 취약성을 조기에 감지하고 애플리케이션 보안을 향상시키는 데 도움이 되는 팁도 찾을 수 있습니다.

이 문서는 DevSecOps 파이프라인의 성숙도를 평가하고, 개발을 위한 로드맵을 개발하고, 각 작업에 적합한 도구를 선택하고, DevSecOps 철학에 따라 프로젝트를 관리하는 방법을 더 잘 이해하는 데 도움이 될 것입니다.

왼쪽으로 이동 개념

DevSecOps 방법론의 주요 목표는 DevOps 파이프라인, 즉 소프트웨어 개발 프로세스 자체에 자동화된 보안 검사를 도입하는 것입니다.

얼마 전까지만 해도 정보보안 전문가들이 개발 과정을 마치고 테스트를 진행한 적이 있다. 이 접근 방식은 비효율적입니다. 보안 테스트 중에 오류가 발견되면 전체 개발 주기를 다시 시작해야 합니다. 이는 시간이 많이 걸리고 비용이 많이 듭니다.

아래 이미지를 살펴보세요. 각 단계마다 오류 수정 비용이 증가하는 것을 볼 수 있습니다.

개발 및 기능 테스트 중에 발견된 보안 문제를 해결하는 데는 거의 비용이 들지 않습니다. 소스 코드에 필요한 모든 변경 사항을 즉시 적용하고 재확인을 위해 보낼 수 있습니다.

아티팩트 빌드 단계에서 문제를 해결하는 데는 최소한 두 배의 비용이 듭니다. 예를 들어 Dockerfile을 편집하는 등 빌드 프로세스를 변경해야 합니다. 즉, DevOps 엔지니어의 도움이 필요합니다.

통합 테스트 중에 오류가 감지되면 이를 수정하는 데 10배의 비용이 더 듭니다. 이 경우 개발 주기를 다시 시작하고 개발자, DevOps 엔지니어 및 테스터를 참여시켜야 합니다.

배포 단계에서 감지된 보안 문제는 사용자 데이터 유출로 이어질 수 있습니다. 회사는 수백만 달러의 벌금과 평판 손상을 받을 수 있으며, 이는 실수로 인한 비용이 수백 배 증가한다는 것을 의미합니다.

따라서 주요 결론은 가능한 한 빨리 안전 점검을 수행해야 한다는 것입니다. 시각화하면 파이프라인의 왼쪽으로 이동합니다. 이것이 바로 보안 전문가들이 즐겨 이야기하는 Shift Left의 개념입니다.

DevSecOps 파이프라인 구조

DevSecOps 파이프라인은 프로덕션 환경에서 애플리케이션을 구축, 테스트 및 제공하고 모든 단계에서 이를 보호하는 자동화된 프로세스 및 도구 체인입니다.

위 이미지는 보안 검사의 모든 주요 단계가 포함된 DevSecOps 파이프라인 구조를 보여줍니다. 다음은 각각에 대한 몇 가지 단어입니다.

사전 커밋. 이는 개발자가 버전 제어 시스템에 코드를 커밋하기 전에 소스 코드의 보안을 확인하는 것을 의미합니다. 이 검사를 통해 비밀번호나 API 키와 같은 암호화되지 않은 기밀 정보를 탐지할 수 있습니다.

사전 빌드. 이는 버전 관리 시스템에 들어간 후 소스 코드의 보안을 확인하는 것을 의미합니다. 이 도구는 소스 코드 및 해당 종속성에 대한 정적 분석을 수행하여 다음과 같은 일반적인 취약점을 탐지합니다. OWASP 상위 10위 목록.

빌드 후. Docker 파일, RPM 패키지 또는 JAR 아카이브와 같은 소스 코드로 구축된 아티팩트에 대한 보안 검사입니다. 이 도구는 애플리케이션 환경과 종속성을 분석하여 최신 버전에 이미 패치가 있는 오래된 버전의 패키지와 라이브러리를 찾습니다.

테스트 시간. 이는 수집된 아티팩트에서 실행되는 애플리케이션의 보안을 테스트하는 것을 의미합니다. 이 단계의 도구는 공격자의 행동을 시뮬레이션하여 애플리케이션을 "중단"하려고 합니다.

배포 후. 이는 애플리케이션이 프로덕션 환경에 배포된 후 애플리케이션의 보안을 확인하는 것을 의미합니다. 이 도구는 알려진 취약점의 공개 레지스트리를 실시간으로 모니터링하고 애플리케이션에 대한 위협이 감지되면 이를 알려줍니다.

다음으로 이러한 검사가 무엇인지, 검사를 수행하는 데 사용되는 도구는 무엇인지 자세히 살펴보겠습니다.

사전 커밋 확인

사전 커밋 검사를 사용하면 저장소의 로컬 복사본에 변경 사항을 커밋하기 전에 개발자 컴퓨터의 소스 코드를 분석할 수 있습니다. 명령문 중 하나라도 오류를 반환하면 커밋이 수행되지 않습니다. 이 경우 개발자는 실수를 수정하고 다시 커밋해야 합니다.

이 검사는 예를 들어 암호화되지 않은 비밀이 포함된 검사되지 않은 코드가 저장소에 들어가는 상황을 방지합니다.

커밋 전 소스 코드 검사를 수행하려면 개발자의 로컬 컴퓨터에 도구를 설치해야 합니다. 이 접근 방식에는 장점뿐만 아니라 단점도 있습니다. 예를 들어, 환경적 차이가 있습니다. 다양한 버전의 계측기, 다양한 운영 체제, 심지어 프로세서 아키텍처도 있습니다.

개발자가 서로 다른 버전의 사전 커밋 도구를 사용하는 경우 검사 결과가 달라지며 이로 인해 공동 작업이 어려울 수 있습니다. 팀 내에서 또는 회사 전체에서 커밋 전 검사를 구현할 때 이를 고려하세요.

커밋 전 검사 도구

다양한 오픈 소스 도구를 사용하여 커밋 전 검사를 설정할 수 있습니다.

커밋 전 검사를 위한 훌륭한 도구입니다.

빌드 전 검사

빌드 전 단계에서는 화이트 박스 테스트가 수행됩니다. 이러한 검사는 이전 단계와 마찬가지로 소스 코드를 분석하는 데 사용됩니다. 이 경우 애플리케이션은 아키텍처와 내부 구조를 알고 이해하고 있기 때문에 "화이트 박스"입니다.

빌드 전 검사에는 여러 유형이 있습니다.

비밀 탐지
정적 애플리케이션 보안 테스트(SAST)
소프트웨어 구성 분석(SCA)

이제 자세히 논의해 보겠습니다.

사전 구축된 비밀 탐지 검사

비밀 탐지는 암호화되지 않은 민감한 정보, 즉 버전 제어 시스템에 입력된 소스 코드의 암호화되지 않은 비밀을 탐지하는 자동화된 검사입니다.

빌드 전 검사는 소스 코드가 버전 제어 시스템의 저장소에 들어간 후 수행됩니다. 따라서 예를 들어 저장소의 콘텐츠가 유출되는 경우 저장소에 있는 암호화되지 않은 모든 민감한 데이터는 공격자가 잠재적으로 액세스할 수 있습니다.

또한 비밀 탐지 검사를 구현하는 프로세스는 처음부터 시작하는 것이 아니라 발전하는 프로젝트에서 발생할 수 있습니다. 이 경우 암호화되지 않은 비밀이 이전 커밋과 다른 저장소 분기에서 발견될 수 있습니다.

이러한 문제를 해결하려면 우리는 다양한 일을 해야 합니다. 예를 들어, 암호화되지 않은 비밀 저장소를 정리하거나 Hashicorp Vault 와 같은 다양한 비밀 관리 도구를 구현해야 합니다.

비밀 탐지 도구

비밀 탐지는 다음을 사용하여 구성할 수 있습니다. Gitleaks , 자식 비밀 , 또는 비밀 감지 . 그러나 잘 알려진 CI/CD 플랫폼에서 제공하는 서비스를 사용하는 것이 가장 좋습니다. GitLab 비밀 탐지 .

사전 구축 SAST 확인

SAST(정적 애플리케이션 보안 테스트)는 분석기가 구문 정확성을 확인할 뿐만 아니라 고유한 메트릭을 사용하여 코드 품질을 측정하는 테스트입니다. SAST 스캐너의 주요 임무는 보안 테스트입니다.

특히 SAST 분석기에는 일반적인 취약점에 대한 소스 코드가 포함되어 있습니다. OWASP 상위 10위 기울기. SAST 스캐너는 취약점 자체뿐만 아니라 취약점을 유발한 코드 조각도 찾아낸다는 점은 중요합니다.

SAST 분석은 분석기가 애플리케이션의 내부 구조에 접근할 수 있기 때문에 화이트 박스 테스트(White Box Testing)라고 불립니다. 분석기는 소스 코드를 실행하지 않고 확인하므로 잘못된 긍정을 생성하고 일부 취약점을 감지하지 못할 수 있다는 점에 유의하는 것이 중요합니다.

이러한 이유로 SAST 분석에만 국한되어서는 안 됩니다. 문제에 포괄적으로 접근하고 SCA, DAST, IAST, OAST 등 다양한 유형의 분석을 사용하는 것이 좋습니다.

SAST 도구

독점 솔루션:

무료 솔루션은 GitLab SAST입니다.

사전 빌드 소스 SCA 확인

SCA(소프트웨어 구성 분석)는 오픈 소스 구성 요소를 분석하여 애플리케이션을 보호하는 방법론입니다.

SCA 스캐너는 알려진 취약점과 악용을 포함하는 오래된 종속성을 찾습니다. 또한 일부 SCA 도구는 구성 요소의 라이선스 호환성과 라이선스 침해 위험을 확인할 수 있습니다.

소스 SCA는 소스 코드, 특히 소스 코드에 정의된 애플리케이션 종속성을 분석합니다. 이 분석을 종종 종속성 검색이라고 합니다.

SCA를 사용하면 한 구성 요소의 취약성이 모든 애플리케이션의 보안 문제로 이어질 수 있는 문제를 감지할 수 있습니다.

좋은 예는 다음과 같습니다 Log4Shell . 이 취약점은 2021년 후반에 널리 사용되는 Java 로깅 프레임워크인 Log4j에서 발견되었습니다. 이 취약점은 공격자가 수억 대의 장치에서 임의의 Java 코드를 실행할 수 있도록 허용하므로 가장 두려운 취약점 중 하나가 되었습니다.

SCA 도구

퀴즈 오픈 소스 솔루션입니다.

무료 가격 계획을 갖춘 상용 솔루션:

GitLab(Ultimate 버전에서만 사용 가능)의 일부로 다음을 사용할 수 있습니다. GitLab 종속성 검색 .

빌드 후 검사: 바이너리 SCA

빌드 후 단계는 CI 파이프라인의 소스 코드(Docker 이미지, RPM 패키지 또는 JAR 아카이브)에서 아티팩트가 빌드된 후에 수행됩니다. 빌드 후 확인을 통해 이러한 바이너리 아티팩트의 종속성을 분석할 수 있습니다.

바이너리 SCA 분석에는 Docker 이미지, RPM 패키지, JAR/WAR/EAR 아카이브와 같은 바이너리 아티팩트 검사가 포함됩니다. 흔히 컨테이너 스캔이라고도 합니다. 즉, 빌드 후 단계 이전이 아니라 바이너리 아티팩트가 빌드될 때 실행하는 것이 합리적입니다.

Docker 이미지로 작업할 때 몇 가지 흥미로운 기능이 있습니다. 바이너리 SCA 분석기는 Docker 이미지의 레이어를 확인하고 이를 다음과 같은 공개 취약성 데이터베이스에서 해시 합계로 찾습니다. 국가 취약점 데이터베이스(NVD) 또는 Snyk 취약점 DB .

일부 분석기는 취약한 구성 요소를 찾을 수 있을 뿐만 아니라 이미 수정된 취약성이 있는 구성 요소의 최소 필수 버전을 지정하여 수정 사항을 제안할 수도 있습니다.

널리 사용되는 바이너리 SCA 분석기의 예

무료 솔루션은 GitLab 컨테이너 스캐닝 .

오픈 소스 솔루션:

분석기가 내장된 Docker 레지스트리 - 항구 .

테스트 시간 확인: DAST, IAST 및 OAST

이 단계에서는 동적 Gray Box 테스트와 Black Box 테스트가 수행됩니다. 애플리케이션의 내부 구조가 부분적으로 또는 전체적으로 알려지지 않은 경우 이러한 보안 검사는 취약점을 발견하고 이를 악용하여 애플리케이션을 "중단"시키려는 공격자의 행동을 에뮬레이션하여 수행됩니다. DAST, IAST, OAST 각각에 대해 간략하게 살펴보겠습니다.

테스트 시간 DAST 확인

DAST 스캐너는 다양한 취약점을 통한 외부 공격을 시뮬레이션하여 애플리케이션을 자동으로 테스트합니다. 애플리케이션은 분석기를 위한 블랙박스입니다. 그것에 대해서는 알려진 바가 없습니다.

DAST 검사를 위해서는 스캐너에 사용할 수 있는 실행 중인 응용 프로그램 인스턴스가 있어야 합니다. 또한 애플리케이션 테스트 인스턴스의 매개변수가 프로덕션 설치에 가까울수록 오탐(false positive)이 줄어듭니다.

예를 들어, HTTP 프로토콜을 통해서만 액세스할 수 있는 테스트 애플리케이션 인스턴스를 배포했지만 프로덕션에서는 HTTP 프로토콜을 통해서만 애플리케이션에 액세스할 수 있다고 가정합니다.

이 경우 DAST 스캐너는 클라이언트(분석기)와 서버(응용 프로그램 인스턴스) 간의 트래픽 암호화 부족과 관련된 일부 오류를 생성합니다.

DAST 도구의 예

주목할 만한 도구:

GitLab DAST — Ultimate 버전에서만 사용 가능
OWASP Zed 공격 프록시(ZAP) — GitLab DAST에서도 사용되는 오픈 소스 솔루션
아큐네틱스
Fortify WebInspect
HCL 보안 AppScan
Synopsys 관리형 DAST
Tenable.io (웹앱 스캐닝)
Veracode 동적 분석

좋습니다. 계속하세요.

테스트 시간 IAST 확인

IAST(Interactive Application Security Testing)는 White Box Testing SAST와 Black Box Testing DAST의 장점과 장점을 결합한 Gray Box Testing입니다.

SAST 및 DAST 방법의 모든 장점을 수집하고 단점을 제거하기 위해 개발자는 이러한 방법을 결합한 하이브리드 메커니즘인 IAST를 개발했습니다. 코드 분석을 통해 애플리케이션 작동에 대한 더 많은 정보를 제공하므로 동적 테스트의 정확성이 높아집니다.

IAST에는 장점 외에도 한계가 있다는 점을 기억할 가치가 있습니다. 가장 기본적인 것은 테스트 중인 애플리케이션이 작성된 언어에 대한 의존성입니다. IAST 솔루션은 애플리케이션 수준에서 작동하며 해당 동작을 분석하려면 실행 코드에 액세스해야 합니다.

이는 IAST 솔루션이 애플리케이션이 작성된 프로그래밍 언어를 이해할 수 있어야 함을 의미합니다. 특정 IAST 솔루션에 대한 지원은 다른 언어보다 일부 언어에 대해 더 잘 구현될 수 있다는 점에 유의해야 합니다.

IAST 분석에도 시간이 오래 걸립니다. 애플리케이션의 크기와 복잡성, 외부 종속성 수, 사용된 IAST 도구의 성능 등 다양한 요소에 따라 달라집니다.

게다가 분석 프로세스에서는 코드 자체를 스캔하지 않고 직접 실행되는 조각만 확인합니다. 따라서 IAST 분석은 가능한 한 많은 애플리케이션 시나리오를 테스트할 수 있는 경우 기능 테스트와 가장 잘 결합됩니다.

IAST 도구의 예

다음은 훌륭한 도구입니다.

좋습니다. 계속하세요.

테스트 시간 OAST 확인

OAST(Out-of-Band Application Security Testing)는 에서 개발한 기술입니다. 포트스위거 log4shell과 같이 DAST가 볼 수 없는 취약점을 찾는 DAST의 확장입니다.

OAST 도구의 예

나는 당신을 추천합니다:

버프 스위트
OWASP ZAP을 사용하여 OAST 플러그인
OAST 서비스 자랑 , 툭툭 , 그리고 상호작용하다

계속하세요.

배포 후 확인

이는 애플리케이션 보안 및 운영성을 보장하는 데 필수적인 단계입니다. 개발 단계에서 수행되는 커밋 전 검사와 달리 배포 후 검사를 사용하면 자연 환경에서 애플리케이션을 작동하는 동안 이미 발생할 수 있는 문제를 식별할 수 있습니다.

유물의 안전성 모니터링

적시에 새로운 취약점을 탐지하려면 애플리케이션이 배포된 후를 포함하여 정기적인 아티팩트 검사를 수행해야 합니다.

이는 다음과 같은 특수 저장소나 도구를 사용하여 수행할 수 있습니다. 스닉 컨테이너 , Trivy, GitLab 컨테이너 검색 또는 통합 모듈 개발.

애플리케이션 보안 모니터링

보안을 보장하는 또 다른 방법은 애플리케이션 자체를 모니터링하는 것입니다. 이 목적을 위해 사용할 수 있는 몇 가지 기술이 있습니다.

WAF(웹 애플리케이션 방화벽)는 트래픽 필터링 도구입니다. 애플리케이션 계층에서 작동하며 HTTP/HTTPS 트래픽을 분석하여 웹 애플리케이션을 보호합니다.

RASP(Runtime Application Self-Protection)는 애플리케이션에 대한 공격을 실시간으로 탐지하고 차단하는 기술입니다. 런타임 환경에 방어 기능을 추가하여 애플리케이션이 자동으로 자체 보호되도록 합니다.

WAF에 비해 RASP의 주요 장점은 애플리케이션의 작동 방식을 이해하고 공격과 불법 트래픽을 탐지한다는 것입니다. RASP는 시그니처 매칭을 활용한 일반적인 공격뿐만 아니라 이상 징후에 대응해 제로데이 취약점을 악용하려는 시도도 확인할 수 있다.

WAF와 달리 RASP는 애플리케이션 내에서 작동합니다. WAF는 속일 수 있습니다. 공격자가 애플리케이션 코드를 변경하면 WAF는 실행 컨텍스트를 이해하지 못하기 때문에 이를 감지할 수 없습니다.

RASP는 애플리케이션에 대한 진단 정보에 접근하여 이를 분석하고 이상 징후를 탐지하며 공격을 차단할 수 있습니다.

RASP 기술은 기본적으로 공격을 예방하는 데 중점을 둔다는 특징이 있습니다. 시스템에는 소스 코드에 대한 액세스가 필요하지 않습니다.

RASP 바보들

나는 당신을 추천합니다:

확고히 하다
스크린
오픈RASP Baidu가 개발한 오픈 소스 솔루션입니다.
신호 과학
Jscrambler
HDiv
임페르바

좋습니다. 계속하세요.

DevSecOps 파이프 라인 결과 및 취약성 관리 시각화

파이프라인의 여러 단계에서 저는 많은 애플리케이션 보안 테스트/DevSecOps 분석기를 사용합니다. 그들 각각은 고유한 형식으로 보고서를 생성하며, 그 중 일부는 소위 거짓 긍정(False Positive)을 생성합니다. 이 때문에 애플리케이션의 보안을 전체적으로 분석하는 것은 쉽지 않습니다.

취약점을 효과적으로 분석하고 해결 프로세스를 관리하기 위해 간단히 보안 대시보드 라고도 하는 전문적인 취약점 관리 도구가 사용됩니다.

보안 대시보드는 DevSecOps 분석 결과를 통합되고 분석하기 쉬운 형식으로 제공하여 문제를 해결합니다. 이러한 방식으로 보안 엔지니어는 어떤 문제가 존재하는지, 어떤 문제가 가장 중요한지, 어떤 문제를 먼저 해결해야 하는지 확인할 수 있습니다.