Introduction
A bug-bounty researcher can find the flaw.
A CVD programme can receive the report.
A penetration test can examine a defined scope.
A red team can discover an unexpected route to an objective.
None of those mechanisms can retroactively turn a weak architectural decision into a good one after the product has already been shipped to thousands of customers.
If a product defaults to excessive privilege, lacks server-side authorisation, stores secrets in the wrong place, does not produce useful audit telemetry or has no ownership model for critical dependencies, external researchers may help discover those failures.
They cannot make the original development system sound.
External security research therefore belongs here:
as an additional assurance layer above internal secure-development capability, not as a replacement for it.
That principle is now visible not only in engineering guidance but increasingly in regulation.
NIS2 Article 21 requires essential and important entities to implement appropriate and proportionate cybersecurity risk-management measures that include security in acquisition, development and maintenance, vulnerability handling and disclosure, supply-chain security and assessment of control effectiveness.6
The EU Cyber Resilience Act goes further for products with digital elements by connecting risk assessment, design, development, production, delivery, maintenance and vulnerability handling across the product lifecycle.7
One timing qualification is important as of 25 September 2026: the CRA's main product-security obligations, including Article 13 and Annex I, generally apply from 11 December 2027. Article 14 reporting obligations began applying on 11 September 2026, but that does not mean the full Secure-by-Design requirements moved forward to the same date.7
Secure by Design is not “run a pentest before release”
Pre-release testing matters.
Secure by Design begins earlier.
The first question is:
Which security properties must the architecture possess before there is code to test?
Examples include:
- tenant A must never be able to read tenant B's objects;
- privileged administrators must use strong authentication;
- normal product operation should not require unnecessary privilege;
- secrets must not reside in client-controlled storage;
- security-relevant actions must be auditable;
- update authenticity and integrity must be verifiable;
- critical security capabilities should not be luxury add-ons;
- the easiest configuration path should not be the insecure one.
Those are design properties.
A penetration test may show that they were not achieved.
That is not the ideal moment to define them for the first time.
Secure by Design moves responsibility toward the producer
CISA and international partners frame Secure by Design around three high-level principles:
- take ownership of customer security outcomes;
- embrace radical transparency and accountability;
- build organisational structure and leadership to make security a product priority.4
That guidance is not EU law.
Its allocation-of-responsibility principle is nevertheless useful:
the burden of basic product security should not be pushed downstream onto the customer where the manufacturer can remove it upstream.
Secure by Default applies the same idea at configuration level.
If an essential control is:
- disabled by default;
- available only in a premium tier;
- dependent on difficult manual hardening;
- or useful security telemetry requires additional payment;
the producer is effectively shipping part of its security debt to the customer.
The CRA turns that responsibility into a lifecycle model
Annex I Part I of the Cyber Resilience Act requires products with digital elements to be designed, developed and produced to provide an appropriate level of cybersecurity based on risk.7
Depending on the risk assessment, the product must, among other things:
- be placed on the market without known exploitable vulnerabilities;
- use secure-by-default configuration;
- support security updates;
- protect against unauthorised access;
- protect the confidentiality and integrity of data.7
Article 13 then requires the cybersecurity risk assessment to inform:
- planning;
- design;
- development;
- production;
- delivery;
- maintenance.7
That is a product-engineering model, not “ship first, react to CVEs later”.
Vulnerability handling belongs inside the SDLC
Some organisations still operate as if product security were split into two worlds:
The administrative split may be convenient.
Technically, it is incomplete.
If an external researcher reports IDOR, closure should not stop at:
patch this endpoint.
The organisation should ask:
Why did our authorisation design and verification process allow this pattern?
If the issue is unsafe deserialisation:
Why did an untrusted deserialisation path exist?
If the issue is a hard-coded secret:
Why did review or pipeline controls not detect it?
NIST's SSDF explicitly links vulnerability response to identifying and addressing root causes so similar defects do not keep recurring.1
The mature loop is therefore:
not merely:
development team
→ builds product
security / PSIRT
→ handles vulnerabilities laterfinding
→ fix
→ root-cause analysis
→ variant search
→ regression test
→ design/coding rule
→ pipeline controlfinding
→ ticket closedNIST SSDF: four parts of the development system
As of 25 September 2026, NIST SP 800-218 SSDF v1.1 remains the final publication. NIST released an Initial Public Draft of SSDF v1.2 in December 2025, but it should not be cited as the current final baseline.12
SSDF v1.1 organises practice into four groups:
- Prepare the Organization (PO);
- Protect the Software (PS);
- Produce Well-Secured Software (PW);
- Respond to Vulnerabilities (RV).1
That structure is useful because secure software development is not synonymous with secure coding.
It also requires:
- roles and organisational preparation;
- protection of source, toolchains and artifacts;
- secure design and implementation;
- verification;
- vulnerability response and learning.
OWASP SAMM adds a maturity perspective
OWASP SAMM organises software assurance around five business functions:
- Governance;
- Design;
- Implementation;
- Verification;
- Operations.3
Its value is not a demand that every organisation use exactly the same process.
SAMM is risk-driven and technology/process agnostic.3
That helps avoid two bad extremes:
“We need every AppSec control anyone has ever invented.”
and:
“We are a small company, so secure development does not apply to us.”
The right control set depends on product risk and delivery model.
But important security boundaries should not be left to the hope that an external researcher eventually notices them.
Gate 1: define security requirements before architecture hardens
If security requirements first appear in a penetration-test report, they arrived late.
Before design, the team should identify at least:
- critical assets;
- trust boundaries;
- user and service roles;
- sensitive data;
- major abuse cases;
- critical security invariants;
- third-party dependencies;
- update and recovery model.
A security requirement should not say:
The system must be secure.
It should be testable.
For example:
tenant_idreceived from a client request is never treated as the source of authorisation.
Or:
every privileged state-changing operation is independently authorised server-side regardless of UI role.
Now there is a property that later testing can actually evaluate.
Gate 2: threat model before implementation
Threat modelling is not a diagram for the archive.
Its value is early decision-making.
A useful threat model exposes:
- trust boundaries;
- data-flow transitions;
- dependency assumptions;
- high-value abuse paths;
- systemic failure modes;
- places where defence in depth is justified;
- required fail-safe states.
It should be revisited when the product materially changes:
- authentication;
- authorisation;
- cloud architecture;
- data flows;
- privilege model;
- third-party integration;
- AI/tool permissions;
- administrative control paths.
A threat model that does not change with the product becomes historical artwork.
Gate 3: secure defaults
A meaningful amount of product risk comes from product choices rather than coding mistakes.
Examples include:
- default administrator credentials;
- MFA off by default;
- public storage;
- overly permissive CORS;
- debug endpoints in production;
- useful logs available only on premium plans;
- broad IAM permissions as defaults;
- opt-in security updates.
Secure by Default changes the question from:
Can an expert administrator make this secure?
to:
What happens if the administrator takes no special hardening action?
The CRA's secure-by-default requirement makes that question particularly important for covered EU products once the main requirements apply in December 2027.7
Gate 4: dependency and supply-chain control
A modern product is not just first-party source code.
It includes:
- open-source libraries;
- containers;
- base images;
- build tools;
- package registries;
- CI/CD actions;
- SaaS;
- cloud services;
- third-party SDKs.
So:
We reviewed our source code.
is not a complete product-security statement.
CRA Article 13 requires due diligence when integrating third-party components, including FOSS, so that those components do not compromise product cybersecurity.7
NIS2 Article 21(3) requires relevant entities, when considering supply-chain measures, to take account of vulnerabilities and the overall quality of suppliers' products and cybersecurity practices, including secure-development procedures.6
Operationally, that means knowing:
- which dependencies exist;
- their versions;
- who maintains them;
- how updates reach the product;
- how advisories are handled;
- how build provenance is protected;
- who owns a dependency when it becomes a security problem.
Gate 5: code and pipeline verification
No single tool is a security oracle.
SAST misses things.
DAST misses things.
SCA misses things.
Secret scanners miss things.
Code review misses things.
Verification therefore needs a combination appropriate to the product, such as:
- peer code review;
- SAST;
- DAST;
- dependency/SCA;
- IaC scanning;
- secret scanning;
- fuzzing;
- unit and security tests;
- API authorisation tests;
- tenant-boundary tests;
- negative tests;
- software supply-chain checks.
The goal of automation is not:
prove the software is secure.
It is:
cheaply and repeatedly stop defect classes that should not consume expensive human or external-researcher time every release.
Gate 6: make a release security decision
CI passed is not the same thing as a complete security decision.
Before release, the organisation should understand:
- what changed;
- which security boundaries changed;
- which checks ran;
- what was not tested;
- whether unresolved High/Critical findings remain;
- whether an exception exists;
- who accepted the exception;
- whether rollback exists;
- whether production monitoring can detect failure.
Risk-based does not mean:
security blocks every release.
It means:
when evidence is incomplete, the remaining risk is consciously decided rather than silently inherited.
Gate 7: design observability and recovery into the product
Secure by Design does not end at deployment.
If an organisation cannot later determine:
- who authenticated;
- which privileged action occurred;
- who changed configuration;
- which release was running;
- which dependency version was present;
it has lost a significant part of its security control.
CISA's Secure-by-Design work also argues that customers should receive necessary security controls and visibility rather than treating essential telemetry as an optional luxury.5
Product-security architecture therefore also includes:
- audit logging;
- alertable security events;
- secure updating;
- rollback;
- backup and recovery;
- degraded-safe operation;
- incident forensics.
Security includes the ability to understand what happened after prevention failed.
So when should external research begin?
In reality, an external researcher can appear at any time.
That is why an organisation should not postpone its vulnerability intake channel until it believes its SDLC is mature.
There is, however, a major difference between:
A. being able to receive an unexpected vulnerability report;
and
B. actively inviting a broad external population to test the product.
A should exist early.
B requires more operational readiness.
Before opening a broad bounty or actively expanding external testing, an organisation should normally have at least:
- clear scope;
- technical triage ownership;
- secure evidence intake;
- incident escalation;
- remediation capacity;
- retest capability;
- reward/dispute operations if money is involved;
- product teams able to absorb findings without improvisation.
External research should not wait for a mythical “perfect SDLC”.
It also should not become the system that discovers every defect class the internal pipeline could have cheaply prevented.
What external researchers do better than internal process
The argument here is not:
A strong SDLC makes external researchers unnecessary.
The opposite is closer to the truth.
Independent research is especially valuable for:
- unexpected perspective;
- different technical specialisation;
- novel exploit combinations;
- fresh eyes;
- production-reality testing;
- business-logic abuse;
- boundary cases the internal model did not anticipate.
A good SDLC removes more of the cheap, repeatable failure modes.
That lets external researchers spend more of their effort on harder, higher-information security problems.
That is a better crowdsourcing model than paying repeatedly for defects that could have been rejected automatically before release.
Every external finding is a test of the SDLC
A strong vulnerability report asks two questions.
First:
How do we fix this vulnerability?
Second:
Which internal control failed to prevent or detect this class?
For example:
If the organisation answers only the first question, CVD or bounty becomes outsourced QA.
If it answers the second, external research becomes a sensor for SDLC effectiveness.
| External finding | SDLC question |
|---|---|
| IDOR | Were authorisation invariants defined and negatively tested? |
| Hard-coded secret | Why did review or secret scanning not stop it? |
| Vulnerable dependency | Does SCA have an update owner and response path? |
| SSRF | Was outbound network trust designed explicitly? |
| XSS | Are framework/output-encoding controls consistently enforced? |
| Privilege escalation | Is the role model complete and tested negatively? |
| Insecure default | Who approved the default configuration? |
Not every bug needs a new process gate
Feedback can also become bureaucracy.
If every vulnerability creates:
- another checklist;
- another committee;
- another mandatory sign-off;
- another Jira field;
the process eventually becomes unusable.
Root-cause feedback should be proportionate.
Ask:
Is this a one-off implementation mistake or a recurring/systemic defect class?
For a one-off defect, a regression test may be enough.
For a recurring defect, change the:
- architecture rule;
- shared library;
- framework;
- pipeline check;
- developer guidance;
- security requirement.
The goal of a secure SDLC is not maximum process.
It is the cheapest reliable control closest to the point where the defect is created.
“Shift left” is not a complete strategy
Secure development is often reduced to shift left.
The idea is valid: catch problems earlier, when remediation is cheaper.
But it can degrade into:
Developers now own all of security.
That is not a mature operating model.
Some controls should move left.
Others must remain or grow on the right:
- production telemetry;
- attack detection;
- CVD;
- post-release vulnerability handling;
- incident response;
- regression based on real-world findings.
Secure software needs a full lifecycle.
Not only the left side of a pipeline.
Secure by Design is not the same as compliance
An organisation can run many security activities and still produce an insecure product.
Examples:
- threat-model document exists but is stale;
- SAST runs but Critical results do not affect release;
- dependency scanning exists but nobody owns upgrades;
- code review is mandatory but does not understand the authorisation model;
- annual pentest runs while production changes daily.
That is activity evidence.
It is not necessarily effectiveness evidence.
This connects directly to Cybersecurity Certification Should Prove Effectiveness, Not Just Activity.
A Secure SDLC works when controls actually reduce or detect the defect classes they are meant to control.
A minimum Secure SDLC evidence record
I would not create a huge compliance package for every release.
For material security changes, however, I would preserve something like:
This is not a mandated standard.
It is an evidence unit.
The point is to be able to answer after an incident or external finding:
What did we know about this risk before release, what did we test, and who accepted what remained?
change:
release:
components_changed:
trust_boundaries_changed:
security_design:
requirements:
threat_model_updated:
new_abuse_cases:
verification:
code_review:
automated_security_checks:
authorization_negative_tests:
dependency_review:
manual_security_test:
open_findings:
critical:
high:
exceptions:
release_decision:
approver:
residual_risk:
rollback_ready:
production:
logging_ready:
detection_ready:
support_and_patch_owner:The CRA makes this explicitly a product-lifecycle problem
The Cyber Resilience Act is particularly significant because it does not stop at one pre-market security test.
It connects:
- cybersecurity risk assessment;
- design;
- development;
- production;
- delivery;
- maintenance;
- third-party components;
- vulnerability handling;
- security updates;
- coordinated vulnerability disclosure.7
Annex I Part II requires manufacturers, among other things, to:
- identify and document vulnerabilities and product components;
- remediate vulnerabilities without undue delay;
- perform effective and regular security tests and reviews;
- establish and enforce a coordinated vulnerability-disclosure policy;
- provide a contact point for vulnerability reporting.7
That is why:
Secure by Design and vulnerability disclosure are not competing strategies.
They are different parts of one lifecycle.
NIS2 makes a similar point at organisational level
NIS2 Article 21 requires covered essential and important entities to address not only incident handling, but also:
- supply-chain security;
- acquisition;
- development;
- maintenance;
- vulnerability handling and disclosure;
- assessment of cybersecurity-measure effectiveness.6
So an entity cannot reasonably reduce the model to:
We have CVD, therefore researchers will compensate for weak development.
Disclosure is one risk-management control among several.
Security debt should not be repeatedly exported to researchers
External researchers should not become a recurring substitute for controls the organisation could cheaply automate or standardise.
Examples include:
- public secrets;
- default credentials;
- long-known vulnerable dependencies;
- missing server-side authorisation across whole API families;
- recurring basic input-validation failures;
- one root cause repeatedly reappearing.
If a researcher finds one of these, the report can still be entirely valid.
The organisational question is different:
Why are we repeatedly buying discovery of this defect externally instead of removing the root cause internally?
Bug bounty should pay for useful security signal.
It should not finance the absence of a Secure SDLC.
A readiness gate before actively expanding external testing
I would use a minimum readiness check.
An organisation is reasonably prepared to actively expand external testing if:
- the asset inventory is known and current;
- scope authority is understood, including third-party boundaries;
- critical security requirements are defined;
- material changes receive threat analysis;
- code/dependency/pipeline controls exist;
- there is a release-security decision process;
- logging and incident escalation work;
- a vulnerability-intake route exists;
- technical triage has an owner;
- remediation and retest capacity exists;
- external findings feed root-cause and SDLC improvement.
This is not a certificate to “open the bounty”.
It is a sanity check.
If item 8 is missing, build CVD.
If 9 and 10 are missing, actively inviting a much larger volume of findings may be premature.
Conclusion
Secure by Design does not mean building software that will never contain a vulnerability.
That is not a defensible assurance claim.
It means something more practical:
The producer accepts responsibility for reducing predictable classes of security failure before the customer and external researcher inherit them.
External researchers can then do what they do best:
- approach the system differently;
- combine unexpected paths;
- test reality;
- find boundary cases;
- challenge internal assumptions.
They should not be the first people to tell the organisation that:
- there is no coherent authorisation model;
- nobody owns dependencies;
- the product ships insecure by default;
- useful audit logs do not exist;
- negative cases are never tested.
External research is therefore most valuable not instead of strong development, but on top of it.
In one sentence:
CVD is a safety net. Bug bounty is a market for external attention. Pentest is a controlled test. Secure by Design is the responsibility the producer cannot delegate to any of them.
Frequently asked questions
Should an organisation wait for a mature Secure SDLC before publishing a CVD channel?
No. A vulnerability-reporting route should exist even for an immature organisation because researchers may discover issues at any time. Greater readiness is especially important before actively opening a broad bug-bounty or external-testing programme.
Can bug bounty replace SAST, code review or penetration testing?
No. Bug bounty provides a different discovery model. It does not provide systematic coverage and should not replace baseline secure-development and assurance controls.
Does Secure by Design mean software must contain zero vulnerabilities?
No. A realistic goal is to reduce predictable defects, make exploitation harder, provide secure defaults and maintain an effective capability to discover, remediate and distribute security updates.
Are the CRA Secure-by-Design requirements already fully applicable in September 2026?
No. The CRA generally applies from 11 December 2027. Article 14 reporting obligations apply from 11 September 2026, but that does not move the full Article 13 and Annex I product-security regime to the earlier date.7
What is the difference between Secure by Design and Secure by Default?
Secure by Design concerns architecture and lifecycle choices that make the product safer. Secure by Default means the initial configuration already enables an appropriate security baseline without requiring the customer to discover and switch on essential protections.
What should happen after an external finding is fixed?
Analyse the root cause and variants, then decide whether the defect class should become a regression test, design rule, shared component change or automated pipeline control. Otherwise the same weakness may reappear elsewhere.
Source status
Sources and EU legal status checked on 25 September 2026. NIST SSDF v1.1 is the current final publication; SSDF v1.2 is an Initial Public Draft as of this date. The CRA's main product and manufacturer Secure-by-Design/vulnerability-handling obligations generally apply from 11 December 2027; Article 14 reporting obligations apply from 11 September 2026. The gates, readiness model and evidence record in this article are the author's practical methodology.
This article analyses secure software development and product-security assurance practice. It is not individual legal advice.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, Final, 3 February 2022 · NIST
- NIST SP 800-218 Rev. 1, SSDF Version 1.2, Initial Public Draft, 17 December 2025; public comment period closed · NIST
- OWASP, Software Assurance Maturity Model (SAMM), checked 25 September 2026 · owasp.org
- CISA and international partners, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software · cisa.gov
- CISA, “When Tech Vendors Make Important Logging Info Available for Free, Everyone Wins”, 19 July 2023 · cisa.gov
- Directive (EU) 2022/2555 (NIS2), particularly Article 21(2)(d)–(f) and Article 21(3) · EUR-Lex
- Regulation (EU) 2024/2847 (Cyber Resilience Act), particularly Articles 6, 13 and 71 and Annex I Parts I–II · EUR-Lex