Secure software development without a final security gate

Secure software does not come from one check at the end. This guide shows how ownership, requirements, code, dependencies, build, tests and production management become part of the normal development process from the start.

The short answer

Secure software development does not mean a security team runs one final check at the end. It means that ownership, requirements, code, dependencies, build, tests, deployment and production management are part of the normal development process from the start. Security becomes a property of how you work, not a gate at the finish line.

Four qualifications belong here from the outset. Not every team needs every role or every tool: a team of four building an internal tool sets this up differently from a payments platform. More scanners do not automatically mean safer software: a scan nobody reads adds nothing. Automated checks support human judgement, they do not replace it. And the level you need depends on the data you process, the business impact of an incident, the threats that are realistic for your product and the risk tolerance of your organisation.

This guide is written for founders of software companies, CTOs, engineering managers, product owners and technical buyers who want to organise security more structurally without immediately building a security department. We rely on primary sources: the NIST Secure Software Development Framework (SSDF 1.1) as a framework of practices and desired outcomes, OWASP ASVS as a verification standard, OWASP SAMM as a maturity model, the OWASP Web Security Testing Guide as a testing guide and the Dutch NCSC guidelines as practical government guidance. Where we make our own judgement call, it is explicitly marked as tre plus analysis.

What is in scope and what is not?

The market uses the same words for very different things. This table puts the terms side by side, the way we use them in this guide.

Three explicit boundaries. Secure software development is not a synonym for penetration testing: a pentest is one check at one moment, not a way of developing. Security testing is not the same as all of QA: functional tests verify the software does what it should, security tests verify it does nothing it should not. And DevSecOps does not mean every developer must become a security specialist: it means the pipeline runs checks that are usable for developers. General IT security, endpoints, awareness and network monitoring are deliberately outside this page.

Ownership: security is shared, but not ownerless

"Everyone is responsible" sounds good, but in practice it often means nobody picks up a finding. That is why the NIST SSDF does not start with tools but with the organisation: prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities. Those four practice groups run from ownership to execution. The framework is risk-based and adaptable: you decide per practice whether it fits your risks, instead of ticking every box.

The matrix below shows, per area, who executes, who decides and who verifies independently. It is a practical starting point, not a prescription: in a small team one person fills several columns, and that is fine as long as it is named.

Note the last column. Independent verification does not always mean an external party: a second developer reviewing a pull request is independent verification too. The point is that the author is never the only checker.

From idea to production: seven phases

This lifecycle follows the structure that the NIST SSDF and the NCSC guidelines for secure software development also use: security belongs in every phase, not only at the end. For each phase we cover the goal, the minimum practical control, possible deepening, the normal owner and the evidence that remains.

1. Requirements and risk

Goal: record what the software may do and what it must never do. Minimum control: for risky changes, explicitly note which data is touched and what could go wrong. Deepening: security requirements based on a verification standard such as OWASP ASVS, linked to the risks of your product. Owner: product owner, with the tech lead for the technical content. Evidence: security requirements attached to the relevant tickets or in the project specification.

2. Design and architecture

Goal: make the choices that are hard to repair later, such as the authorisation model, data flows and trust boundaries. Minimum control: for new components, a short assessment of who can access what and which data flows where. Deepening: threat modelling for the components with the highest impact. Owner: tech lead or senior developer. Evidence: a recorded design decision or threat model, however brief.

3. Development and code review

Goal: catch mistakes while they are still cheap. Minimum control: every change is reviewed by a second developer, with attention to input validation, authorisation and error handling. Deepening: review guidelines with an explicit security checklist, for example derived from the ASVS requirements that apply to your product. Owner: the development team, with the tech lead guarding the rules. Evidence: review rules and a review trail in your version control.

4. Dependencies and the software supply chain

Goal: know what you carry into your product. Minimum control: a current inventory of dependencies and runtimes, with an agreement on who tracks and applies updates. Deepening: an SBOM as a formal inventory, dependency scanning in the pipeline and a policy for expired or abandoned packages. Owner: developers for the code, the tech lead for the policy. Evidence: a dependency inventory or SBOM and an update log.

5. Build and CI/CD

Goal: keep the path from code to production manageable. Minimum control: secrets outside the code, a reproducible build and a pipeline that always runs tests and basic checks. Deepening: SAST, SCA and secret scanning as part of the pipeline, with agreements on when a finding blocks a release. Owner: the DevOps or platform responsible. Evidence: pipeline output and the release decisions that followed from it.

6. Test and release

Goal: establish before go-live that the software behaves as intended, also under unusual input. Minimum control: automated functional tests plus a conscious check of risky flows such as login, payments and permissions. Deepening: DAST or API security tests against a running test environment, and for critical releases an independent test or pentest. Owner: QA together with development, the product owner decides on go-live. Evidence: test results and a release decision.

7. Production, updates and responding to vulnerabilities

Goal: stay in control after release. Minimum control: know which version is running, an urgent patch procedure and a named owner for incoming vulnerability reports. Deepening: logging and monitoring that make anomalies visible, periodic review of exceptions and a rehearsed response to severe reports. Owner: the operator or hosting provider for the runtime, the product team for the application. Evidence: a patch log, change records and an incident procedure.

One warning for all these phases: documentation is supportive, not proof that software is secure. A threat model nobody reads and an SBOM nobody updates say nothing about the safety of yesterday's release. Evidence only counts when it is current and has an owner.

Which control does what?

There are many controls and they deliberately overlap. The table shows, per control, what is examined, when you run it, what it finds well, what it probably misses and who it belongs to. None of these controls alone proves that an application is secure.

The factual limits matter more than the possibilities. SAST examines code without running the application and therefore sees no runtime behaviour. DAST tests the behaviour of a running application, but only the paths the test reaches. SCA examines the components you use and their known vulnerabilities, not the vulnerabilities nobody has found yet. An SBOM is primarily an inventory, not a security scan. Secret scanning can detect known patterns, but it does not prevent every secret in code or logs. A pentest is a point-in-time assessment and does not replace continuous controls. No tool proves that an application is completely secure.

Why scanners alone are not enough

Automated controls are valuable, but they have structural limitations you need to know before you rely on them.

False positives: tools report problems that are not there. Without someone assessing the reports, noise builds up, and noise leads to ignored warnings. False negatives: tools miss problems that are there. A green scan means the tool found nothing, not that there was nothing to find.

The deeper limitation is context. A scanner does not know your business. Authorisation and business logic flaws, such as a customer who can reach another customer's invoices, are rarely a pattern a tool recognises. Configuration errors outside the code, such as a misconfigured header on the load balancer, fall outside what a code scanner sees. And a finding without an owner disappears into a list: scans that run but never block a release, exceptions that become permanent and warnings ignored because of too much noise are organisational problems, not tool problems.

The Dutch NCSC examined new developments in static analysis: a literature study combined with a survey among 44 Dutch software professionals, comparing three newer tools (CodeQL, Infer and Semgrep) with SonarQube. The conclusions are sober: custom detection rules add a lot and tools complement each other, so no single tool covers everything. We draw no conclusions from that bounded research about all Dutch companies or all tools. What it does support is what practitioners have known for longer: a scanner is a tool for a reviewer, not a replacement.

The practical lesson: connect every automated finding to an owner and a deadline, record when a finding blocks a release and review exceptions periodically. That is organisational work, which is exactly why it belongs to ownership and not to tooling.

Which role do you need?

Not every team needs every role, and certainly not at the same time. This decision matrix helps you determine which profile fits the gap you actually have. Per role: when it fits, when it is not enough and which internal owner always remains.

Developer

Fits: secure implementation, applying dependency updates, doing code review and repair work inside your own codebase. Not enough when: nobody sets the direction for what is secure enough, or when the problem sits in the pipeline or infrastructure. Internal owner who remains: the tech lead, who guards review rules and priorities.

QA/Test Automation Engineer

Fits: repeatable functional, integration, API, regression and end-to-end tests, including security-related scenarios such as permissions between users. Not enough when: you expect test automation to cover application security automatically; a QA engineer is not automatically an application security specialist. Internal owner who remains: the product owner, who decides which risks must be tested.

DevSecOps Engineer

Fits: security controls in CI/CD, dependency and image checks, secrets, deployment rules, cloud or container configuration and making findings usable for developers. Not enough when: the problem sits in the application code or architecture, or when there is no pipeline to place controls in. Internal owner who remains: the platform or technical owner who decides which findings block a release.

Application Security Specialist

Fits: threat modelling, security requirements, complex code or architecture assessment and coaching teams in secure development practices. Not enough when: there is no development capacity to actually fix the findings. Internal owner who remains: the technical leadership, which translates recommendations into the roadmap.

Pentester

Fits: an independent, bounded assessment of a running application or environment, for example before a major release or at a customer's request. Not enough when: you want continuous assurance; a pentest is a point-in-time assessment and says nothing about next week's release. Internal owner who remains: the person who receives, prioritises and gets the findings fixed.

Deliberately stated: this is a decision matrix for your organisation, not an offer. tre plus does not provide all these roles as standard. Where we do add capacity is described later in this guide.

A minimum viable security process

For a product team without its own security department, this is a realistic base model. It is a practical growth model from tre plus: not a certification, and not the official levels of OWASP SAMM. If you want a recognised maturity model, use SAMM to assess and benchmark your own situation.

Base

Name an owner for security in the development process. Run on supported runtimes and keep dependencies current. Make review mandatory for every change. Keep secrets out of the code. Run automated tests with every build. Record an urgent patch procedure: who decides, who executes, who verifies.

Repeatable

Record security requirements for risky changes. Place SAST, SCA and secret scanning in the CI pipeline. Maintain a dependency inventory. Make the build reproducible. Record release criteria, including when a finding blocks a release. Give every finding an owner and a deadline.

Deepened

Run threat modelling for the components with the highest impact. Base requirements on ASVS for the parts that apply to you. Add DAST or API security tests against a running test environment. Maintain an SBOM. Have an independent test or pentest performed periodically. Review exceptions and incidents periodically, so temporary measures do not become permanent.

The order is deliberate: ownership and basic habits first, then automation, then deepening. A team at Base level that does it consistently is in a better position than a team with expensive tools at Deepened level and no owner for the findings.

The first thirty days

A sober starting plan for a team that begins today. It does not guarantee that your organisation is secure or compliant; it delivers a working start with an owner.

Week 1: inventory your critical applications, the runtimes and dependencies they run on and the owners per component. Include older environments and separate containers; those are forgotten most often.

Week 2: record review rules, update policy and the minimum automated checks. Write down who tracks, decides and validates future runtime and dependency updates.

Week 3: place the checks in CI/CD and determine the responsibilities for findings: who receives them, who assesses them, within which deadline.

Week 4: test one critical release flow or application against the new process and adjust. What turned out to be unworkable administration? Which finding had no owner? Adjust the process, not reality.

What the PHP incident shows about this

In October 2026, PHP published patches for two critical vulnerabilities in the runtime itself. We deliberately leave the technical details out here; they are in our article on the critical PHP vulnerabilities of October 2026. What matters here is what the incident shows about the setup of your development process.

The vulnerability sat below the application code, in the runtime. Plugin, Composer or application updates do not automatically update the PHP runtime, so a team that only updates the application stays vulnerable without noticing. That is exactly the gap a dependency and runtime inventory closes: you need to know which runtimes run in production and which versions of them are supported.

The second point is ownership. In many organisations the runtime sits between the product team, the hosting provider and a supplier, and during this incident it turned out nobody felt responsible for the question whether PHP was patched. That division must be clear in advance, not during an emergency update.

The third point is that temporary measures do not replace patching. The official mitigations for this incident were explicitly incomplete. Treating temporary measures as a solution builds a permanent exception. That is exactly why the periodic review of exceptions sits in the deepened level of the growth model above.

AI-generated code

One compact section, because this topic does not deserve its own hype. AI can speed up code production, but it does not take over responsibility. Generated code goes through the same review, test and security requirements as handwritten code. A plausible answer is not proof of correct authorisation, data handling or error handling: models produce code that looks good and can still contain a wrong assumption.

AI can also help with analysis and test suggestions, for example thinking through edge cases or reading an unfamiliar codebase. Those outcomes must be checked too. We cover the broader question of what AI means for the composition of development teams in our article on AI and nearshore development.

Where tre plus fits and where it does not

tre plus is a nearshore development partner, not a cybersecurity company. Where we add capacity: developers who work inside the existing client team, QA and test automation capacity, and DevOps or DevSecOps capacity when the profile demonstrably matches the work. Structural maintenance, testing, review and CI/CD are part of the development work itself for us. The client always keeps the roadmap, the architecture, the access and the technical direction.

Where we explicitly do not fit: a SOC or 24/7 security monitoring, managed detection and response, incident response or forensics, an independent pentest certificate, a compliance audit, NIS2, GDPR or other legal guarantees, a one-off security scan as a standalone product and full result responsibility for a bounded security project. For that work, specialised providers are the right choice.

If you want to know what working with us looks like in practice, the models are on our services page, with the details at Developer as a Service and Team as a Service. Specifically for PHP teams, more is on the nearshore PHP developers page. If you read this as an engineering leader, the page for engineering leaders is written for your questions. And if you are making a broader comparison of nearshore partners, you can use our buyer guide for choosing a nearshore partner.

Checklist for engineering leaders

Fifteen questions to test your own situation. No form, no download: print them or take them to your next team meeting.

1. Do we know which runtimes and dependencies run in production?

2. Is it clear who applies critical updates?

3. Are security requirements linked to product risks?

4. Is every change reviewed by a second developer?

5. Are automated findings assigned to an owner?

6. Can we demonstrate which version is currently running?

7. Have we recorded when a release must stop?

8. Do we know who acts on a severe vulnerability?

9. Are temporary exceptions reviewed again?

10. Do we know when independent verification is needed?

11. Are secrets kept out of code and logs?

12. Do we run on supported versions of runtimes and frameworks?

13. Is there a rehearsed procedure for urgent patches?

14. Does the team know which data does not belong in external tools?

15. Is it named per lifecycle phase who executes, who decides and who verifies?

If you answer a question with "we should check that", you have your first action point. Start with ownership, not with tooling.

Frequently asked questions

What is secure software development?

Building security into the entire development process, from requirements to production management, instead of one check at the end. Ownership, requirements, code, dependencies, build, tests and deployment all take part.

Is DevSecOps the same as secure software development?

No. DevSecOps is about security controls in the build and deployment pipeline. Secure software development is broader: it also covers requirements, design, code review and production management. DevSecOps is a subarea, not a synonym.

What is the difference between SAST, DAST and SCA?

SAST examines source code without running the application. DAST tests the behaviour of a running application from the outside. SCA examines which components you use and which known vulnerabilities they contain. They find different things and complement each other.

Is a pentest enough?

No. A pentest is a point-in-time assessment of a running application, valuable as an independent check but no replacement for continuous controls in the development process. Next week's release falls outside the scope of last month's pentest.

Does every team need a security engineer?

No. Small product teams often get far with a named owner, good review habits, basic checks in the pipeline and a clear patch procedure. An application security specialist becomes appropriate with higher risks, stricter customer requirements or complex architectures.

What is the difference between QA and security testing?

QA checks whether the software does what it should do. Security testing checks whether it does nothing it should not do. A QA engineer can automate security scenarios, but that does not automatically make them an application security specialist.

How do you start without your own security department?

Start with ownership: name someone, inventory runtimes and dependencies, make review mandatory and record an urgent patch procedure. Then automate the basic checks in the pipeline. The 30-day plan in this guide gives a concrete order.