이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
CI/CD 파이프라인에서 SAST·DAST·Dependency Scan을 직접 구성한 경험은 없습니다. DevSecOps 수업에서 보안 검사를 파이프라인에 통합하는 핵심 이유는 "개발 단계에서 취약점을 발견하는 비용이 배포 후보다 훨씬 낮다"는 것임을 배웠습니다.
SAST는 소스코드를 정적으로 분석해 코드 수준의 취약점을 잡고, DAST는 실행 중인 애플리케이션에 공격을 시뮬레이션해 런타임 취약점을 찾는다는 차이를 배웠습니다. Dependency Scan은 사용 중인 라이브러리의 알려진 CVE를 자동으로 체크하는 것으로, 최근에는 공급망 공격이 늘면서 중요도가 높아졌다고 이해하고 있습니다.
직접 구성 경험은 없지만, 세 가지를 모두 적용할 때 중요한 건 오탐(False Positive)을 어떻게 관리하는가라고 봅니다. 오탐이 많으면 개발팀이 알람을 무시하는 패턴이 생기기 때문에, 기준 조율이 도입만큼 중요하다고 생각합니다.
CI/CD에 보안 스캔을 통합할 때 가짜 신호를 어떻게 처리하는지가 운영 품질을 결정합니다. SAST 도구가 탐지하는 모든 결과를 그대로 차단에 연결하면 빌드가 자주 멈추고 팀의 신뢰가 낮아집니다. 실제 악용 가능한 취약점과 잠재적 주의 항목을 구분하는 기준이 필요합니다.
Critical/High 이상의 항목만 빌드를 차단하고 나머지는 리포트로 추적하는 정책이 현실적인 운영 방식입니다. 모든 경고를 동일하게 처리하면 결국 경고 피로가 생기고 실제 중요한 취약점을 놓치는 자리가 생깁니다. 신호를 거르는 기준이 보안 스캔을 실질로 만드는 결이 됩니다. 도구의 결과보다 그것을 해석하는 기준이 더 중요한 자리입니다. 이 기준이 있어야 보안과 개발 속도의 균형이 만들어집니다. 기준을 팀과 공유하면 보안이 병목이 아닌 흐름의 일부가 됩니다.
CI/CD에 SAST, DAST, Dependency Scan을 통합하면서 막혔던 자리가 있습니다. 이론으로는 각 스캔이 어느 단계에서 실행되어야 하는지를 알지만, 서로 다른 도구들이 파이프라인에서 충돌하거나 실행 시간이 예상보다 오래 걸리는 문제는 직접 다뤄봐야 알 수 있는 자리입니다. 특히 DAST는 실행 중인 환경이 필요한데 이 환경을 CI/CD 파이프라인에 어떻게 포함할지가 복잡했습니다.
테스트 환경 프로비저닝과 보안 스캔 순서를 조율하는 것이 아직 약한 부분입니다. 막힌 자리를 인식하는 것이 다음 학습 방향을 구체적으로 만드는 결입니다. 이 인식이 보안 파이프라인 역량을 실질로 키우는 결이 됩니다. 막힌 경험이 있어야 비슷한 상황에서 더 빠르게 대안을 찾는 결이 만들어집니다. 이 경험이 쌓이면 도구 통합 설계에서 더 현실적인 판단을 하는 감각이 생깁니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.