Security is no longer only a question for the IT team after software has been bought, configured and connected to the rest of the business. The UK government is now spelling out what should reasonably be expected from organisations that develop, sell or distribute software to other businesses.
The Software Security Code of Practice is voluntary, but it is still worth paying attention to. It gives software suppliers a practical baseline for secure development, secure build environments, vulnerability handling and customer communication. It also gives customers a clearer way to ask better questions when buying SaaS, ERP extensions, website platforms, portals, integrations, apps or software-enabled products.
For most small businesses, this is not about creating a heavyweight compliance programme. It is about making software risk visible before it becomes an incident, a broken update, a supplier dispute or an urgent customer assurance request.
What The Code Is Trying To Fix
Modern businesses rely on a stack of software they do not fully control. A typical small or medium-sized firm may depend on a website CMS, hosting account, CRM, payment system, accounting platform, ERP system, booking tool, email service, remote access tool, cloud storage, analytics scripts and several integrations between them.
That stack creates a simple problem: the customer carries much of the operational risk, but the supplier often controls the code, update process, vulnerability response and support lifetime. When those responsibilities are vague, security gaps are easy to miss.
GOV.UK says the Code was developed to reduce the likelihood and impact of software supply-chain attacks and resilience incidents. It was co-designed with the National Cyber Security Centre and includes 14 principles split across four themes. The government also says the principles are intended to be fundamental and achievable for organisations of any size, type or sector.
The NCSC’s overview of the Software Security Code of Practice describes it as a way to define a market baseline for cyber security. In plain English: software security should be built into the product and the supplier relationship, not sold as a confusing optional extra after the contract is signed.
Who Should Pay Attention?
The Code is most relevant to business-to-business proprietary software, but the boundary is wider than many people expect. It can apply to firms that develop and sell software, SaaS providers, vendors of products with software inside them, managed service providers that distribute software, and organisations building software components into a wider customer offer.
That matters for Bloom’s audience because many small firms are not pure software companies, but still ship or depend on software in practical ways. Examples include:
- a manufacturer providing a connected machine dashboard or customer portal;
- an industrial supplier offering remote monitoring or reporting software;
- a service business commissioning a bespoke booking or membership platform;
- a SaaS company selling a specialist workflow tool to other businesses;
- an ERP partner building integrations, reports, extensions or middleware;
- a web agency or developer maintaining business-critical websites and plugins.
Customers should pay attention too. GOV.UK is explicit that organisations procuring software can use the Code to inform supplier negotiations, agreements and contracts. That is useful because most small-business software procurement still focuses heavily on features, price and implementation timescale, with security questions arriving late or not at all.
The Four Themes In Practical Terms
The Code groups its 14 principles into four themes. The wording matters less than the operational habit behind each one.
Secure Design And Development
Suppliers should follow an established secure development framework, understand third-party components, test software before release, and follow secure-by-design and secure-by-default principles. For a small supplier, this does not have to mean a large security department. It can start with documented development standards, threat modelling for sensitive features, code review, dependency checks, sensible permission defaults and repeatable release testing.
This aligns with the broader approach in NIST’s Secure Software Development Framework, which recommends practices that can be added to different software development lifecycle models. The useful point for customers is that secure development should be a visible process, not a vague promise that the supplier “takes security seriously”.
Build Environment Security
The build environment is where code is assembled, packaged and prepared for release. If that environment is compromised, an attacker may be able to insert malicious code into otherwise trusted software. The Code expects suppliers to protect the build environment against unauthorised access and to control and log changes.
For smaller development teams, this is often one of the most important areas to tighten. Repository access, deployment credentials, CI/CD systems, package publishing accounts, admin laptops and shared secrets all need proper control. Multi-factor authentication, separate production credentials, limited access, build logs and careful handling of automation tokens are not glamorous, but they prevent a lot of avoidable risk.
Secure Deployment And Maintenance
Software security does not end on launch day. The Code expects secure distribution, vulnerability disclosure, proactive vulnerability management, appropriate reporting and timely security updates. For customers, this is where contract wording and day-to-day support need to match reality.
A supplier should be able to explain how updates are delivered, how quickly serious vulnerabilities are handled, how customers are notified, and how external researchers or customers can report a weakness. If the answer depends on emailing one busy developer or waiting for the next general feature release, the process probably needs work.
Communication With Customers
The final theme is easy to underestimate. Suppliers should tell customers what support and maintenance they receive, give at least one year’s notice when software will no longer be supported or maintained, and make information available about notable incidents that may significantly affect customers.
This is especially relevant for websites, plugins, industrial systems and ERP add-ons that quietly become business-critical. Unsupported software often remains in production because nobody owns the replacement decision. Clear end-of-support dates, maintenance terms and incident communication reduce that drift.
What This Means For Small Software Suppliers
If you develop or sell software, the Code is a useful checklist for credibility. It can help you answer the questions customers are increasingly asking about security, especially when they are in regulated sectors, manufacturing supply chains or larger procurement processes.
The first useful step is to appoint a clear owner. GOV.UK says a Senior Responsible Owner should be appointed at senior leadership level to hold accountability for the principles being followed. In a small firm, that might be the founder, managing director, technical lead or operations lead. The point is not the job title; it is that somebody has authority to make security part of delivery, support and customer communication.
After that, focus on evidence. A supplier does not need to produce a glossy security pack on day one. It does need to know what it can show a customer if asked.
- Which secure development framework or internal standard do you follow?
- How do you review third-party libraries, plugins, packages and services?
- Who can access source code, build systems and production environments?
- How are secrets, API keys and deployment credentials stored?
- How are updates tested before release?
- Where can someone report a vulnerability?
- What support lifetime do customers receive?
- How would customers be notified about a serious incident?
NCSC’s implementation guidance for the Software Security Code of Practice is designed to help vendors turn the principles into practical evidence. For small teams, that is the right place to start because it keeps the work tied to outcomes rather than paperwork for its own sake.
What This Means When Buying Software
For customers, the Code gives a better way to compare suppliers than asking broad questions such as “is the system secure?” A better question is one the supplier can answer with a process, document, setting or example.
Useful procurement questions include:
- How do you manage third-party components? Ask about open-source libraries, plugins, packages, embedded services and update responsibility.
- How are updates delivered? Check whether security fixes are automatic, manual, chargeable, tested or dependent on a wider upgrade project.
- What happens if a vulnerability is found? Look for a clear disclosure route, triage process, customer notification process and patch timeline.
- Who can access our data or environment? Ask about administrator access, support access, logging, least privilege and offboarding.
- What evidence can you share? This might include a self-assessment, penetration test summary, development policy, incident process, Cyber Essentials certificate or relevant assurance report.
- How long will this product be supported? Check support dates for the platform, plugins, integrations, operating systems and hardware where relevant.
- What is not included? Many incidents begin in the gap between supplier responsibility and customer responsibility.
These questions are particularly important when the software will connect to payments, customer accounts, operational data, machinery, internal documents, single sign-on, ERP, finance systems or production workflows. The more connected the system, the less sensible it is to treat security as a final box-tick.
Do Not Turn This Into A Paper Exercise
The risk with any code of practice is that it becomes a folder of documents nobody reads. That would miss the point. The useful version is operational: improve how software is built, updated, supported and explained to customers.
For a small supplier, a good first month might involve tightening repository access, documenting the update process, adding dependency scanning, writing a short vulnerability disclosure page, reviewing admin accounts and clarifying support terms. For a customer, it might involve adding seven security questions to supplier selection and checking whether existing critical systems have a known owner and support date.
The Code is voluntary today, but it is part of a wider movement. UK policy, NCSC guidance, international secure-by-design work, the EU Cyber Resilience Act and customer procurement expectations are all pushing in the same direction: software suppliers need to be able to show how they manage security across the product lifecycle.
The Bottom Line
The Software Security Code of Practice is not only for large vendors. It gives small software suppliers a practical way to build trust, and it gives customers a clearer way to buy software without relying on vague assurances.
The sensible response is to start small and be specific. Know who owns software security, protect the build and deployment process, keep track of third-party components, publish a way to report vulnerabilities, and tell customers clearly what support they can expect. Those steps are useful whether or not a customer ever asks about the Code by name.