Top 10 AppSec Programme Mistakes: What Goes Wrong and How to Fix It

Most application security programmes do not fail for lack of tools; they fail because the tools are bought before anyone knows which applications matter, who owns the findings and what "fixed" means. The result is familiar: thousands of open scanner findings, developers who mute the noise, APIs that no scanner understands, pipeline secrets nobody inventoried and a security team that reports activity instead of risk reduction. This guide sets out the ten programme-level mistakes we see most often, why each one happens, what to do instead and how to tell when it is fixed, using OWASP SAMM, the NIST Secure Software Development Framework (SP 800-218) and CISA's Secure by Design principles as the reference points. It is for AppSec leads, CISOs and engineering managers who run or are rebuilding a programme, and it assumes the foundations described in the Application Security Guide.

Key takeaways

• Start with inventory and ownership. A programme that cannot list its applications, APIs, owners and data sensitivity cannot prioritise anything else.
• Measure outcomes, not output. Finding counts and scan coverage say little; time to remediate what matters, escape rates and repeat defect classes say a lot.
• Fix classes, not instances. Secure defaults, paved-road libraries and framework guardrails remove whole vulnerability classes that scanners would otherwise find forever, which is the core of CISA's Secure by Design message.
• Authorisation, APIs and secrets need their own attention. Scanners are weakest on business logic and object-level access, and pipeline credentials are an attack path, not an operations detail.
• Plan for the vulnerabilities you will miss. A disclosure route, an internal response process and root-cause analysis are SSDF requirements, not extras.

The Top 10 at a glance

1. Buying tools before knowing the application estate

What it looks like: a SAST and SCA platform is licensed and connected to whichever repositories were easy to reach. Nobody can say which of the scanned repositories run in production, which handle payment or personal data, or who owns them, so findings land in a shared queue.

Why it hurts: priority depends on what an application does and what it exposes. Without an inventory the programme spends equal effort on a retired prototype and on the customer-facing API, and the highest-risk systems, often legacy or acquired applications outside the main source platform, are the ones missing.

What to do instead:

• Build an application and API inventory with owner, business criticality, internet exposure, data classification and deployment location; NIST CSF 2.0 ID.AM-02 and NIST SP 800-53 CM-8 expect it.
• Tier applications (for example three tiers) and set testing depth and remediation SLAs per tier.
• Link repositories, pipelines and running services so a finding can be routed to a team automatically.

Fixed when: over 95% of production services map to an owner and a tier, and new services cannot deploy without an inventory record.

2. Measuring activity instead of risk reduction

What it looks like: monthly reports show scans run, findings opened and training completions. Leadership cannot tell whether risk went up or down.

What to do instead: report a small set of outcome metrics by application tier.

SAMM's Strategy and Metrics practice exists for this purpose: assess maturity, set targets and measure progress against them. See the AppSec Programme Metrics Guide and the OWASP SAMM Guide.

Fixed when: every metric reported has a target and an owner, and at least one decision per quarter is made because of a metric.

3. Scanning everything, triaging nothing

What it looks like: default rule packs run on every repository, every finding becomes a ticket, and developers learn that most tickets are false positives or irrelevant. Gates are switched off after the first release they block.

What to do instead:

1. Tune before you gate: run new rules in report-only mode, measure the false positive rate per rule and disable or rewrite rules that exceed an agreed threshold.
2. Gate on a narrow set: block merges only for high-confidence, high-impact rules (hardcoded secrets, known injection patterns, critical exploitable dependencies), and track the rest in the backlog.
3. Prioritise with context: combine severity with exposure, data sensitivity and known exploitation; SSDF RV.2 asks organisations to assess, prioritise and remediate vulnerabilities based on risk.
4. Route to owners: deliver findings in the developer's pull request or issue tracker, not a separate security portal.
5. Allow documented exceptions with an expiry date and an approver.

See the SAST Triage Guide.

Fixed when: gate overrides are rare and reviewed, and developer-reported false positive rates for gating rules stay below the agreed threshold.

4. Skipping design and requirements

What it looks like: security first sees a feature when a scanner or penetration test runs, after the architecture is fixed. Design flaws such as missing tenant isolation or trust in client-supplied identifiers are then expensive or impossible to fix.

What to do instead: SAMM's Design function (Threat Assessment, Security Requirements, Secure Architecture) and SSDF PW.1, designing software to meet security requirements and mitigate risks, both put this work before code. Practically:

• Define triggers for a threat model: new internet-facing service, new data class, new authentication or authorisation flow, new third-party integration, or an AI agent with tool access.
• Use a lightweight, time-boxed format so teams actually do it, and record the resulting requirements as tickets with acceptance criteria.
• Maintain reusable requirement sets per application type, for example from OWASP ASVS levels.

See the Threat Modelling Guide.

Fixed when: tier 1 designs carry a threat model before build, and pentest findings classed as design flaws fall release on release.

5. Assuming scanners cover authorisation and APIs

What it looks like: the programme reports full DAST coverage of the web front end, while dozens of APIs, some undocumented, sit behind it untested. Static and dynamic tools rarely know which user should be allowed to read which object, so broken object-level authorisation passes every automated check.

Why it hurts: the McKinsey Lilli AI platform disclosure in 2026 involved public API documentation listing more than 200 endpoints, 22 of which required no authentication, plus SQL injection and an object-reference flaw: basic API controls on a platform that was otherwise well funded.

What to do instead:

• Inventory APIs from gateway logs, specifications and traffic, not only from documentation.
• Require authentication by default at the gateway and in the framework, with explicit, reviewed exceptions.
• Write authorisation tests per role and per tenant as part of the test suite, and include business logic in penetration test scope.

See the API Security Guide and the OWASP API Top 10 API1 Broken Object Level Authorization Guide.

Fixed when: every API in the inventory has an owner, an authentication requirement and authorisation tests, and unauthenticated endpoints are a reviewed list.

6. Leaving secrets and pipeline identities out of scope

What it looks like: the AppSec programme covers code defects, while API keys in repositories, CI variables, deploy keys and cloud credentials used by pipelines belong to nobody. Pipelines run with broad, long-lived credentials and third-party scripts are executed without verification.

Why it hurts: in the Codecov breach of 2021, a modified uploader script that many CI pipelines downloaded and ran sent each job's environment variables to an attacker, exposing the tokens and keys held there across many customers.

What to do instead:

• Scan repositories, history, images and build logs for secrets, with pre-commit or push protection on new commits. See the Git Secret Scanning Guide.
• Replace stored cloud keys in pipelines with short-lived federated credentials, and scope each job to the secrets it needs.
• Pin and verify third-party actions and scripts; SSDF PO.5 calls for secure development environments and PS.1 for protecting all forms of code from unauthorised access and tampering.
• Inventory pipeline identities with owners and rotation dates. See the Secrets Management Guide.

Fixed when: new secrets in code are blocked before merge, and no production pipeline uses a long-lived cloud access key.

7. Running SCA without ownership or context

What it looks like: the software composition analysis dashboard shows tens of thousands of vulnerable dependency findings. Nobody can say which are reachable, which applications are exposed, or who should upgrade a shared base image.

What to do instead:

• Generate an SBOM per build and store it with the release, so exposure to a newly disclosed vulnerability can be answered in minutes. See the SBOM Guide.
• Prioritise dependency findings with exploitability and reachability context, and treat vulnerabilities on CISA's Known Exploited Vulnerabilities catalogue as urgent.
• Automate routine updates with merge-ready pull requests and assign owners to shared images and internal libraries. See the Dependency Update Automation Guide.
• Control what enters the build: SSDF PW.4 encourages reusing existing well-secured software, and package source policies reduce exposure to malicious packages. See the Malicious Package and Dependency Confusion Guide.

Fixed when: exposure to a new critical dependency vulnerability can be determined across the estate within one working day.

8. Security as a late gate instead of a paved road

What it looks like: each team chooses its own authentication library, query building approach and logging format, and security tries to catch the resulting mistakes at release. The same vulnerability classes recur in every new service.

What to do instead: CISA's Secure by Design work argues that products should be secure by design and secure by default, with protections such as multi-factor authentication and intrusion logging built in rather than configured later. Inside an organisation, that means:

• Service templates that include authentication, authorisation middleware, parameterised data access, secure headers, logging and secret retrieval by default.
• Approved, maintained libraries for risky functions (cryptography, file upload, HTML sanitisation, outbound HTTP) and lint rules that flag alternatives.
• Framework settings that make the safe path the default, matching SSDF PW.9, configuring software to have secure settings by default.
• Guardrails for AI coding assistants and agents, so generated code passes the same checks. See the AI Coding Agents Security Guide.

Fixed when: the share of services built from the paved road rises each quarter and repeat defect classes fall in those services.

9. Champions and training without time or purpose

What it looks like: an annual video course for all developers and a champions list that nobody has time to act on. Training content does not reflect the defects the organisation actually produces.

What to do instead:

• Base role-based training on your own top defect classes and stack, refreshed from metrics (mistake 2). SAMM's Education and Guidance practice and NIST SP 800-53 AT-3 cover role-based training.
• Give champions protected time, a clear remit (threat models, triage, rule tuning) and a direct line to the AppSec team; SSDF PO.2 asks organisations to implement roles and responsibilities and provide role-based training.
• Measure champions by outcomes in their teams, not by meetings attended.

See the Security Champions Programme Guide and the Developer Security Training Programme Guide.

Fixed when: every tier 1 team has an active champion and repeat defect classes in trained teams decline.

10. No plan for vulnerabilities that escape

What it looks like: a researcher cannot find where to report a flaw, an internal report sits in a shared inbox, and once a bug is fixed nobody checks whether the same pattern exists elsewhere.

What to do instead: the SSDF's Respond to Vulnerabilities group asks organisations to identify and confirm vulnerabilities on an ongoing basis (RV.1), assess and remediate them (RV.2) and analyse them to identify root causes (RV.3).

• Publish a vulnerability disclosure policy and a security.txt contact, and consider a bug bounty for mature, internet-facing applications. See the Bug Bounty and Vulnerability Disclosure Guide.
• Define an application vulnerability response process with severity criteria, a fix SLA, customer communication and links to incident response.
• After every significant finding, run variant analysis across the codebase and add a rule, test or guardrail so the class cannot return.

Fixed when: every critical escaped vulnerability produces a root-cause record and a preventive control within an agreed time.

Common failure patterns

• Programme by procurement: the roadmap is the tool renewal schedule rather than a SAMM target profile.
• Gates switched off quietly: a blocking rule frustrates a release and is disabled, with no record or replacement.
• Pentest as the programme: an annual penetration test is the only security activity for most applications.
• Exceptions without expiry: risk acceptances granted once and never revisited.
• Shadow applications: acquired, low-code and internal AI applications sit outside the inventory and every control. See the Citizen Developer and Internal AI App Governance Guide.

Framework mapping

Mistakes 6 and 7 are where attackers most often enter through the development process itself: ATT&CK T1195.002 Compromise Software Supply Chain and T1552.001 Credentials In Files.

Where to start

1. Weeks 1 to 4: build the inventory and tiering (mistake 1) and baseline a SAMM assessment for the top tier. See the AppSec Maturity Model.
2. Weeks 5 to 8: turn on secret scanning with push protection and remove long-lived pipeline cloud keys (mistake 6); these give quick, measurable risk reduction.
3. Weeks 9 to 12: tune scanners in report-only mode, agree SLAs per tier and gate on a short list of rules (mistake 3); publish the outcome metrics (mistake 2).
4. Next two quarters: API inventory and authorisation tests for tier 1 (mistake 5), threat model triggers (mistake 4), SBOMs and dependency automation (mistake 7).
5. Ongoing: grow the paved road (mistake 8), the champions network (mistake 9) and the response loop (mistake 10), and reassess SAMM annually.

Small organisations can combine roles and rely on platform-native scanning and a single paved-road template; large organisations need federated ownership, a shared inventory service and tier-based policy enforced in the pipeline platform.

Practitioner checklist

• An application and API inventory exists with owner, tier, exposure and data class for every production service.
• Reported metrics are outcome-based, have targets and drive decisions.
• Gating rules are tuned, few and high-confidence; exceptions expire.
• Threat modelling is triggered by defined design changes for tier 1 systems.
• Every API has authentication by default and authorisation tests by role and tenant.
• Secret scanning blocks new secrets, and pipelines use short-lived, scoped credentials.
• SBOMs are generated per build and dependency updates are automated with owners.
• New services start from a secure-by-default template with approved libraries.
• Champions have protected time and training reflects real defect data.
• A disclosure policy, response process and root-cause analysis exist for escaped vulnerabilities.

Standards and references

• OWASP: Software Assurance Maturity Model (SAMM) v2
• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• CISA: Secure by Design
• OWASP: Application Security Verification Standard 5.0
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Application Security Guide · OWASP SAMM Guide · AppSec Programme Metrics Guide · Security Champions Programme Guide