팀이 보통 마주하는 것
- 너무 많은 findings가 명백히 무해하거나 잘못 우선순위가 매겨져 있어 개발자들이 스캐너를 더 이상 신뢰하지 않습니다.
- 무엇이 중요한지, 무엇을 무시해야 하는지를 결정하는 수동 병목이 AppSec가 됩니다.
- 같은 오탐이 이후 스캔에서도 반복해서 돌아오는데, 그 결정이 공유되지도 지속되지도 않기 때문입니다.
신호 품질
실제 findings를 숨기지 않고 SAST 오탐 줄이기
대부분의 팀에게 어려운 점은 스캐너를 실행하는 일이 아닙니다. 어떤 findings를 믿고 리뷰할 수 있는지, 어떤 것은 suppression해야 하는지, 그리고 그 결정이 다음 스캔까지 어떻게 이어지는지가 핵심입니다.
SAST 오탐 줄이기
SAST 오탐이 운영 문제로 변하는 이유
AI 검토가 시작되기도 전에 휴리스틱 prefilter가 기본 노이즈를 제거합니다.
- 주요 병목이 스캐너 범위 그 자체보다 findings에 대한 신뢰일 때.
- CI가 병목이 되기 전에 개발자가 에디터 안에서 더 낮은 노이즈로 리뷰해야 할 때.
- suppression과 리포지토리 이력이 시간이 갈수록 신호를 개선하길 원할 때.
신뢰를 깨는 요소
SAST 오탐이 운영 문제로 변하는 이유
워크플로
시스템을 블랙박스로 만들지 않고 노이즈를 줄이는 방법
01
먼저 무해한 기본 노이즈 제거
일어나는 일
Oryon은 AI 검토 전에 휴리스틱을 적용해 가장 명백히 가치가 낮은 findings가 값비싼 리뷰 경로를 소비하지 않도록 합니다.
왜 중요한가
이렇게 하면 triage 계층이 컨텍스트와 판단이 가장 중요한 findings에 집중할 수 있습니다.
02
무엇이든 버리기 전에 엄격한 AI 합의 사용
일어나는 일
AI triage는 두 번의 패스로 실행됩니다. 두 패스가 독립적으로 제거에 동의할 때만 finding이 버려집니다.
왜 중요한가
이 방식은 시스템을 더 보수적으로 만들어 공격적인 노이즈 필터 아래 실제 이슈가 숨겨질 위험을 줄여 줍니다.
03
남아야 할 결정을 유지
일어나는 일
공유 suppression과 dashboard 이력은 이후 스캔이 올바른 컨텍스트를 상속받도록 해, 팀이 같은 무해한 findings를 반복해서 재판단하지 않게 합니다.
왜 중요한가
진짜 신호 품질은 필터링만이 아니라 메모리에서도 나옵니다. 시끄러운 스캔을 계속 이어 붙인다고 해결되지 않습니다.
적합한 경우
오탐 피로에 Oryon이 더 나은 답이 되는 경우
다음에 해당하면 Oryon을 선택하세요
- 주요 병목이 스캐너 범위 그 자체보다 findings에 대한 신뢰일 때.
- CI가 병목이 되기 전에 개발자가 에디터 안에서 더 낮은 노이즈로 리뷰해야 할 때.
- suppression과 리포지토리 이력이 시간이 갈수록 신호를 개선하길 원할 때.
다른 선택이 더 나은 경우
- 최우선 과제가 개발자 신호 품질보다 중앙집중형 정책 관리일 때.
- 팀이 가능한 가장 넓은 플랫폼 범위를 위해 더 많은 리뷰 노이즈를 감수할 때.
- 보안 루프가 에디터에서 시작할 필요가 없을 때.
FAQ
오탐이 주요 병목일 때 팀이 묻는 질문
- AI triage가 실제 취약점을 숨길 수 있나요?
- Oryon은 보수적으로 설계되었습니다. 두 번의 AI 패스가 모두 동의할 때만 finding이 제거됩니다. 충돌이나 불확실성이 있으면 유지됩니다.
- 공유 suppression이 리뷰를 대체하나요?
- 아니요. 팀이 이미 내린 결정을 기록해 이후 스캔이 그 컨텍스트를 재사용하도록 할 뿐입니다. 처음부터 다시 시작하지 않게 해 줍니다.
- Oryon은 기존 CI 스캐너와 함께 사용할 수 있나요?
- 네. 많은 팀이 더 넓은 CI 또는 플랫폼 스캐너를 유지하면서, Oryon으로 개발자 워크플로 안에서 신호 품질을 개선하고 triage를 더 앞당길 수 있습니다.