답변.

애플리케이션 보안 검사의 자동화 아이디어는 사이버 위협이 증가함에 따라 발전했다. 처음에 보안 테스트는 거의 완전히 수작업이었지만, DevOps 및 자동화의 발전으로 CI/CD 파이프라인에 보안 체크를 통합할 수 있게 되었다.

질문의 역사

처음 몇 년 동안 수동 침투 테스트(pentest)와 스캐너가 유일한 취약점 검사 도구였다. 이후 개발 과정에서는 개별 자동화 스캐너가 등장했고, 그 후에는 프로세스에 통합되는 전체 플랫폼이 생겨났다.

문제

• 보안 테스트는 종종 오래 걸리고 드물게 업데이트된다.
• 많은 "거짓 양성"이 발생한다.
• 인프라 및 애플리케이션에 대한 복잡한 설정이 필요하다.
• 모든 취약점을 자동으로 찾을 수는 없으며, 일부 검사에서는 전문가의 분석이 필요하다.

해결책

1. CI/CD 단계에서 자동화된 보안 테스트를 통합: DAST/SAST 분석기, 자동 스캐너(OWASP ZAP, SonarQube, Checkmarx 등)를 사용한다.
2. 보고서와 테스트 시나리오를 정기적으로 업데이트하고, 거짓 양성에 대한 처리를 설정한다.
3. 자동화를 주기적인 수동 감사 및 회고와 결합한다.

주요 특징:

• SAST/DAST/RASP 스캐닝
• CI/CD와의 통합
• 인시던트 대응의 처리 및 자동화

낚시 질문.

모든 취약점을 오직 자동화된 테스트만으로 찾는 것이 가능한가?

아니다, 자동 검사는 보안 위험의 일부만을 커버한다(예: XSS, SQL 인젝션). 완전성을 위해서는 수동 감사도 필요하다.

하나의 유형의 스캐너(SAST 또는 DAST)만으로도 충분한 보호가 가능한가?

아니다, SAST는 애플리케이션 실행 전에 코드를 정적 분석하고, DAST는 실행 중 애플리케이션의 동작을 분석한다. 둘 다 사용해야 하며 추가적인 방법도 고려해야 한다.

배포 속도를 높이기 위해 CI/CD에서 보안 테스트를 비활성화하는 것이 좋을까?

아니다, 그러한 접근은 위험하다 — 이는 제품의 보안을 위태롭게 한다.

일반적인 실수 및 안티 패턴

• 스캐너 보고서 무시하기(거짓 양성 피로)
• 수동 및 자동 접근 방법의 통합 부족
• 보안 프로세스의 단일 부분만 자동화하기

실제 사례

부정적 사례

보안은 릴리스 단계에서 수동 분석만을 통해 검사되며, 가끔 스캐너를 사용하고 보고서는 CI/CD에 통합되지 않는다.

장점:

• 복잡한 취약점에 대한 "실시간" 감사

단점:

• 문제를 늦은 단계에서 발견
• 수정 비용이 높음

긍정적 사례

보안 테스트가 CI/CD에서 자동으로 배포되고, 주요 취약점이 릴리스를 차단하며, 거짓 양성을 위한 필터링 규칙이 설정되고, 추가적인 침투 테스트 세션이 분기마다 진행된다.

장점:

• 주요 취약점을 신속하게 발견
• 코드 변경 시 분석 보장

단점:

• DevOps 및 보안 전문가의 자원이 필요함
• 일부 취약점(논리적)은 수동으로만 발견됨