왜 87%의 Security Findings는 절대 해결되지 않을까 (그리고 우리가 해결한 방법)
Source: Dev.to
보안 스캐너가 방금 847건의 발견을 표시했습니다. 개발자들은 그 중 정확히 12건만 수정할 것입니다.
다음 주에 스캐너가 913개의 문제를 찾습니다. 팀은 8개만 고칩니다. 이 사이클이 반복됩니다.
이것은 게으름이 아닙니다. 이것은 부주의가 아닙니다. 이것은 깨진 시스템의 예측 가능한 결과입니다.
개발자들이 보안 발견을 무시하는 이유
20,000+ 풀 리퀘스트를 분석하고 수백 명의 개발자를 인터뷰한 결과, 세 가지 일관된 패턴을 발견했습니다:
1. 컨텍스트 격차
보안 스캐너는 무엇이 잘못됐는지를 보여줍니다. 하지만 어디서 중요한지, 실제 코드베이스에서 어떻게 수정해야 하는지는 거의 보여주지 않습니다. “SQL Injection vulnerability detected”(SQL 인젝션 취약점이 감지되었습니다)라는 메시지를 본 개발자는 다음을 이해해야 합니다:
- 어떤 특정 쿼리가 취약한지
- 어떤 사용자 입력이 해당 쿼리에 도달할 수 있는지
- 기존 기능을 깨뜨리지 않으면서 어떻게 수정할지
- 이 수정이 코드 리뷰를 통과할 수 있는지
2. 오탐 세금
**60‑80 %**의 발견이 오탐이거나 컨텍스트와 무관할 때, 개발자들은 모든 발견을 무시하는 법을 배우게 됩니다. 이는 비합리적인 신호‑대‑잡음 비율에 대한 합리적인 반응입니다.
3. 마찰 문제
개발자들이 문제를 해결하고 싶어도 가장 저항이 적은 경로는 다음과 같습니다:
- “해결하지 않음”으로 표시
- 백로그에 추가(거기서 사라짐)
- 티켓 생성(아무도 우선순위를 두지 않음)
실제 수정에는 컨텍스트 전환, 조사, 테스트, 리뷰가 필요합니다. 대부분의 보안 발견은 그 정도의 인지 부하를 정당화할 만큼 긴급하지 않습니다.
근거 기반 접근 방식
우리는 다른 시스템을 구축했습니다. 단순히 문제를 표시하는 대신, 우리는 다음을 수행합니다.
1. 실제 수정 사항 생성
우리의 복구 엔진은 코드베이스를 분석하고 다음을 포함한 바로 병합 가능한 풀 리퀘스트를 생성합니다:
- 코드 스타일에 맞는 컨텍스트‑인식 수정
- 회귀를 방지하는 자동화된 테스트
- 취약점과 수정 사항을 설명하는 문서
2. 신뢰도 점수 부여
모든 발견이 동일한 가치를 갖는 것은 아닙니다. 우리는 각 발견을 다음을 기준으로 점수화합니다:
- 도달 가능성 – 신뢰할 수 없는 입력이 실제로 이 코드에 도달할 수 있는가?
- 악용 가능성 – 이론적으로 취약한가, 실제로 악용 가능한가?
- 영향 – 악용될 경우 파급 효과는 어느 정도인가?
- 수정 품질 – 생성된 수정에 대한 신뢰도는 어느 정도인가?
신뢰도가 높은 발견만 풀 리퀘스트로 전환됩니다. 나머지는 설명만 제공되고 자동화되지 않습니다.
3. 개발자‑우선 설계
복구는 개발자의 기존 워크플로우 내에서 이루어집니다:
# Before: Security finding in dashboard
Finding ID: SEC-4721
Severity: HIGH
File: api/auth.py
Issue: Hardcoded secret detected
# After: Pull request in your inbox
PR #842: Remove hardcoded API key from auth module
✅ Fix verified
✅ Tests passing
✅ Zero‑trust secret management configured
📚 Learn more: [Hardcoded secrets are dangerous]실제 결과
- 87 % → 94 % 고신뢰 발견에 대한 수정 비율
- 3 days → 4 hours 수정 중간 시간
- 60 % reduction 거짓 양성 노이즈 감소
- Zero additional meetings 또는 프로세스 변경이 전혀 필요 없음
코드: 진화형 복구 엔진
우리는 전체 시스템을 오픈소스로 공개했습니다. 포함 내용은 다음과 같습니다:
템플릿 엔진
취약점 패턴을 기반으로 언어별 수정을 생성합니다.
# Example: SQL injection fix template
template = RemediationTemplate(
vulnerability="sql_injection",
language="python",
fix_strategy="parameterized_query",
confidence_threshold=0.85,
)증거 분석기
다양한 신호를 바탕으로 결과에 점수를 매깁니다.
scorer = ConfidenceScorer()
score = scorer.evaluate(
reachability=reachability_analysis(code),
exploitability=exploit_complexity(vuln),
impact=blast_radius(code_context),
fix_quality=test_coverage(generated_fix),
)PR 생성기
머지 준비가 된 풀 리퀘스트를 생성합니다.
pr = PRGenerator(
finding=security_finding,
fix=generated_fix,
tests=automated_tests,
docs=vulnerability_explanation,
)
pr.create(repo="your-org/your-repo")직접 해보기
🔗 GitHub:
빠른 시작
git clone https://github.com/AuraquanTech/evolutionary-remediation-engine
cd evolutionary-remediation-engine
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
# Run analysis
python analyze.py --repo /path/to/your/repo
# Generate fixes
python remediate.py --findings findings.json --create-pr디자인 파트너에게 영구 무료 프리미엄 제공
우리는 100명의 디자인 파트너를 찾고 있습니다:
- 실제 코드베이스에서 엔진 테스트
- 수정 품질에 대한 피드백 제공
- 언어/프레임워크 지원 우선순위 지정 도움
대가로:
- 영구 무료 프리미엄 기능 제공 (bait‑and‑switch 없음)
- 엔지니어링 팀과 직접 연결
- 로드맵에서 귀하의 사용 사례 우선순위 지정
- 원한다면 공동 마케팅 기회
관심 있으신가요? 댓글을 남기거나 직접 연락 주세요.
핵심 요약
보안 발견이 해결되지 않는 이유는 시스템이 탐지에 최적화되어 있고, 수정에는 최적화되지 않았기 때문입니다. 우리는 반대 방향으로 최적화된 시스템을 구축했습니다: 수정을 너무 쉽게 만들어 무시하는 것이 적용하는 것보다 더 많은 노력이 들도록.
코드는 오픈 소스입니다. 접근 방식은 증거 기반입니다. 결과는 스스로 말해줍니다.
가장 큰 보안 수정 과제는 무엇인가요?
보안 발견을 해결하는 데 가장 큰 장애물은 무엇인가요?
댓글에서 논의해 주세요.