Fortify — 규제 산업을 위한 통합 보안 솔루션

개념

같은 SAST 계열, 다른 체급

레슨 1에서 SonarQube로 코드를 정적으로 분석하고 Quality Gate를 걸어봤다. Fortify (Micro Focus를 거쳐 현재 OpenText 제품군)도 같은 SAST 계열에서 출발한다 — 소스 코드를 실행하지 않고 훑어 취약점 후보를 찾는다.

하지만 두 도구는 겨냥하는 조직이 다르다.

하나의 플랫폼 안에 SAST와 DAST가 같이 있다

모듈 16(레슨 12)에서 다룬 ZAP·Burp Suite는 실행 중인 애플리케이션을 밖에서 공격해보는 DAST 였다. 레슨 1의 SonarQube는 코드를 읽는 SAST 였다. 둘은 보는 각도가 달라서 실무에서는 보통 둘 다 쓴다.

Fortify는 이 둘을 제품군 안에 함께 담는다.

Fortify Static Code Analyzer (SCA)   → SAST. 소스 코드 분석
Fortify WebInspect                   → DAST. 실행 중인 앱을 외부에서 스캔
Software Security Center (SSC)       → 두 결과를 한 곳에 모아 관리·리포팅

핵심은 세 번째 줄이다. 결과를 모으는 자리가 제품 안에 이미 있다는 것.

"기능이 더 강력해서"가 아니다

여기서 자연스럽게 나오는 질문이 있다. SonarQube + ZAP + SQLmap 같은 오픈소스 조합으로 대체하면 되지 않나? 개별 기능만 보면 대체로 된다.

문제는 그다음이다. 오픈소스 도구를 조합하면 각각이 서로 다른 형식의 결과 를 뱉는다. 그리고 규제 산업에서 진짜 일이 되는 건 스캔이 아니라 그 뒤다.

감사 대응에서 실제로 요구되는 것
- 이번 릴리스에 어떤 취약점이 몇 건 발견됐는가
- 각 항목이 언제, 누가, 어떤 근거로 조치 또는 예외 처리됐는가
- 그 조치가 어떤 규정 항목(PCI DSS, OWASP Top 10 등)에 대응하는가
- 지난 분기 대비 위험 추이는 어떠한가

오픈소스 조합에서는 이 네 줄을 만드는 작업 자체가 매번 수작업 이 된다. 누군가 스프레드시트를 열고 세 도구의 결과를 붙여넣고 중복을 지우고 규정 항목에 매핑한다. 감사가 분기마다 온다면 이 노동도 분기마다 반복된다.

Fortify가 파는 것이 바로 이 지점이다. 통합·추적·리포팅을 제품이 기본 기능으로 해결해준다. 선택 이유는 "탐지 성능이 더 좋아서"가 아니라 "규제 대응과 통합 리포팅이 필요해서" 다. 이 구분을 못 하면 도입 논의에서 엉뚱한 비교표를 만들게 된다.

실무에서 왜 필요한가

채용공고에 등장하면 읽어야 할 신호

모듈 22(레슨 5 계열)에서 HP ALM 같은 엔터프라이즈 도구를 다룰 때와 같은 독법이 적용된다. 채용공고의 도구 이름은 기능 요구사항이기 이전에 그 조직이 어떤 환경인지 알려주는 신호 다.

"Fortify 운영 경험" 이 적힌 공고에서 읽어낼 것
- 외부 감사·규제 심사를 정기적으로 받는 조직일 가능성이 높다
- 보안 요구사항이 릴리스 게이트로 걸려 있을 가능성이 높다
- 도구 도입·운영에 예산을 쓸 수 있는 규모다
- 반대로, 절차가 무겁고 릴리스 주기가 느릴 가능성도 함께 높다

QA 지원자 입장에서 Fortify를 직접 설치해볼 일은 거의 없다. 개인이 라이선스를 구할 수 있는 종류의 도구가 아니다. 그래서 이 레슨의 목표는 사용법 습득이 아니라 "왜 이 조직이 이 도구를 쓰는지 설명할 수 있는 것" 이다. 면접에서 유효한 답은 "써봤습니다"가 아니라 "규제 대응 때문에 통합 솔루션이 필요한 환경이라고 이해합니다"에 가깝다.

트레이드오프를 솔직하게

Fortify는 만능이 아니고, 오히려 대부분의 팀에는 과하다.

• 라이선스 비용이 매우 높다. 스타트업이나 중소 규모 팀이 감당할 수준이 아니다. 비용만으로 후보에서 빠지는 경우가 대부분이다.
• 도입·운영 복잡도가 크다. 전담 인력, 룰셋 튜닝, 서버 운영이 따라붙는다. 도구를 켜두는 것과 제대로 쓰는 것은 다른 일이다.
• 스캔이 느리다. 대규모 코드베이스 전체 스캔은 시간이 오래 걸려, 레슨 1에서 배운 것처럼 매 커밋마다 돌리는 방식과 잘 맞지 않는다.
• 오탐은 여전히 나온다. 상용이라고 오탐이 사라지지 않는다. 모듈 16(레슨 12)에서 배운 "스캐너는 후보를 줄 뿐"이라는 원칙은 그대로다.

그럼에도 규제 준수가 선택이 아닌 조직 에서는 마땅한 대안이 없다. 감사에서 "저희는 오픈소스 도구를 조합해 쓰고 결과는 수작업으로 취합합니다"라고 답했을 때, 그 취합 과정의 신뢰성을 증명하는 부담이 전부 조직에 돌아오기 때문이다.

실습 과제

과제 1 — 어느 조직에 맞는가 판단하기 (8분)

아래 세 조직에 SonarQube + ZAP 조합과 Fortify 중 무엇을 권할지, 그리고 그 판단의 결정적 근거 한 가지 를 적는다.

1. 개발자 15명 규모의 커머스 스타트업. 배포는 하루 여러 번.
2. 시중은행의 인터넷뱅킹 개발실. 금융감독 관련 외부 심사를 정기적으로 받는다.
3. 공공기관 사업을 주로 수주하는 SI 업체. 사업마다 보안성 검토 산출물을 제출해야 한다.

과제 2 — 도입 반대 논리 세우기 (8분)

"보안을 강화해야 하니 Fortify를 도입하자"는 제안이 들어온 상황에서, QA 담당자로서 먼저 확인해야 할 질문 세 가지 를 적는다. 도구를 반대하기 위해서가 아니라, 이 도구가 해결하는 문제(통합·감사)와 조직이 실제로 겪는 문제가 같은지 확인하기 위한 질문이어야 한다.

자가 체크리스트

• Fortify가 SonarQube와 같은 SAST 계열이면서 포지션이 어떻게 다른지 설명할 수 있다
• Fortify가 SAST와 DAST를 한 플랫폼에 통합한다는 것이 왜 핵심 가치인지 설명할 수 있다
• 오픈소스 조합의 한계가 "탐지 능력"이 아니라 "결과 통합과 감사 대응"임을 설명할 수 있다
• 채용공고의 Fortify 언급에서 조직의 규제 수준을 읽어낼 수 있다
• 높은 비용·운영 복잡도·느린 스캔이라는 트레이드오프를 함께 말할 수 있다

흔한 실수

• "상용이니까 오픈소스보다 성능이 좋다"고 정리한다. 선택 이유는 탐지 성능이 아니라 규제 대응과 통합 리포팅이다. 이 비교축을 틀리면 도입 논의 전체가 엉뚱한 방향으로 간다.
• 상용 도구라서 오탐이 없을 거라고 기대한다. 오탐 검증은 여전히 사람의 몫이다(모듈 16 레슨 12).
• 모든 조직에 통합 솔루션이 낫다고 일반화한다. 규제 요구가 없는 팀에는 비용과 복잡도만 남는다.
• Fortify를 "설치해서 써보는" 학습 대상으로 잡는다. 개인이 라이선스를 구하기 어렵다. 이 도구는 사용법이 아니라 선택의 맥락 을 이해하는 것이 학습 목표다.
• SAST 하나로 보안 테스트가 끝났다고 본다. 코드를 읽는 분석은 실행 중에만 드러나는 설정 오류·인증 우회를 잡지 못한다.

참고 자료

• OpenText Fortify 제품 페이지 — 제품군 구성(SCA, WebInspect, SSC)과 포지셔닝
• OWASP Source Code Analysis Tools — SAST 도구 계열 전반의 비교 관점
• PCI DSS 공식 문서 — 규제 준수 요구가 실제로 어떤 문서를 요구하는지 확인용