There is a version of this post that opens with a statistic. Something alarming about the average cost of a data breach, or the percentage of organizations that report their AppSec program as "mature" while simultaneously suffering preventable vulnerabilities in production. That version exists everywhere. You have read it. It did not change your program.
This version starts differently.
Imagine you have just hired a strong AppSec engineer. They are experienced, technically sharp, and genuinely motivated. Within their first six months, they stand up a SAST pipeline, instrument your repositories, generate findings, and open hundreds of tickets across dozens of teams. They present metrics. The data is real. The risk is real.
And nothing moves.
Not because engineering is lazy. Not because product does not care about security. Not because leadership lacks intent. Nothing moves because the AppSec engineer, however talented, entered the organization as a stranger, handed people more work, and expected adoption through authority rather than trust. The tooling worked perfectly. The program failed anyway.
This is not a hypothetical. It is a pattern. It is one I have lived, rebuilt from, and now help organizations avoid. And the reason it keeps happening is that the industry keeps selling the wrong solution to the wrong problem.
Walk any security conference floor. Count the vendors. Each one has a platform, a dashboard, a "unified" something. Each one promises that if you deploy their product, you will have visibility, coverage, and measurably improved posture. The pitch is not wrong, exactly; the tools often do what they say they do. The gap is in the assumption underneath the pitch: that tooling is the bottleneck.
It is not.
The bottleneck in almost every struggling AppSec program is not the absence of a scanner, a DAST platform, or a consolidated findings dashboard. It is the absence of the cross-functional trust required to turn findings into action. Tools produce output. Output becomes risk reduction only when people act on it. And people act on it only when they believe the source of that output is working with them, not at them.
This distinction -- working with versus at -- is where AppSec programs live and die. It is also where leaders have more leverage than they realize, for better or worse.
Trust in the context of an AppSec program is not a soft, cultural abstraction. It is a functional prerequisite that operates in three distinct directions, and a deficit in any one of them will stall your program regardless of your tooling investment.
Specifically, they need to believe that the AppSec function is not going to introduce friction into their workflows, flood their backlog with unranked noise, or treat every finding as equally urgent and equally their problem to solve immediately. Engineering teams are already operating under mounting pressure to ship faster, break less, and do more with the same headcount. An AppSec program that shows up as an additional tax on their time -- especially one imposed without conversation -- will be quietly deprioritized. Not out of malice. Out of survival.
The failure mode here is specific and recognizable: you automate a rollout, findings appear in repos, tickets are opened at scale, SLAs are enforced before any collaborative norm has been established. Engineering experiences this not as security being thorough but as security being an occupying force. The result is silence, then deferment, then isolation; a predictable collapse sequence that has nothing to do with the quality of the underlying findings.
This is the half of the equation that rarely gets discussed, because the narrative tends to position security as the frustrated expert being ignored by ungrateful stakeholders. But the dependency runs both ways. The majority of AppSec OKRs and KPIs are not within AppSec's power to deliver in isolation. Vulnerability remediation requires engineering cycles. Secure coding adoption requires engineering managers to prioritize training. SDLC integration requires engineering buy-in at the process level. If Security cannot trust Engineering leadership to follow through on commitments, they are not building a program — they are building a list of things they asked for that never happened.
This is perhaps the most structurally underestimated dimension of the problem. There is a persistent organizational fantasy that because an AppSec engineer can write code, they can build everything in-house (scanners, integrations, custom tooling, automation) in addition to running the actual program. This is not a creative use of technical talent. It is a way to ensure your AppSec function is perpetually behind, perpetually stretched, and perpetually unable to point to outcomes because they spent their capacity building infrastructure instead of delivering security. A purpose-built piece of software from a vendor comes with contractual SLOs, SLAs, support, and a roadmap. Expecting one engineer to replicate that while also doing the job is not a budget decision. It is a liability.
Here is what makes the trust problem particularly tricky for CISOs, CTOs, and VPs: it is largely invisible until it collapses.
Organizations where AppSec is working well tend to have leaders who model cross-functional behavior explicitly. The CISO is in the room with the CTO, not just sending reports to them. The VP of Engineering and the AppSec lead have a standing relationship, not just an escalation path. Security is introduced to product and engineering as a collaborative function at the start of initiatives, not as a review gate at the end.
When that does not exist, what fills the vacuum is silos. And siloed AppSec is performative AppSec. It generates documentation, dashboards, and coverage statistics that look like a program while the actual risk surface remains largely unaddressed because no one has the relationships required to move work across team boundaries.
Leaders often underestimate how directly their own behavior sets the template for this. If you as a CTO have a pattern of treating security conversations as compliance overhead, your engineering managers will treat AppSec requests as overhead too. If you as a CISO have a pattern of escalating findings to leadership without first building the engineering relationship to contextualize them, you will be seen as an adversary rather than an ally — and you will have earned that perception, regardless of how technically correct you are.
The cultural conditions that allow AppSec to function are not something a tool can install. They require deliberate cultivation from the top down. This is not a platitude, it is an operational reality with measurable downstream effects on your program outcomes.
One of the most seductive traps in AppSec program design is optimizing for coverage when you should be optimizing for adoption.
Coverage means you have instrumented everything. Your SAST runs on every repo. Your DAST hits every application. Your SCA is scanning every dependency. You have a dashboard that is almost entirely red, and a backlog that is growing faster than anyone is resolving it. Your metrics show thorough scanning. Your risk posture has not changed.
Adoption means that when a finding surfaces, someone owns it, understands it, and has both the context and the capacity to address it within a reasonable timeframe. Adoption means that engineering teams have internalized secure patterns not because they were commanded to but because the AppSec function has made it easy to do the right thing and has been a reliable, low-friction resource when they have questions. Adoption means the program has roots in the organization, not just a presence.
The distinction matters because coverage is cheap to demonstrate and hard to turn into outcomes. A single well-adopted security control that engineers understand, trust, and actively engage with will reduce more real-world risk than a thousand findings sitting in a ticket queue that no one is prioritizing.
This also has direct implications for tooling decisions. The right question when evaluating an AppSec tool is not "what can it find?" It is "will our engineering teams actually engage with what it finds, and do we have the organizational conditions to make that happen?" If the answer to the second question is uncertain, the answer to the first is irrelevant.
If you are a CISO, CTO, or VP reading this and recognizing your organization in any of the above, here is what recovery actually looks like in practice, not as theory, but as a sequenced set of decisions.
The instinct when building or rebuilding an AppSec program is to establish comprehensive coverage immediately. Resist it. Breadth deployed without trust creates noise. Noise creates fatigue. Fatigue creates the silent opposition that looks like non-engagement but is actually active avoidance. Pick one category of risk that genuinely matters to engineering leadership; something they have already expressed concern about, or something tied to a product initiative already in flight, and solve that specific problem well. Demonstrable, targeted impact on something that matters to your stakeholders builds more durable credibility than a comprehensive scan that floods their inbox.
AppSec engineers should be embedded in engineering conversations before they are deploying anything. Sit in sprint planning. Understand the roadmap. Learn what engineering is actually being asked to deliver and under what constraints. When security is familiar with the delivery context, it can design interventions that work within the existing flow rather than introducing new external demands. The sequence matters: relationship, then process, then tooling. Not the reverse.
One of the clearest markers of a program in collapse is the confusion over who is responsible for remediation. Security identified it; does that mean security owns it? Engineering has to fix it; does that mean engineering owns it entirely? The ambiguity is where accountability goes to die. The rebuild requires having direct, explicit conversations with engineering leadership about what shared ownership looks like, what security commits to providing (context, severity triage, remediation guidance, validation), and what engineering commits to providing (prioritization, cycles, timelines). Written down. Agreed to. Revisited quarterly.
The decision to build versus buy custom security tooling is almost always a false economy when made under resource constraints. Custom tooling requires maintenance, documentation, onboarding, and ongoing iteration. Purpose-built vendor solutions exist because the problem is common enough to warrant a product, and they come with support structures that a single engineer cannot replicate. More importantly: introduce tooling only after the organizational conditions exist to support adoption. A SAST tool introduced to a team that has no security context will generate findings no one prioritizes. The same tool introduced after six months of relationship-building, shared context, and a demonstrated track record of useful, actionable security guidance will get used. The tool did not change. The conditions around it did.
The best AppSec program is one that engineers do not notice because it is already built into the way they work. Pre-commit hooks, IDE integrations, secure-by-default libraries, automated PR comments that flag specific patterns with remediation links; these move security left in a way that does not feel like security imposing on engineering. It feels like good tooling. Build toward that experience. Every piece of security work that can be automated and embedded in the developer workflow is one less ticket in a backlog and one fewer reason for an engineer to view security as friction.
If you are reporting on scan coverage and ticket volume in your quarterly reviews, you are not giving leadership what they need to make good decisions. What matters to a CTO or CEO is not how many findings you generated -- it is what the program is doing to reduce the probability and blast radius of a security event, and what resources it needs to do that more effectively. Report on adoption rates, time-to-remediation trends, risk categories that are moving, and the specific dependencies on engineering cycles that are determining your pace. This is how you make the case for adequate resourcing, and it is how you move from being a cost center to being a function that leadership understands and invests in.
There is a conversation happening in security teams right now that is not making it to leadership in a useful form.
The expectation that one AppSec engineer can build a program, maintain tooling, remediate findings, train developers, manage vendor relationships, and report to the board is not a challenge. It is a structural failure that will produce one of two outcomes: burnout, or the appearance of a program that does not actually reduce risk. Neither is acceptable.
Staffing it as though one person can hold all of those dependencies simultaneously is how organizations end up in breach post-mortems wondering why the security team did not catch something only to find that the security team did catch it, raised it, and had no path to get it fixed.
Adequate resourcing means appropriate headcount relative to engineering size. It means budget for purpose-built tooling rather than expecting custom builds. It means executive air cover for the cross-functional asks that AppSec cannot fulfill through individual relationships alone. And it means consistent audience: regular engagement from leadership that signals to the rest of the organization that security is not an afterthought.
Praise without support is not a retention strategy. It is a resignation letter written slowly over time.
If your organization is considering an AppSec tooling investment -- a new SAST platform, a DAST solution, an ASPM consolidation play -- there is a question worth asking before the procurement process begins:
Do we have the cross-functional trust required to turn what this tool finds into action?
If the answer is yes, if AppSec and engineering have a working relationship, if leadership is actively supporting the function, if there is a clear ownership model for remediation, then the tool is likely a good investment and will compound the value of the organizational conditions you have already built.
If the answer is no, or uncertain, if engineering views security as an external imposition, if AppSec is operating without executive support, if the last tooling rollout generated findings that are still sitting unaddressed, then the tool will inherit those conditions and perform accordingly. It will add to the noise, not reduce the risk.
No tool fixes an organizational problem. But organizations that fix the organizational problem first find that their tools suddenly work.
Nullra was built specifically for organizations that have recognized this gap; that the program they have, or the program they are about to build, needs a foundation before it needs a stack.
Our work starts where most vendors stop: with the honest assessment of organizational readiness. What is the current state of the Security-Engineering relationship? Where does leadership need to be more engaged? What does the existing SDLC actually look like, and where are the realistic integration points? What would a sustainable, adoption-oriented AppSec program look like given the specific constraints of this organization?
From there, we help design and stand up programs that are built for the conditions that actually exist -- not the ideal conditions that a vendor demo assumes. That means sequenced tooling introductions, explicit ownership frameworks, embedded engineering relationships, and reporting structures that give leadership real signal rather than coverage theater.
If any of what you have read here resonates with where your organization is, we would like to talk. Not to pitch a platform. To understand the actual problem and figure out whether we are the right help for it.
That conversation starts at https://nullra.com/#contact.