Secure by Design Is Not Enough: Can Your Software Vendor Prove It?

“Secure by design” has become one of the defining principles of modern software security. Vendors are expected to consider security from the outset, reduce dangerous defaults, protect development environments and maintain their products throughout their operational lives.

The direction is right. The problem is that a principle, policy or promise does not prove that secure development is actually happening.

A supplier may say that it follows a secure development lifecycle. It may have a vulnerability management policy, use automated testing and require developers to complete annual security training. Yet customers, assessors and senior leaders still need to answer a more difficult question:

What evidence demonstrates that these practices operate effectively for the software being supplied?

That question lies at the heart of the UK Software Security Code of Practice. The voluntary Code contains 14 principles across four themes: secure design and development, build environment security, secure deployment and maintenance, and communication with customers. It is intended to establish a consistent baseline of software security and resilience for organisations that develop or sell software to business customers.

More significantly, the supporting NCSC Assurance Principles and Claims translate the Code’s high-level principles into individual claims that can be objectively evidenced. The NCSC states that where all relevant claims are well evidenced, a vendor can claim in good faith that it meets the associated principle.

This changes the conversation. Secure by design is no longer only about adopting good practices. It is increasingly about creating a defensible chain from principle, to claim, to evidence, to conclusion.

The gap between doing security and proving security

Most software vendors are not starting from nothing. They already possess substantial security evidence: secure development policies and engineering standards; architecture decisions and threat models; source-code and dependency scanning results; build-pipeline configurations and access logs; penetration tests and release test records; software bills of materials; vulnerability tickets and remediation records; developer training records; incident procedures and customer notifications; and support policies and end-of-life notices.

The challenge is rarely the complete absence of information. It is that evidence is fragmented across development platforms, document repositories, ticketing systems, cloud services, spreadsheets and individual teams.

A policy may describe how third-party components should be controlled, while the component inventory sits in another system, vulnerability scans are held elsewhere and evidence of remediation is buried in engineering tickets. Each artefact may be useful, but none provides the complete assurance argument by itself.

This creates two risks.

The first is false confidence. An organisation sees the existence of a policy or tool and assumes the underlying security outcome has been achieved.

The second is unrecognised good practice. Teams may be operating strong controls, but cannot demonstrate them efficiently because the evidence has not been mapped, evaluated and presented coherently.

The result is familiar: lengthy supplier questionnaires, repeated requests for the same documents, inconsistent answers, avoidable audit effort and conclusions that depend too heavily on whoever happens to assemble the response.

What the NCSC expects vendors to evidence

The Assurance Principles and Claims make clear that evidence must extend across the software lifecycle.

Under secure design and development, vendors should be able to show, among other things, that their development framework is documented, developers are trained, requirements are recorded, third-party components are identified and tested, and test plans are repeatable. The claims also address threat modelling, privileged-user MFA, input validation and secure storage of credentials and sensitive data.

For build environment security, evidence should demonstrate that roles are defined, credentials are protected, multifactor authentication is used, access is reviewed and changes to the environment are controlled and logged. Logs must themselves be auditable and appropriately protected.

Secure deployment and maintenance extend the obligation beyond release day. Vendors need evidence that software is distributed through trusted channels, update integrity can be verified, vulnerabilities can be reported confidentially, known vulnerabilities are monitored and prioritised, affected parties are informed and security updates are tested and issued as soon as practicable.

The final theme addresses communication with customers. Vendors are expected to publish support information, update processes and end-of-support dates, provide at least one year’s notice before support ends, and communicate incidents that could significantly affect customers.

These are not isolated documentation requirements. Together they form an assurance case: a reasoned explanation of why the vendor believes its software achieves the intended security outcome, supported by evidence that can be inspected and challenged.

Evidence quality matters as much as evidence presence

A common assessment mistake is to treat all evidence as equally persuasive.

A policy stating that every release must undergo security testing is relevant, but it does not prove that a particular release was tested. A screenshot showing that a scanning tool is enabled is useful, but it may not show whether findings are reviewed or resolved. A penetration-test report provides stronger evidence of testing, but its value depends on scope, age, methodology and whether identified issues were remediated.

Effective assurance therefore needs to consider several dimensions:

Relevance: Does the evidence actually address the claim?

Authority: Was it produced or approved by a credible owner?

Scope: Does it apply to the product, version, environment and service being assessed?

Timeliness: Is it recent enough to support the current conclusion?

Completeness: Does it cover the whole claim, or only one part?

Consistency: Does it agree with other evidence, or expose contradictions?

Operational strength: Does it demonstrate implementation and testing, rather than merely intention?

This is where traditional document collection often fails. A shared folder may contain hundreds of files, but volume is not assurance. Without structured evaluation, organisations can confuse an evidence repository with an evidence-based conclusion.

Self-assessment must remain defensible

The Code permits different forms of evidence and gives vendors flexibility in how they demonstrate conformance. Evidence may include document inspection, interviews, test plans and test results. Where a claim cannot be fully evidenced, the NCSC expects the gap and the corrective action to be clear.

That flexibility is valuable because software organisations differ greatly in scale, development model and technology. However, it also places responsibility on the vendor to explain why its chosen evidence is sufficient.

A self-assessment should therefore not be a collection of optimistic yes-or-no answers. Each conclusion should identify the claim being assessed; the relevant product and organisational scope; the evidence examined; how that evidence supports the claim; limitations, assumptions or contradictions; residual gaps and their significance; the action required to improve confidence; and the accountable owner and target date.

This matters commercially as well as technically. Government consultation found substantial support for an assurance or certification scheme and indicated that organisations were likely to use the Code in procurement and supplier management. The government has also stated that it is developing a certification scheme based on the Code’s compliance process.

Vendors that can provide clear, reusable assurance will be better placed to answer customer due-diligence requests, reduce friction during procurement and distinguish themselves from competitors whose security claims remain largely unsupported.

Turning scattered artefacts into defensible assurance with CyConex

CyConex is designed for precisely this evidence problem.

Rather than asking teams to manually read every document and repeatedly recreate assessment responses, CyConex ingests the organisation’s existing evidence and assesses it against defined framework controls, principles and underlying obligations.

For the Software Security Code of Practice, the 14 principles and their supporting claims can be represented as an assessment structure. CyConex can then identify potentially relevant evidence, map it to the appropriate claims and explain how strongly it supports the required outcome.

This creates several practical benefits.

1. Faster evidence discovery

Security evidence is often written for an operational purpose, not for an assessor. A release procedure may contain only one paragraph relevant to build integrity. An incident plan may describe customer communication across several sections. CyConex can retrieve the relevant passages rather than requiring an assessor to search entire documents manually.

2. Evidence assessed in context

Finding a keyword is not enough. CyConex evaluates whether the evidence actually addresses the claim, whether it is sufficiently specific and whether it demonstrates implementation rather than intention. It can distinguish between a policy commitment, a defined process, a technical design and evidence that the control has been tested.

3. Transparent rationale and traceability

Every conclusion should be explainable. CyConex links assessment rationale back to the source evidence, allowing a human reviewer to inspect the supporting material and accept, challenge or refine the conclusion.

AI assists the analysis, but the assessor remains in control.

This creates a traceable relationship between the requirement, the evidence considered, the assessment rationale and the resulting conclusion. Customers and assessors can see not only what conclusion was reached, but why it was reached.

4. Gaps identified at the right level

A weakness discovered against one claim may not require a new document. It may indicate that an existing secure development policy needs updating, that release evidence is not being retained, or that one organisation-wide process is inconsistently implemented across products.

CyConex can consider the wider project and organisational context, helping teams address root causes instead of generating a separate artefact for every assessment question.

This makes remediation more efficient. One improvement to a shared process, policy or evidence-retention practice may close several related gaps across multiple claims.

5. Reusable Assurance Packs

Once evidence has been assessed, CyConex can organise the rationale, conclusions, gaps and source material into a structured Assurance Pack. This gives customers or independent assessors a coherent evidence trail rather than a questionnaire accompanied by an unstructured archive of attachments.

An Assurance Pack can bring together the principle and supporting claims; the assessment outcome; the rationale behind that outcome; relevant evidence extracts; links or references to source artefacts; identified limitations and evidence gaps; recommended remediation actions; and evidence needed for independent verification.

The same underlying evidence can also support multiple frameworks. The NIST Secure Software Development Framework, for example, provides a common set of practices that can be integrated into different software development lifecycles and used to improve communication between producers and purchasers.

Properly mapped evidence should therefore be reusable across related obligations rather than collected again for every assessment.

6. Assurance that evolves with the software

Software, infrastructure, dependencies and threats continually change. A self-assessment completed once and left untouched will steadily lose value.

A new release may introduce different components. Build-pipeline permissions may change. A key member of staff may leave. A vulnerability may be discovered in an embedded dependency. A previously supported product may approach end of life.

Each change can affect the validity of an earlier assurance conclusion.

CyConex can help teams identify stale evidence, changed artefacts and claims requiring reassessment. This supports the NCSC’s recommendation that vendors conduct regular audits, monitor compliance and update practices as the Code and threat landscape evolve.

The result is a move away from periodic document gathering towards a living assurance position that reflects the current state of the product and its supporting processes.

From compliance exercise to commercial asset

The greatest value of evidence-based software assurance is not the production of another compliance report.

A well-maintained assurance position can improve engineering governance, reveal where processes are inconsistently applied, make security investment more targeted and give senior leaders a clearer view of whether secure-development commitments are actually being met.

It can also strengthen the relationship between vendor and customer.

Customers do not need unrestricted access to source code, sensitive build systems or every internal ticket. They do need credible answers to reasonable questions about how the product is designed, built, maintained and supported.

A structured assurance case allows a vendor to provide proportionate transparency while protecting sensitive information.

For vendors, this can shorten due diligence, reduce repetitive questionnaires and support more confident sales conversations. It can also provide reusable evidence for customer assessments, procurement exercises and future certification.

For customers, it creates a stronger basis for procurement, contract management and ongoing supplier assurance. Instead of accepting unsupported declarations, they can examine the rationale and evidence behind each security claim.

For senior leaders, it provides greater confidence that the organisation’s public commitments are supported by its operational reality.

Secure by design must become evidence by default

The Software Security Code of Practice reflects a broader change in cyber security expectations. Organisations are increasingly expected not only to adopt good practices, but to demonstrate that those practices produce the intended outcomes.

The NCSC’s claims-based approach gives vendors a practical route from broad principles to objective evidence. But creating that evidence chain manually can be slow, inconsistent and difficult to maintain, particularly where information is distributed across many teams and systems.

CyConex helps close that gap. It brings together existing evidence, maps it to security claims, assesses its strength, exposes missing coverage and produces a traceable assurance position that can be reviewed by people and shared with customers.

It also enables organisations to reuse evidence, direct remediation towards underlying weaknesses and maintain assurance as products, dependencies and practices change.

Secure by design remains essential. But in a market increasingly shaped by software supply-chain risk, customer scrutiny and emerging assurance schemes, saying that software is secure will not be enough.

The vendors that earn trust will be those that can prove it.