Your Secure SDLC Is Not a Security Scanner

Imagine a SaaS company with a fairly impressive security setup.

Every pull request runs static analysis. Dependencies are checked for known vulnerabilities. Containers are scanned before deployment. Developers complete annual security training, and the company commissions penetration tests.

The CI/CD pipeline has security gates. Vulnerabilities are tracked in Jira. Management receives regular security reports.

On paper, the company appears to be doing quite well.

Now imagine that the engineering team introduces a new API endpoint that allows customers to download invoices.

The endpoint requires authentication. The code follows the team’s coding standards. Every automated security check passes.

Unfortunately, the developer forgot to verify that the requested invoice belongs to the authenticated customer’s organization.

A user from Tenant A can potentially access an invoice belonging to Tenant B simply by changing an identifier in the API request.

The pipeline is green. The application is vulnerable.

This is a hypothetical scenario, but it illustrates an important distinction.

Having security controls in your development pipeline is not the same as having a Secure Software Development Lifecycle.

The first gives you technical checks. The second should give you a repeatable way to identify security risks, make appropriate decisions, implement controls, verify expectations, and learn from failures.

And that difference matters far more than the number of tools running in your CI/CD pipeline.

The uncomfortable reality of many AppSec programs

Application security programs often evolve through individual initiatives rather than through a deliberate engineering strategy.

A penetration test discovers vulnerabilities, so the company introduces SAST.

A critical dependency vulnerability creates an emergency, so Software Composition Analysis (SCA) is added to the pipeline.

A developer accidentally commits a credential, so secret scanning becomes mandatory.

An enterprise customer asks about secure development practices, so the company publishes a Secure Development Policy.

Each response makes sense in isolation.

The problem is that implementing individual controls doesn’t automatically create a functioning security program.

Over time, the organization accumulates tools, policies, reports, and processes. But the connections between them may remain weak.

Security requirements are not consistently defined before implementation. Threat modeling happens only when someone from Security has time. Developers receive vulnerability reports without enough context to understand the underlying risk.

Some teams follow strong security practices, while others rely on individual experience. Release exceptions are approved without clear accountability. The same categories of vulnerabilities appear repeatedly because the underlying design or development practices never change.

Management sees increased security activity, but it is difficult to demonstrate whether the organization is actually reducing meaningful risk.

This is where application security starts becoming expensive without necessarily becoming effective.

Not because the individual controls are wrong, but because the organization lacks a system connecting those controls to engineering decisions and business risk.

What a Secure SDLC actually means

A Secure Software Development Lifecycle (SSDLC) integrates security practices into the way an organization designs, builds, tests, releases, and operates software.

It is not a replacement for Agile, Scrum, Kanban, or DevOps.

It should work with the development methodology the organization already uses.

And it should not require a security specialist to approve every minor engineering decision.

A functioning SSDLC answers a set of practical questions:

Who determines the security requirements for a new feature? How do teams identify architectural risks before writing code? Which security controls should developers use by default? What evidence is required before a high-risk change reaches production? Who accepts residual security risk, and how does the organization learn from vulnerabilities and incidents?

These are engineering and organizational questions.

Tools can help answer parts of them, but tools cannot take ownership of the decisions.

This is also why established frameworks look beyond scanning.

OWASP Software Assurance Maturity Model (SAMM) organizes software security into five business functions: Governance, Design, Implementation, Verification, and Operations.

Across these functions, SAMM defines 15 security practices addressing topics such as security strategy, requirements, architecture, secure builds, deployment, verification, defect management, and incident management.

NIST’s Secure Software Development Framework (SSDF) approaches secure development through four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities.

The frameworks have different structures, but they reinforce the same basic principle.

Secure development requires a coordinated set of practices, not just security testing near the end of the process.

For engineering teams, I find it useful to think about SSDLC through seven connected areas:

Area	Fundamental question
Governance	Who owns security expectations, decisions, and improvements?
Requirements	What security properties must the software enforce?
Design	What can go wrong, and how should the architecture prevent it?
Build	How do developers implement security consistently?
Verification	How do we demonstrate that security requirements are met?
Release	What evidence and risk decisions are needed before deployment?
Operations	How do we detect failures, respond, and improve the software?

These seven areas are a practical way to describe the delivery lifecycle, not a replacement for SAMM’s five official business functions.

The value comes from connecting the activities.

A security requirement should influence architecture. Architecture should influence implementation. Implementation should be verified against the original requirement. Production findings should improve future requirements and controls.

If these connections are missing, security becomes a series of disconnected checkpoints.

Let’s examine a simple API feature

Consider our fictional multi-tenant SaaS application.

The engineering team is implementing an endpoint:

GET /api/invoices/{invoiceId}

The endpoint allows an authenticated user to retrieve an invoice.

A straightforward implementation retrieves an invoice using the supplied identifier and returns it to the caller.

Functionally, that might appear correct.

But authentication only tells us who is making the request. It does not establish whether that person is allowed to access the requested invoice.

This is the difference between authentication and authorization, and it becomes especially important in multi-tenant applications.

OWASP documents this risk as API1:2023 — Broken Object Level Authorization.

Now consider how an SSDLC should influence the feature.

First, establish the security requirement

Instead of a generic statement such as:

“The invoice API must be secure.”

The team defines an explicit authorization requirement:

“Only principals authorized to access an invoice may retrieve its content. Authorization must enforce the applicable tenant boundary, resource ownership, and user permissions.”

That requirement is actionable.

It identifies the security property that the application must enforce, rather than merely instructing developers to write secure code.

It also gives reviewers and testers something specific to verify.

Second, make an architectural decision

The team needs to decide where authorization is enforced.

Will each controller implement authorization independently? Will a shared authorization component evaluate resource access? Will the data-access layer constrain queries to the appropriate tenant? How will internal service identities or administrative access be handled?

These decisions have different implementation and maintenance implications.

A shared authorization mechanism may reduce inconsistency across services, but it also creates a security-critical dependency that requires careful design and testing.

Tenant-scoped queries can provide another layer of protection, but they must not become a substitute for evaluating user permissions where those permissions are required.

The important outcome is that authorization enforcement becomes an explicit architectural decision, rather than something individual developers are expected to remember.

Third, verify the intended behavior

A functional test might confirm that an authorized user can download an invoice.

That is necessary, but insufficient.

The team also needs negative authorization tests.

For example:

Test scenario	Expected security behavior
Authorized user accesses an allowed invoice	Invoice is returned
User from Tenant A requests an invoice from Tenant B	Access denied; no invoice data disclosed
User accesses an invoice within their tenant without sufficient permission	Access denied
User changes an invoice identifier to another valid identifier	Authorization remains enforced
Internal service requests an invoice outside its assigned scope	Access denied unless explicitly permitted

The exact HTTP responses depend on the application’s security contract. A 403 or 404 may be appropriate in different designs, provided the behavior does not reveal unauthorized information.

These tests should execute through the relevant application boundaries, not merely confirm that an authorization helper returns the expected Boolean value.

The team should also consider whether invoice metadata, error messages, logs, and related endpoints could expose information even when direct retrieval is denied.

This is where security requirements become meaningful verification.

OWASP ASVS can provide additional requirements for defining and evaluating authorization controls.

Finally, preserve the decision

The requirement belongs in the feature specification or acceptance criteria.

The architectural decision should be documented where engineers can find it. The negative tests belong in the automated test suite. Any unresolved risk needs an owner and a documented decision.

None of this requires a 40-page security design document.

For many teams, a short threat-modeling discussion, a documented authorization rule, and a small set of meaningful tests may be sufficient.

The important part is that the security decision survives beyond the conversation where it was originally made.

That is the difference between adding security checks and engineering security into the feature.

An SSDLC should reduce friction, not create another approval department

One reason Secure SDLC initiatives struggle is that they are introduced as additional procedures rather than improvements to existing engineering practices.

Every new feature requires a security questionnaire. Every architectural change waits for a security review. Every vulnerability finding becomes a release blocker.

Soon, security becomes a separate workflow competing with product development.

That is rarely sustainable, especially when a small AppSec team supports dozens of engineering teams.

A better approach is to make security activities proportional to risk.

A cosmetic UI change should not require the same level of review as a redesign of the authentication system.

A new integration processing sensitive customer information deserves more scrutiny than a minor update to a low-risk internal utility.

The organization needs a reliable mechanism for distinguishing between those situations.

For example, security review triggers might include changes to authentication or authorization, introduction of a new trust boundary, significant changes in data sensitivity, new internet-facing services, or security-critical infrastructure changes.

These triggers should integrate with existing planning and development workflows.

When additional scrutiny is necessary, the purpose should be clear: identify relevant risks and make actionable decisions.

When established controls are sufficient, the team should be able to proceed without unnecessary manual intervention.

This is how an SSDLC can improve security while supporting delivery speed.

It replaces inconsistent, last-minute security interventions with predictable engineering expectations.

What companies often discover when they examine their SSDLC

A security maturity assessment should do more than confirm that security tools exist.

It should examine whether practices are consistently implemented, appropriate for the organization’s risk, supported by evidence, and producing useful outcomes.

Several recurring categories of weakness deserve particular attention.

Security ownership is unclear. Security defines policies, engineering implements software, and product management decides delivery priorities. But nobody has clearly established who owns security acceptance criteria, risk exceptions, or remediation priorities.

Controls are inconsistent between teams. One engineering team has mature automated testing and secure deployment practices. Another uses different tools, review standards, and exception processes. Leadership assumes the same level of assurance applies everywhere.

Security is introduced too late. Architecture decisions have already been made when the security team becomes involved. Fixing the identified problem now requires changes across APIs, data models, infrastructure, or delivery timelines.

Vulnerabilities are managed without addressing their causes. Findings are assigned and closed, but recurring authorization failures, insecure configuration patterns, or dependency-management problems are not treated as engineering improvement opportunities.

Security metrics emphasize activity over effectiveness. Dashboards report findings, scan coverage, and completed training, but leadership cannot determine whether high-impact risks are being reduced.

Not every organization experiences all of these problems, and maturity varies considerably between teams.

But these are the types of issues a meaningful SSDLC assessment should investigate.

The assessment must also look for existing strengths. The purpose is not to create work where good engineering practices already exist.

It is to identify the smallest set of changes that will produce the most valuable improvement.

Start with your current engineering reality, not an idealized framework

An organization does not need to implement every SAMM practice at the maximum maturity level before it can improve software security.

OWASP SAMM explicitly supports defining target maturity levels appropriate to an organization’s needs.

That is important.

A small SaaS company with 15 engineers and a relatively simple architecture will have different resources and risks from a company operating hundreds of services across multiple business units.

Trying to impose the same operating model on both creates unnecessary complexity.

A practical improvement program starts by establishing a baseline.

Which applications and services are in scope? Which ones present the highest business impact? What security practices are already working? Where does the organization lack consistency or evidence? Which gaps have the greatest potential consequences?

An evidence-based review might examine architecture documentation, application inventories, pull-request protections, CI/CD configurations, security requirements, threat models, test results, vulnerability records, deployment controls, and operational procedures.

Interviews are useful, but statements such as “we perform threat modeling” or “all repositories run security scans” should be supported by representative evidence.

The organization can then compare its current capabilities with relevant SAMM practices and establish realistic target maturity.

That should produce a prioritized improvement roadmap, not simply a maturity score.

What should the first improvements look like?

Suppose a SaaS organization has effective code reviews and automated dependency scanning but no consistent application risk classification, inconsistent authorization testing, and unclear ownership of security exceptions.

Immediately buying an additional scanner may contribute little to solving those gaps.

A more valuable first improvement could be establishing a lightweight application risk-classification process.

That helps determine which applications and changes need additional security review.

The next improvement might standardize authorization requirements and introduce reusable tests for critical access-control scenarios.

At the same time, engineering and security leadership could define who may accept a release exception, what evidence is required, and when the exception expires.

Those improvements are relatively focused, but they connect governance, design, verification, and release management.

They also create a foundation for future automation.

A roadmap should consider dependencies between improvements. There is limited value in automating a release rule that nobody has agreed on or measuring a security requirement that has never been defined.

Standardize the security decision before trying to automate its enforcement.

Security ownership is a leadership decision

An SSDLC cannot succeed through security tooling alone because some of its most important dependencies are organizational.

Security teams can define standards, identify risks, support threat modeling, and help engineering teams implement appropriate controls.

But security teams rarely own product architecture, engineering capacity, or release schedules.

Engineering leadership must make secure development part of normal delivery expectations.

Product management needs to understand when security requirements affect feature scope and acceptance criteria.

Platform teams may need to provide secure defaults, reusable components, and reliable deployment mechanisms.

Application teams need to own the security behavior of the software they build.

And the appropriate business or technical risk owners must make informed decisions when residual risk cannot be eliminated immediately.

This doesn’t mean every team needs a dedicated security specialist.

It means security responsibilities need to be explicit, practical, and supported by leadership.

A Security Champions program can improve collaboration and distribute expertise, but it cannot compensate for a lack of accountability or engineering capacity.

Similarly, a written Secure Development Policy will accomplish very little if teams cannot translate it into concrete engineering expectations.

Policies describe the rules. Engineering practices make those rules operational.

The two must reinforce each other.

Stop measuring how much security work you perform

One of the easiest ways to create a misleading impression of security maturity is to rely on activity metrics.

Consider a dashboard showing that 98% of repositories run SAST.

That sounds impressive, but it leaves several important questions unanswered.

Are the scans configured correctly? Do they cover the relevant code? Are findings reviewed and remediated? Are the uncovered repositories business-critical? Does the tool detect the weakness classes that matter most for those applications?

Coverage is useful information, but it is not the same as effectiveness.

The same applies to counting vulnerabilities.

An increase in reported findings might indicate deteriorating security. It might also result from better detection, expanded application coverage, or new testing methods.

Useful metrics need context.

For a risk-driven SSDLC, some stronger measures include the proportion of high-risk changes receiving appropriate security review before implementation, the coverage of critical authorization scenarios by meaningful negative tests, the age and exposure of unresolved high-impact vulnerabilities, and the recurrence of defect categories that should have been addressed systematically.

Even these metrics should not be treated as universal KPIs.

A metric is valuable when it helps someone make a decision.

If a particular category of vulnerability repeatedly appears, the response might be improved developer guidance, a shared security component, additional automated tests, or an architectural change.

If reviews repeatedly happen after implementation, the organization may need to change how security review is triggered during planning.

The metric should point toward an improvement opportunity.

Otherwise, the organization may simply become more sophisticated at reporting security activity without improving security outcomes.

A simple self-check: Do you have an SSDLC or just security activities?

Before investing in additional security tooling or launching a large transformation initiative, engineering and security leaders can ask themselves six questions.

1. Do we know which applications and services create the greatest business risk? Can we explain why some systems require greater security assurance than others?

2. Are security requirements defined before implementation? For critical functionality such as authentication, authorization, and sensitive data handling, can developers and testers identify the expected security behavior?

3. Do we know which changes require additional security review? Are those decisions based on defined triggers, or on whether somebody remembers to involve the security team?

4. Can we demonstrate that our important security controls work? Beyond scan results, do we have meaningful tests and review evidence for critical security properties?

5. Are release risks accepted by the right people? When software is deployed with known security issues, is there documented ownership, justification, and a remediation plan?

6. Do vulnerabilities and incidents improve how we develop software? Or do we simply close tickets and wait for similar problems to appear again?

These questions are not a substitute for a formal OWASP SAMM assessment.

They are a useful starting point for leadership discussions.

If the answers vary considerably between teams, depend on individual knowledge, or cannot be supported with evidence, that indicates an area worth examining.

The next step is not necessarily a large security transformation.

It may be a focused assessment, a small number of engineering improvements, and a roadmap that addresses the most important risks first.

The objective is not to implement OWASP SAMM

Frameworks provide structure, common terminology, and a way to assess progress.

They are extremely useful when building an SSDLC because they reduce the need to invent an entire methodology from scratch.

But adopting a framework is not the business objective.

Reducing the likelihood and impact of security failures is the objective.

Improving engineering consistency is the objective.

Preventing avoidable vulnerabilities, making security expectations testable, and enabling teams to deliver software with predictable assurance are the objectives.

A SAMM maturity level is meaningful only in the context of the organization’s risks and the practices that support its software.

A company can improve its overall maturity score and still leave an unacceptable weakness in a business-critical authorization system.

Likewise, a company may have relatively modest maturity in some practices while effectively managing the risks relevant to its environment.

Security leadership must be able to distinguish between those situations.

That requires technical understanding, organizational context, and willingness to challenge activities that consume resources without providing sufficient value.

Secure development should become the normal way of working

The goal of a Secure Software Development Lifecycle is not to make developers think about every possible security vulnerability every time they write code.

It is to create an engineering environment in which important security requirements are known, secure implementations are easier to adopt, relevant risks receive appropriate scrutiny, and failures lead to improvements.

Scanners remain an essential part of that environment.

They provide scalable, repeatable checks that would be difficult or impractical to perform manually.

But they cannot replace security requirements, architectural decisions, ownership, or risk management.

A well-functioning SSDLC brings those elements together.

The real question for an engineering organization is not:

“How many security tools do we have in our pipeline?”

It is:

“Can we consistently explain what makes our software secure, demonstrate that its important security properties are enforced, and improve the process when something goes wrong?”

If the answer is unclear, adding another scanner is unlikely to solve the underlying problem.

The better starting point is to understand the current development process, identify the most important security risks, and establish the practices that will actually reduce them.

That is where a practical SSDLC begins.

---

Building or improving your Secure SDLC?

A security program is only as effective as the engineering practices behind it.

TheOnlySecurity’s SSDLC assessment and consulting services focus on evaluating existing security practices, identifying meaningful gaps, establishing risk-driven maturity targets, and helping engineering teams implement sustainable improvements.

The goal is not another generic checklist or a collection of new security tools. It is a practical security improvement roadmap that fits your architecture, development processes, and business priorities.

Explore SSDLC Assessment & Consulting →