What Is Product Security? A UK Guide to ProdSec
In May 2026 a single malicious package slipped into the npm and PyPI ecosystems and spread through CI/CD pipelines, package registries and developer tooling in a matter of days. The organisations affected had not been breached through a clever phishing email or a misconfigured firewall. They were compromised through something they had installed, trusted, and never looked at again.
That is the problem product security exists to solve. It is the discipline of making sure the thing you ship, and everything it is built from, stays trustworthy from the first design sketch until the day you switch it off.
Key Takeaways
- Product security (ProdSec) covers the whole lifecycle of a product, not just the code: design, build, dependencies, release, operation, and end-of-life.
- Software supply chain failures are now a top-three risk. OWASP’s 2025 list introduced A03 Software Supply Chain Failures, and 31% of breaches in Verizon’s 2026 DBIR began with a software vulnerability.
- UK regulation is tightening. The PSTI Act, UK GDPR/DPA 2018, and the Cyber Essentials scheme all push product security obligations onto manufacturers and suppliers.
- Assurance is lagging. Only 14% of UK businesses review cyber risk from their immediate suppliers, and just 7% review the wider supply chain.
- ProdSec is a programme, not a product. Threat modelling, an SBOM, disciplined vulnerability management, and an incident reporting route are the foundations.
What is product security?
Product security, often shortened to ProdSec, is the practice of protecting a product from security threats throughout its entire lifecycle. A “product” here is deliberately broad: a software application, a firmware-driven device, an API, a platform, or a combination of all three.
Where many security efforts begin at the point of deployment, product security starts much earlier and finishes much later. It asks questions at every stage:
- Ideation and design: what could an attacker do with this, and how do we design that away?
- Build: are the components we depend on trustworthy, and do we know what they are?
- Release: can we ship securely and prove the artefact has not been tampered with?
- Operation: how do we find, prioritise, and fix vulnerabilities once customers are using it?
- End-of-life: how do we tell customers when support ends, and retire it safely?
The goal is not perfection at any single moment. It is a defensible, repeatable process that keeps the product’s risk posture under control as the threat landscape, the codebase and the customer base all change.
ProdSec vs AppSec vs InfoSec
These three terms overlap, and the overlap causes real confusion in procurement meetings. The cleanest way to separate them is by scope.
Application security (AppSec) focuses on the application itself: the code, the dependencies it pulls in, and the way it is written and tested. AppSec is a large and important part of product security, but it begins at the code and largely ends at the running application.
Information security (InfoSec) is broader in a different direction. It covers the confidentiality, integrity and availability of information across an organisation, people, processes, networks, physical security, policies. It protects the business around the product.
Product security sits between and beyond them. It owns the product as an asset: its design, its supply chain, its release process, its fielded lifetime and its eventual retirement. AppSec is a subset of ProdSec; InfoSec is the organisational context ProdSec operates within.
Why product security matters for UK businesses
Three forces have converged to make product security a board-level concern rather than a nice-to-have engineering practice.
Attacks have shifted to the software itself
Verizon’s 2026 Data Breach Investigations Report found that 31% of breaches now start with a software vulnerability, overtaking stolen credentials as the single most common initial access route. Attackers are moving away from tricking people and towards exploiting systems, and systems are what product security is built to defend.
The same report found 48% of breaches involve ransomware and that 15% of attack techniques are now bolstered by generative AI. IBM’s Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million, up 12% year on year, and an average of USD 6 million where an AI model inversion attack is involved.
The supply chain is the soft underbelly
Modern products are assembled from hundreds or thousands of third-party components, fetched automatically by CI/CD pipelines with no human in the loop. That combination of automation, trust, and scale is exactly what attackers exploit.
The NCSC’s June 2026 blog on software supply chain attacks is blunt about it: attackers compromise open-source packages at scale to spread malware, and ecosystems such as Node.js, Rust, and Python are unusually exposed because they lean heavily on third-party libraries. OWASP responded by elevating Software Supply Chain Failures to A03 in its 2025 Top 10, a new entry in the top three.
UK businesses are under-assured
The picture closer to home is uncomfortable. The Cyber Security Breaches Survey 2025 found that 43% of UK businesses reported a breach or attack in the previous 12 months. Yet only 14% review cyber risk from their immediate suppliers, and just 7% review their wider supply chain.
For a UK business that builds or resells a product, that gap is a commercial risk as much as a technical one. Enterprise customers, insurers, and regulators increasingly ask for evidence of a security process, and “we’ll get to it” is not an answer that survives a due diligence questionnaire. If you need to close that gap, our risk management and threat modelling services are built for exactly this starting point.
The product security lifecycle
Product security is easiest to understand as a set of activities mapped to the lifecycle of the thing you are building.
Threat modelling and secure design
The cheapest vulnerability to fix is the one designed out before a line of code is written. Threat modelling is the structured process of asking what can go wrong, who would want it to go wrong, and what control prevents it. Done well, it produces a set of security requirements that engineers can build against, and it is dramatically cheaper than patching a flaw in the field.
Secure design also covers the defaults. Insecure design appears as A06 on the OWASP Top 10:2025 for a reason. Products that ship with safe defaults, least-privilege access, and fail-closed behaviour avoid whole categories of incident before they start.
Supply chain and SBOM
You cannot secure what you cannot see. A software bill of materials (SBOM) is an inventory of the components in a product, the dependencies, their versions, and their relationships. It is not a security control in itself, but it is the prerequisite for every other one: when the next widely-used package is compromised, an SBOM tells you in minutes whether you are affected.
The NCSC recommends treating SBOM as one valid format for a dependency inventory, alongside practical controls such as reducing dependency count, deploying through controlled CI/CD rather than developer machines, enforcing MFA on developer and registry accounts, and storing credentials securely. Its supply chain security guidance sets out 12 principles for managing supplier risk.
Vulnerability management and incident reporting
Once a product is in customers’ hands, the work shifts to detection and response. That means a defined route for vulnerabilities to be reported, triaged and fixed, and a published security contact so that researchers, and customers, know where to send findings.
It also means being honest about disclosure. UK organisations handling personal data must report qualifying breaches to the ICO within 72 hours where feasible, and the ICO’s updated guidance leans explicitly towards “report early, update later”. The NCSC’s Software Security Code of Practice encourages manufacturers to publish a vulnerability reporting route and be transparent about how long a product will receive security updates.
UK regulation and frameworks
Product security in the UK is no longer purely voluntary. Depending on what you build and who you sell to, a patchwork of regulation and standards applies.
| model | Who it applies to | What it requires |
|---|---|---|
| PSTI Act 2022 | Manufacturers of consumer connectable products | Bans universal default passwords, requires a vulnerability reporting contact and transparency on security update support periods |
| UK GDPR / DPA 2018 | Any organisation processing personal data | Breach notification to the ICO within 72 hours where feasible; accountability and security-by-design obligations |
| Cyber Essentials | Organisations of all sizes (the UK Government minimum standard) | Five technical controls: firewalls, secure configuration, security update management, user access control, malware protection |
| NCSC supply chain guidance | Buyers and suppliers of technology | 12 principles for supply chain security, including supplier assurance and SBOMs |
| NIS2 / CRA (for exporters) | Organisations selling into the EU | Cyber risk management, incident reporting and product security obligations for in-scope entities |
Two of these deserve more than a table row.
Cyber Essentials is the UK Government’s minimum recommended standard and is increasingly specified in contracts: a growing number of organisations now require suppliers to hold it in order to bid for work. It comes in two levels, Cyber Essentials (self-assessment with independent audit) and Cyber Essentials Plus (which adds technical testing), and certifications start from around £320 plus VAT, priced by organisation size. UK organisations with turnover under £20 million that certify the whole organisation can also access free cyber liability insurance arranged through IASME.
PSTI is the sharp edge for product builders. It places legal duties directly on manufacturers of consumer connectable products, covering default passwords, a vulnerability reporting contact, and transparency about how long security updates will be provided. If you make a connected product sold in the UK, PSTI is now part of your product requirements, not a future consideration.
Meeting these obligations well usually means working to a recognised framework. We support clients across NIS2, CIS and NIST, and a great deal of the effort overlaps with the product security activities described above.
Building a product security programme
You do not need a large team to make meaningful progress. You need a sequence. A workable programme usually looks like this:
- Inventory what you ship. List your products, their owners, their customers, and their support windows. You cannot govern what you have not named.
- Map the dependency graph. Generate an SBOM per product and keep it current. This single step unlocks vulnerability triage, licence management and supply chain response.
- Threat model the high-risk products first. Start with anything that handles personal data, payment data, authentication or safety-critical function.
- Wire security into the pipeline. Static analysis, dependency scanning, secret scanning and secure build steps belong in CI/CD, not in a quarterly review. Our CI/CD security work covers this.
- Define a vulnerability management SLA. Decide how quickly a critical, high, medium and low finding must be fixed, and hold to it.
- Publish a security contact and disclosure route. A
security.txtfile and a monitored inbox are the minimum. Researchers need somewhere to send findings. - Build an incident response plan. Know who decides, who communicates and who notifies the ICO. Rehearse it before you need it.
- Certify the basics. Cyber Essentials gives you an auditable baseline and a credible answer to supplier questionnaires.
Most organisations find that steps 1 and 2 are the hardest, because they expose how little visibility exists over what is actually deployed. That visibility is also the payoff: an SBOM and a dependency inventory turn a supply chain panic into a query.
Common pitfalls
The same mistakes appear again and again when organisations start taking product security seriously.
- Treating ProdSec as a one-off project. A threat model written once and never revisited is a document, not a control. Products change; so do threats.
- Scanning without triaging. A vulnerability scanner that produces 4,000 findings and no decisions has made the problem worse, not better. Prioritisation by exploitability and exposure is the whole game.
- Ignoring the build pipeline. If credentials live on developer laptops and dependencies update automatically, the strongest application code in the world is still one compromised package away from a breach.
- Leaving legal duties to legal. PSTI and UK GDPR obligations have engineering consequences. Someone technical has to own them.
- No disclosure route. Without a published security contact, researchers either give up or go public. Neither outcome is good for you.
Frequently asked questions
Is product security the same as application security? No. Application security is a subset of product security. AppSec covers the application’s code, dependencies, and testing; product security also covers design, supply chain, release, fielded operation, support, and end-of-life.
Do UK businesses have to comply with product security rules? It depends on what you build. If you manufacture consumer connectable products sold in the UK, the PSTI Act imposes legal duties. If you process personal data, UK GDPR and the DPA 2018 apply. Many organisations also face contractual requirements such as Cyber Essentials.
What is an SBOM and do I need one? A software bill of materials is an inventory of the components in your product. You are not universally required to have one today, but it is the fastest way to answer “are we affected?” when a dependency is compromised, and the NCSC recommends it as a valid dependency inventory.
How long does it take to build a product security programme? Most organisations can establish the foundations, inventory, SBOM, threat modelling for critical products and an incident response plan, within a quarter, provided they have engineering buy-in. Maturity takes longer and is continuous.
How much does a data breach cost a UK business? The Cyber Security Breaches Survey 2025 puts the average self-reported cost of the most disruptive breach at £1,600 for businesses, rising to £3,550 when organisations that reported no cost are excluded. IBM’s global average is USD 4.99 million, reflecting the cost of large-scale incidents.
Getting started
Product security is not about buying a tool or passing an audit. It is about knowing what you ship, trusting what you build on, and being able to respond when something goes wrong. The organisations that do this well are not the ones with the biggest security teams, they are the ones that started earlier and built the habits in.
If you build, sell or depend on software products in the UK and want a clear view of where your product security stands, talk to our team. We can help you scope an SBOM and dependency inventory, threat model your highest-risk products, secure your build pipeline, and meet the regulatory obligations that now sit alongside them.