Vercel’s release of deepsec is interesting, but not because another security tool showed up.
That’s the easy story, which can be read here: Introducing deepsec: The security harness for finding vulnerabilities in your codebase
The more important story is that teams are still trying to answer a hard security question with a soft checkbox. Did we scan the code? Did the tool run? Did the pipeline pass? Did someone export findings into tickets?
Fine. But none of that proves the application is secure. It only proves an activity happened.
deepsec is useful because it pushes past the surface-level scan. It uses coding agents to investigate security-sensitive files, trace data flows, check mitigations, revalidate findings, and enrich results with ownership context. That matters. It gets closer to how a real security engineer thinks through a codebase instead of just throwing a list of findings over the wall and calling it governance. But this is also where leaders need to be careful. A better checkbox is still a checkbox if nobody builds the operating model around it.
The real problem is false confidence
Most AppSec programs don’t fail because they had zero tools…they fail because they trusted one control too much.
One SCA scan, one SAST scan, one DAST scan, one pipeline gate, all with one dashboard. One “critical findings only” policy that everyone quietly routes around when the release is late. “Gotta close out all Crit1 on the list before go-live.” You know the drill where the tool runs, which generates the report. Then tickets are opened and ultimately closed and the team feels like security has been handled.
But then the issue shows up somewhere the control never reached! That is the problem with checkbox security. It gives leadership a clean story and gives attackers a messy reality.
What deepsec gets right
The smart part of deepsec is the workflow.
It doesn’t just scan and stop. It starts with static discovery, then sends “agents” into the codebase to investigate candidate areas. It revalidates findings to reduce false positives. It enriches findings with git metadata so ownership is clearer. Then it exports results into instructions that humans or coding agents can turn into work. That is a better model than the usual “here are 900 findings, good luck” approach.
The important pieces are:
- investigation, not just detection
- revalidation, not just reporting
- ownership mapping, not just severity labels
- workflow export, not just dashboard decoration
- customization for auth, data, and team patterns
That last point matters a lot (at least to me). Generic scanners miss business-specific risk all the time. Authentication models, tenant boundaries, entitlement checks, data access patterns, internal APIs, and workflow assumptions are where real exposure often lives, with the problem being that the scanner doesn’t know your business logic unless you teach it.
But it still cannot be the whole strategy
This is the part orgs/teams need to hear. Agentic security tools are going to help, with out a doubt. They will find issues traditional scanners miss. They will reduce some manual review burden, and hopefully they will make security investigation faster. They will not replace layered application security testing but you still need SCA, SAST, DAST and you need them all working together, not sitting in separate dashboards like three departments that don’t talk.
SCA tells you what third-party risk you dragged into the application. Open-source packages, transitive dependencies, vulnerable components, license issues, container risk, supply chain exposure.
SAST looks at the code before it runs. Insecure patterns, dangerous flows, injection paths, hardcoded secrets, weak validation, unsafe calls, missing controls.
DAST tests the running application. Authentication behavior, reachable endpoints, exposed services, runtime misconfiguration, injection paths, headers, session issues, API behavior.
Each one sees a different version of the truth and each one misses things. That is not a tool failure. That is why the layers exist.
The second and third layer matter
A lot of teams want one tool to be the answer because one tool is easier to explain and justify to procurement. That’s not how application security works.
A SAST finding may show a risky code pattern, but DAST may prove whether the path is reachable in a running environment. SCA may flag a vulnerable package, but additional analysis may be needed to know whether the vulnerable function is actually used. DAST may find exposed behavior, but SAST may help trace where the defect lives in the code.
The layers should challenge each other, and that is how you reduce false confidence.
A mature AppSec model should answer:
- What vulnerable components are present?
- What insecure code paths exist?
- What attack paths are reachable at runtime?
- Which findings are exploitable in this application?
- Which risks should block release?
- Who owns the fix?
- Was the fix validated after remediation?
That is the difference between scanning and security control validation.
ASPM is where the work starts to make sense
Once you have SCA, SAST, DAST, agentic review, cloud findings, container findings, secrets detection, IaC checks, and manual pen test results, the next problem is obvious.
Nobody can make sense of it.
Every tool thinks its finding is important and every dashboard has its own severity model. Every team has its own workflow with their developers getting flooded. This leads to security getting ignored. Leadership gets a rollup that looks precise but usually hides the real operational mess underneath. And that my friends is where ASPM becomes important.
An Application Security Posture Management platform helps aggregate findings across the AppSec stack, normalize severity, deduplicate noise, map issues to applications and owners, and show where risk is actually concentrated.
Without that layer, AppSec becomes a pile of disconnected activity.
With it, you can start making better decisions:
- which applications carry the most risk
- which teams are overloaded
- which findings are duplicated across tools
- which issues are reachable and exploitable
- which risks are aging past policy
- which release gates are working
- which controls are mostly theater
A security program should be able to tell the difference between a control that runs and a control that works.
What should leaders take from deepsec?
deepsec is a strong signal of where application security is going. Security testing is becoming more investigative, more code-aware, more contextual, and more workflow-driven. Good…That’s overdue…but the lesson is not “install deepsec and sit on a beach.” The lesson is that traditional checkbox security is weak, and agentic tooling only helps when it becomes part of a layered validation model.
The better operating model looks like this:
- Use SCA to understand inherited component and supply chain risk.
- Use SAST to catch insecure code patterns early.
- Use DAST to test exposed runtime behavior.
- Use agentic security investigation to find subtle logic, auth, and data-flow issues.
- Use ASPM to aggregate, deduplicate, prioritize, and govern the work.
- Use release gates to block risk that matters.
- Use revalidation to prove the fix actually worked.
That is the Merito model. Not one checkbox. Not one dashboard. Not one “we ran the scan” status update.
The Merito point of view
Merito looks at AppSec the same way we look at QA, automation, SAP testing, and delivery pipelines. The tool matters, but the operating model matters more.
A tool can find a defect. It cannot decide your risk tolerance. It cannot fix weak release discipline. It cannot force teams to validate remediation. It cannot magically connect security findings to business impact, ownership, and deployment decisions.
For Merito customers, this is where we help connect the layers. SCA, SAST, DAST, ASPM, workflow, triage, release gates, and executive reporting all need to work as one program. Otherwise, you don’t have AppSec maturity. You have tool inventory and tool inventory is not security. It is a spreadsheet with licensing costs.
Stop trusting the checkbox
The checkbox is useful as a signal. Nothing more.
The real questions are harder:
- Did the scanner reach the right code, workflow, API, or runtime path?
- Did it understand the business context?
- Were the findings revalidated?
- Were false positives removed?
- Were true positives prioritized?
- Did the issue block release when it should have?
- Did the team prove the fix worked?
- Can leadership see risk across the application portfolio?
That is the AppSec conversation worth having with deepsec being a good reminder that better investigation is coming. But the companies that benefit will be the ones that already understand the bigger point. Security is not the checkbox…security is the layered validation model behind it.
