Deadlines vs. secure code: How AppSec can cope

Two recent reports on application security (AppSec) have unearthed disturbing findings. A Cypress Data Defense survey found that 62% of organizations knowingly release insecure code to meet delivery deadlines. And a Checkmarx survey with a broader sample (1,500 respondents versus 250) reported that 81% of organizations knowingly ship vulnerable code.

Organizations often decide that any vulnerabilities in the code are within an acceptable risk level for release, explained Steve Kosten, Cypress Data Defense’s co-founder and director of AppSec. Business pressure and the expectation of a quick remediation release can drive that decision, Kosten said. 

Teams may also believe — correctly or incorrectly — that the vulnerability does not present meaningful exploitation risk.

Steve Kosten 

Eran Kinsbruner, vice president of portfolio marketing at Checkmarx, cautioned that the velocity of AI coding means security haas to change — and can no longer be a bolt-on practice. 

It has to be embedded from code to cloud. Our research shows that developers are already letting AI write much of their code, yet most organizations lack governance around these tools.

Eran Kinsbruner

Here’s why so much code ships with vulnerabilities — and key recommendations for what AppSec teams can do about third-party software risk management (TPSRM).

See Video: Addressing Third-Party Software Risk

It’s not negligence — it’s just a reality

Deadlines and feature delivery commitments often force engineering leaders to make risk-based decisions without fully engaging the security team, said Randolph Barr, CISO of Cequence Security. 

It’s not always negligence. Sometimes it’s the absence of a well-embedded remediation process that would allow issues to be addressed earlier in the lifecycle.

Randolph Barr

Another factor is fragmented security investment, Barr said. Organizations deploy application security testing, threat hunting, and endpoint scanning tools in silos, but they don’t consolidate findings into a clear risk picture for development teams. “That leads to alert fatigue, contested findings, and ultimately delays in remediation,” he said. “The end result is code being shipped with known vulnerabilities because the context for prioritization isn’t aligned across teams.”

Leadership may consciously decide to accept the risk, hoping that compensating controls like traditional AppSec will hold the line, said Diana Kelley, CISO of Noma Security. 

It’s usually the math of business pressure versus security debt.

Diana Kelley

Iftach Ian Amit, founder and CEO of Gomboc.AI, said many organizations lack the ability to distinguish between a vulnerability that’s theoretical and one that’s exploitable in their specific environment. 

Combine that with tool fatigue — where engineers are flooded with alerts they can’t take action on — and it’s not surprising that insecure code still gets shipped.

Iftach Ian Amit

Here are four key recommendations for how AppSec teams can manage risk from software released before proper vetting.

1. Implement contractual safeguards with third parties.

“Organizations can define a number of safeguards during the contract negotiation process to protect themselves from knowingly shipped vulnerable code,” said Charlie Jones, director of product management at ReversingLabs (RL). For example, they can stipulate reporting and remediation time frames for known security risks.

They can also stipulate their right to independently test the software for vulnerabilities before procurement or deployment and specify the obligations of the third party to comply with applicable laws and regulations associated with their business, Jones said. Those laws and regulations may require the enterprise to not onboard or deploy software containing known vulnerabilities.

In addition, organizations can define terms to address the third party’s responsibility for appropriate corrective controls to support operational resilience in the event of a security breach of software they knowingly ship with security weaknesses.

Ensar Seker, CISO of SOCRadar, recommends requiring software providers to adhere to standards such as the OWASP Application Security Verification Standard or MITRE’s CWE/SANS Top 25. 

A ‘secure development warranty’ clause, similar to a defect warranty, is also increasingly being adopted.

Ensar Seker 

Contractual safeguards should not be only external, said Cequence’s Barr. He explained that organizations need an internal mechanism such as a RACI (responsible, accountable, consulted, informed) framework that clearly defines who owns secure development, who governs oversight, and critically, who has the authority to make risk-acceptance decisions on behalf of the company.

Without that clarity, decisions are often made ad hoc by engineering leads under deadline pressure, leaving security leaders accountable without having been part of the process. A documented RACI ensures shared responsibility, transparency, and traceability when vulnerabilities are knowingly shipped.

Randolph Barr

2. Use continuous monitoring and validation.

“Continuous monitoring practices allow organizations to identify vulnerabilities early in the software development lifecycle and remediate them quickly, lowering the risk of knowingly shipping vulnerable code,” said Aaron Cure, Cypress Data Defense’s co-founder and director of cybersecurity.

Continuous monitoring is critical because code is never really done. “Infrastructure evolves, dependencies shift, and drift happens,” observed Gomboc.AI’s Amit. “Continuous monitoring gives organizations real-time feedback when vulnerable code surfaces in production. Pairing that with automated validation and deterministic remediation reduces the window of exposure dramatically, transforming security from a reactive gate to a built-in guardrail.”

RL’s Jones said continuous monitoring of third parties can take many forms, depending on the nature of the product or service provided by the vendor. “For software vendors, each major version change introduces a new asset for downstream enterprise buyers, potentially adding new components and dependencies that alter the software's risk profile,” he said.

In an effort to stop new risks introduced by a new version of software from materializing and preserve effective change management controls, organizations must reevaluate the updated software prior to deployment.

Charlie Jones

The key to continuous monitoring is real-time visibility, said SOCRadar’s Seker.

3. Use risk scoring and tiering to assess vulnerabilities.

Guy Pearce, an IT and data consultant and member of the Emerging Trends Working Group of ISACA, said that scoring risks by vulnerability category and then communicating the scores to potential clients would at least let clients know the risks of acquiring the software, enabling them to make informed decisions about it. 

Applying good risk management methodology, such as ISO31000 or COSO II, would mean assessing the likelihood of any vulnerability harming a client and estimating the impact, which would provide a risk score for each vulnerability, Pearce said.

The risk score would enable a ranking of the severity of each vulnerability. The client, if they really wanted such software, could then determine the nature of mitigating actions that could mitigate the risk of each rated vulnerability.

Guy Pearce

Checkmarx’s Kinsbruner said that risk scoring and the classification of security vulnerabilities based on predefined criteria are a proven and effective strategy for prioritization and risk mitigation. “By flagging vulnerabilities that are internet-facing or impact sensitive services, organizations can ensure developers focus on the most critical issues, while de-emphasizing those that are less exploitable or internal only,” Kinsbruner said.

To remain effective, this risk scoring must be continuously monitored and refined as business objectives and application code evolve.

Eran Kinsbruner

Tools such as CVSS, EPSS, and now SSVC (Stakeholder-Specific Vulnerability Categorization) help teams assign meaningful risk scores based on exploitability, business context, and exposure, said SOCRadar’s Seker. “This allows rational decisions around what can ship and what can’t, even when vulnerabilities are present.”

However, Gomboc.AI’s Amit argued that risk scoring is problematic because it doesn’t take into account the specific landscape in which software is being used. “The risk score of the same vulnerability may differ widely based on how and where software is deployed.”

Risk scoring systems, such as CVSS, have the ability to apply such biases to the final score, but these aren’t widely adopted because of the additional work that needs to be done by security teams to do it.

Iftach Ian Amit

4. Transparency, due diligence, and independent testing are essential.

One key to transparency is the software bill of materials. Employing proper SBOM methodologies, which allow third-party risk management teams to have full transparency into the software components being procured as well as their individual security status, is one of the key approaches, Amit said.

He said that using AI tools that are designed for code review and deterministic security research can deliver immediate visibility into vulnerable elements in procured software.

Organizations also need to perform due diligence, ISACA’s Pearce said, asking questions about what known vulnerabilities are being shipped with code and what known vulnerabilities have been identified and eliminated. “Another aspect of due diligence would be checking the vendor contract for sections that may seek to cover vulnerable code shipments,” he said.

RL’s Jones recommended that third-party risk management teams have the tools to perform independent testing of software throughout its lifecycle of use. This will ensure that they can identify risks to third-party software, so that they then can work with the vendor to fix vulnerabilities before downstream exploitation can impact their business.

“Organizations should ensure that code scanning and reporting are conducted by a trusted third party or by a group that does not report to the same executive leadership as the team whose code is being evaluated,” said Cypress Data’s Kosten. 

It may also be acceptable to ship vulnerable code if the assessed risk level is small compared to the business impact of delaying deployment. Clear guidelines on risk management and acceptance, along with defined ownership and transparent reporting, are essential.

Steve Kosten

Shift right on your application security 

Third-party risk teams can no longer rely on once-a-year assessments, warned SOCRadar’s Seker. “Instead, they must integrate SBOM analysis, live threat feeds, and behavioral indicators into continuous vendor monitoring,” he said.

If a partner repeatedly ships software with critical known CVEs, that should trigger tier upgrades, enhanced scrutiny, or even pause procurement. Risk management must become dynamic, not static.

Ensar Seker

Machine learning’s large language models (LLMs) are a boon for making sure that code has as few vulnerabilities as possible, subject to the constraints of the training data, said ISACA’'s Pearce. “Not only is the opportunity better than ever; the speed with which these checks and balances could be performed is also better than ever,” he said.

This means that code should theoretically be as good as or better than ever, Pearce said, and able to be generated at an unprecedented pace. 

It’s as if the whole rapid development-security curve has moved to the right, meaning that code should be developed faster and with fewer vulnerabilities given AI’s capabilities. The reputational risks of shipping bad code can be terminal for the vendor. They should use the tools available today to minimize the presence of vulnerabilities.

Guy Pearce

Learn more about TPSRM. Discover how RL can help you assess and manage third-party risk.