Summary
Application Security는 오랫동안 SAST, DAST, SCA를 중심으로 SDLC 전반에 보안 점검을 삽입하는 구조로 발전해 왔습니다. 이 방식은 많은 취약점을 넓게 찾는 데는 효과적이었지만, 현업에서 진짜 병목은 여전히 “무엇이 실제 문제인가”를 판정하는 과정에 있었습니다. NIST SSDF가 말하는 secure development의 기본 구조도 결국 개발 단계 전반에 보안 통제를 내재화하는 데 초점이 있으며, 시장의 실제 운영 비용은 탐지 자체보다 triage와 remediation coordination에서 커지는 경우가 많았습니다.
RSAC 2026 전후로 이 시장은 빠르게 재편되고 있습니다. Snyk는 AI Security Fabric과 Secure at Inception을, Checkmarx는 agentic application security를, Apiiro와 Cycode는 code-to-runtime context, AI guardrails, agentic development security를, HCL과 OpenText는 MCP 기반 AI 연동을 전면에 내세우고 있습니다. 즉, 2026년의 AppSec는 “더 잘 찾는 스캐너” 경쟁에서 “AI 속도로 예방·분석·우선순위화·수정·거버넌스를 운영하는 control plane” 경쟁으로 넘어가고 있습니다.
다만 이 보고서에서 말하는 검증은, 시장이 흔히 말하는 “AI가 한 번 더 읽어본다”, “컨텍스트를 더 붙여 exploitability score를 계산한다”, “fix가 맞는지 재확인한다”와는 다릅니다. 여기서의 검증은 PoC를 생성하고, 대상 서비스 또는 이에 준하는 검증 환경에서 실제로 실행해, 실행 결과를 통해 취약점의 존재를 증명하는 것입니다. OWASP는 LLM에 대한 과도한 신뢰가 hallucination과 잘못된 권고로 이어질 수 있다고 경고하고 있으며, 2025년 연구 역시 LLM 기반 vulnerability triage에서 false positive와 false negative의 한계를 지적하며 인간 분석가의 비판적 감독이 여전히 필요하다고 설명합니다.
반대로 PoC는 보안 업계에서 오래전부터 “취약점이 실제로 악용 가능함을 보여주는 코드 또는 공격 시연”으로 취급되어 왔습니다. CISA는 PoC를 “실행되면 exploitation을 허용하는 코드”라고 설명하고 있고, CVSS/NVD 역시 PoC exploit code의 존재를 exploit maturity의 중요한 단계로 다룹니다. 텍스트 기반 LLM 판단은 여전히 사람이 “이 설명이 맞는가”를 다시 검토해야 하지만, PoC가 실제로 실행되어 취약점이 재현되면 검증의 기준은 “모델의 주장”이 아니라 “시스템의 관측 결과”로 바뀝니다. 이 차이가 바로 Provally가 집중하는 검증의 본질입니다.
이전의 Application Security는 어떻게 하고 있었는가
기존의 Application Security는 본질적으로 탐지 중심 시장이었습니다. SAST는 코드를 정적으로 훑어 잠재적 결함을 넓게 탐지하고, DAST는 실행 중인 애플리케이션에 대해 공격 시뮬레이션을 수행하며, SCA는 오픈소스 의존성의 알려진 위험을 식별했습니다. 이 구조는 개발 초기 단계에서 취약점을 빨리 찾고 수정 비용을 낮추는 데 유효했지만, 동시에 대량의 alert와 오탐을 AppSec 팀 앞으로 밀어 넣는 구조이기도 했습니다.
중요한 점은, 과거에도 “실행 기반 검증”이 아예 없었던 것은 아니라는 사실입니다. DAST는 원래부터 live attack simulation을 통해 running application의 exploitable vulnerability를 찾는 접근이었고, penetration testing 역시 실제 공격 경로를 재현함으로써 위험을 입증하는 작업이었습니다. 그러나 이들은 대체로 런타임 discovery 도구였지, 기존 SAST 결과 하나하나를 받아 PoC를 생성하고, 해당 finding이 진짜 exploitable한지 증거를 남기는 verification layer는 아니었습니다.
AI 이후 무엇이 바뀌었는가
AI는 이 시장의 속도를 근본적으로 바꾸고 있습니다. 코드 생성 속도가 높아지자 시장의 관심도 “얼마나 많이 찾는가”에서 “개발 속도와 같은 속도로 위험을 막고, 정리하고, 고치고, 증명할 수 있는가”로 이동했습니다. Snyk는 Secure at Inception을 통해 코드 생성 시점부터 guardrail을 넣겠다고 말하고 있고, Semgrep은 AI reasoning과 rule-based analysis를 결합한 Multimodal을 내놓았으며, Checkmarx는 PR 안에서 triage와 remediation을 실행하는 agentic AppSec을, Cycode는 IDE 경계에서 프롬프트·파일·tool call을 통제하는 AI Guardrails를 강조하고 있습니다.
하지만 여기서 중요한 것은, 시장이 “검증”이라는 단어를 더 많이 쓰기 시작했음에도 그 의미가 대부분 재판독, 우선순위화, 운영 자동화에 머문다는 점입니다. Anthropic의 사례나 Snyk의 deterministic validation 언급은 업계가 이미 “AI가 찾는 속도보다 신뢰의 형성이 더 느리다”는 문제를 인식하고 있음을 보여줍니다.
전통 벤더의 변화
전통 벤더들은 기존 AST 포트폴리오를 버리지 않았습니다. 오히려 자신들이 이미 갖고 있던 대규모 설치 기반, policy, compliance, auditability 위에 AI를 얹어 precision, triage, remediation, governance를 강화하는 방향으로 움직이고 있습니다.
Veracode
2026년에는 RSAC 메시지를 AI precision, application risk governance, AI remediation, supply chain security로 재정리했고, “Prioritize, Protect, Prove”를 전면에 내세웠습니다. 다만 여기서 Veracode의 prove는 finding을 PoC로 실행해 입증하는 의미보다, due diligence와 governance evidence를 강화하는 의미에 가깝습니다.
Checkmarx
2026년에는 Triage Assist, Remediation Assist, Developer Assist, Attackability를 통해 agentic application security를 선언했습니다. 특히 Attackability는 attacker-controlled input, ingress point, control effectiveness까지 고려해 “실제 공격 가능성”을 더 잘 따지려 합니다. 그러나 이것 역시 본질적으로는 contextual exploitability analysis입니다.
OpenText Fortify
Application Security Aviator를 올려 finding 분류, false positive suppression, explainable results, auto-remediation을 제공했고, 2025년 하반기 이후에는 Fortify MCP Server로 Fortify 기능을 AI agents에 연결했습니다. 여전히 중심은 scan result auditing이며, 결과를 실행으로 증명하는 검증 레이어와는 다릅니다.
Black Duck
2026년에는 Signal을 출시하며 AI-native security가 risk를 assess하고 findings를 validate하며 remediation을 자동화한다고 강조합니다. 이는 분명 기존 플랫폼보다 한 단계 더 진화한 메시지입니다.
신흥 벤더의 변화
신흥 벤더들은 전통 벤더보다 더 빠르게 scanner company에서 control plane company로 이동하고 있습니다. Developer-first, workflow integration, AI-native prevention을 앞세워 코드 작성 시점과 PR, IDE, AI agent workflow를 장악하려는 방향으로 움직이고 있습니다.
Snyk
2026년에는 AI Security Fabric과 Agent Security, Evo AI-SPM으로 범위를 AI lifecycle 전체로 넓혔습니다. 특히 Snyk는 “enterprise trust still depends on deterministic validation”이라고 공개적으로 적시했습니다. 이 표현은 매우 중요합니다. 그러나 Snyk가 말하는 validation은 정책·거버넌스·continuous control을 위한 deterministic validation이지, 개별 finding을 PoC로 실행해 증명하는 방식은 아닙니다.
Semgrep
2026년에는 Cursor Plugin, MCP server, Hooks, Skills, Autofix, Multimodal을 통해 AI coding agent의 생성물까지 실시간 스캔하고, AI reasoning과 rule-based analysis를 결합하는 방향으로 더 진화했습니다. 이것은 “판단 자동화”를 매우 높은 수준으로 끌어올린 사례입니다. 다만 실행 기반 증거를 남기는 모델은 아닙니다.
Apiiro
2026년에는 Guardian Agent와 AI Threat Modeling으로 코드 생성 이전 단계에서 secure-by-design, compliant-by-default를 지향하는 방향으로 나아갔습니다. Static finding을 더 똑똑하게 해석하는 데는 강력하지만, PoC 실행으로 취약점 존재를 입증하는 verification과는 분명히 구분됩니다.
Cycode
2026년에는 Agentic Development Security Platform, Context Intelligence Graph, AI Guardrails를 내세우며 프롬프트 전송 전, 파일 첨부 전, tool call 실행 전 단계까지 통제하는 구조를 제시했습니다. 그러나 Cycode의 exploitability 역시 context-rich inference와 orchestration입니다.
스타트업의 변화
스타트업들은 상대적으로 더 좁은 웨지로 들어오지만, 가장 검증 문제에 가까이 접근하고 있습니다. Business logic, exploitability, autonomous pentest, verified closure 같은 주제를 직접 건드리기 때문입니다.
Gecko Security
2026년에는 static analysis가 business logic vulnerabilities를 구조적으로 놓친다고 명확히 주장했습니다. Cal.com 사례에서도 chained vulnerability와 account takeover를 보여주며, 단순 pattern matching을 넘는 semantic reasoning의 필요성을 강조합니다.
Cogent Security
Connect & normalize, prioritize with context, drive remediation, prove & report, context-to-decision-to-action-to-validation을 전면에 내세우고 있습니다. 그러나 Cogent의 validation은 본질적으로 remediation closure validation입니다. Provally는 그보다 앞단의 “이 finding이 처음부터 진짜인가”를 다룹니다.
Endor Labs
2026년에는 AURI를 “missing security intelligence layer”로 정의하며 AI coding agents의 코드가 애플리케이션 아키텍처와 어떻게 연결되는지까지 보겠다고 말합니다. Execution proof의 중요성을 강하게 인식하는 플레이어에 가깝습니다.
Aikido Security
2026년 Aikido Infinite를 통해 “pentest every release, validate exploitability, generate patches, retest fixes”를 전면에 내세웠습니다. 스타트업군 중 execution에 가장 가까운 메시지입니다.
왜 시장은 여전히 ‘검증’을 놓치고 있는가
이번 조사에서 확인되는 핵심은, 시장이 말하는 검증이 사실상 세 가지로 나뉜다는 점입니다.
AI 재판독
Finding을 모델이 한 번 더 읽고 true/false를 분류
컨텍스트 기반 추론
Code-to-runtime context로 exploitability를 계산
Remediation 검증
고쳤는지, retest 통과했는지 확인
하지만 Provally가 말하는 검증은 이 세 가지와도 다릅니다. 그것은 execution-based finding proof입니다. 즉, “이 finding이 실제로 exploitable한가?”를 PoC 코드 생성과 실행 결과로 증명하는 것입니다.
왜 이것이 아직 시장 중심이 아닌가에 대해서는 기술적 이유와 비즈니스적 이유가 함께 있습니다. 기술적으로는 PoC synthesis, 안전한 실행 환경, rollback, side-effect control, result interpretation, reproducibility까지 함께 다뤄야 하므로 난도가 높습니다. 비즈니스적으로는 기존 벤더 대부분이 scan → prioritize → fix → report 흐름에 최적화되어 있기 때문입니다.
Provally가 지금 풀고 있는 문제
Provally가 풀고 있는 문제는 탐지 이후, 사람이 다시 신뢰를 형성해야 하는 마지막 병목입니다. 즉, 기존 SAST가 뱉어낸 noisy findings를 받아, 각 finding별 PoC를 생성하고, 이를 실제로 실행해, 취약점이 존재한다는 관측 가능한 증거를 남기는 것입니다.
본질은 probabilistic judgment를 executable evidence로 바꾸는 것입니다. 바로 이 지점에서 Provally는 triage automation이 아니라 trust conversion을 하고 있습니다.
이 방식이 가져오는 변화
- 보안 엔지니어는 LLM의 설명을 다시 읽는 사람이 아니라, 실행 결과와 증거를 검토하는 사람으로 바뀝니다.
- 개발팀과의 커뮤니케이션이 “이론적으로 위험합니다”에서 “실제로 이렇게 재현됩니다”로 바뀝니다.
- Prioritization, remediation, governance 모두 더 신뢰할 수 있는 입력값 위에서 돌아가게 됩니다.
2026년의 보안 시장은 이미 코드, 오픈소스, IaC, container, API, AI assets까지 결과를 대량 생산하고 있습니다. 모든 도구가 더 많은 finding을 만들어내는 방향으로 가면 갈수록, 시장에는 그 finding을 “정말 실행 가능한 위험인가”로 바꾸는 상위 verification layer가 필요해집니다. Provally가 SAST verification layer로 시작해 장기적으로는 security proof layer로 확장할 것입니다.
In Conclusion
RSAC 2026의 Application Security 시장은 분명히 진화하고 있습니다. 그러나 그 진화의 핵심은 “AI가 더 많은 취약점을 찾는다”가 아니라, **“AI 속도로 생성되는 결과를 누가 더 신뢰 가능하게 만들 것인가”**에 있습니다.
- 전통 벤더는 precision, governance, remediation을 강화하고 있습니다. 그러나 그들이 말하는 검증은 대체로 auditing, prioritization, reporting의 의미에 가깝습니다.
- 신흥 벤더는 secure at inception, AI guardrails, code-to-runtime context, exploitability inference를 통해 control plane을 장악하려 하고 있습니다. 그러나 이 역시 대부분은 더 나은 판단을 만드는 과정이지, 실행으로 증명하는 과정은 아닙니다.
- 스타트업들은 business logic, autonomous pentest, verified closure 같은 더 어려운 문제로 접근하고 있습니다. 하지만 여전히 기존 noisy findings 전체 위에 올라가는 범용 proof layer는 시장에 거의 없습니다.
- 따라서 앞으로의 핵심 경쟁은 “무엇을 더 많이 찾는가”가 아니라, “무엇이 실제로 exploitable한지 PoC와 실행 결과로 얼마나 빨리 증명하는가”가 될 가능성이 높습니다. 그 관점에서 Provally의 SAST verification layer는 AI 시대 Application Security가 반드시 필요로 하게 될 신뢰 인프라의 시작점으로 볼 수 있습니다.