The UK’s National Cyber Security Centre (NCSC) recently released a new Software Security Code of Practice. It’s technically optional, but it shows where things are heading in terms of secure development.
Writing secure code is definitely part of it, but it also covers how software is designed, built, deployed, and maintained, pushing for security throughout the entire software development lifecycle (SDLC).
Here’s a closer look at what’s in the Code and how SecureFlag can help teams put it into practice.
The Code looks at typical weak spots that attackers target, such as outdated libraries or insecure deployment setups. It’s not just about stopping attacks, though, but also building trust between developers and the users of their software.
One of the main goals of the Code is to get all stakeholders to collaborate on security. When developers, managers, and third parties all understand what is expected and work more effectively together, it helps reduce duplicated effort and makes the software supply chain more secure.
The NCSC worked closely with developers, industry experts, and researchers, then opened the Code up for public feedback. They adjusted the framework based on real-world input, making it feel much more practical and developer-friendly.
The Code outlines 14 principles organized under four main themes:
Secure Design and Development
Build Environment Security
Secure Deployment and Maintenance
Communication with Customers
We’ll focus on the first theme.
Good security engineering involves designing and developing software that is resilient, even when facing attacks. To get there, security needs to be built in from the start.
Following secure coding best practices, using reliable tools, and having proper processes in place all help reduce both the risk of introducing vulnerabilities and the impact if something does go wrong.
The reality is that most developers aren’t security experts, and many of the tools out there can be more confusing than helpful. What makes a difference is the right support, such as access to expert guidance, practical training, or developer-friendly tools that make secure coding easier.
An effective way to embed security into workflows is to follow a secure development framework. It provides structure and consistency across teams, making sure security is considered throughout the lifecycle, not just at release time.
A good framework will typically cover:
Threat modeling: Identifying potential risks early on.
Security requirements: Defining what needs protecting and how.
Secure coding practices: Preventing flaws like SQL injection or XSS.
Testing: Verifying security in every release, including patches and updates.
Data and configuration management: Knowing what the software handles and how it’s managed.
Choosing the right framework is a business call, but it also needs to work with how your team builds software. There are plenty of options out there, so it’s worth finding one that fits your workflows and culture.
One example is RaD-TM (Rapid Developer-Driven Threat Modeling), a developer-friendly approach that brings threat modeling into everyday development, with no need for a dedicated security team to get started.
Cyber attacks targeting the software supply chain have surged recently, causing costly and long-lasting damage to organizations and their customers. Since most software depends on third-party libraries and suppliers, these dependencies can introduce hidden vulnerabilities at any stage.
Dependency chains aren’t just third-party libraries; they include your internal code and all the packages you rely on, directly or indirectly. If any part is vulnerable or compromised, attackers can use it as a way in.
That’s why it’s so important to keep track of every component in your stack. Knowing what you’re working with makes it easier to spot vulnerabilities and react faster if something goes wrong.
Regular testing throughout development ensures code works as intended and stays secure. It helps catch vulnerabilities early before software is released.
Important points to follow:
Test all parts: Cover both individual components and the complete software. Ensure security and functional requirements are met, with baseline code coverage before adding new code.
Document and improve: Record test results, fix issues, update tests regularly, and add tests for new security flaws. Adjust tests if false positives are frequent.
Test often: Automate tests to save time and focus expert effort on complex issues.
Use multiple methods: Combine automated static and dynamic analysis, peer reviews, unit and integration tests, and manual assessments, such as penetration testing, to catch all types of issues.
‘Secure by design’ refers to integrating security from the very start of development through to deployment, creating stronger, more resilient software.
For secure software, teams should:
Use threat modelling early on to anticipate and address potential attacks.
Enforce strong authentication, such as phishing-resistant multi-factor authentication (MFA) for privileged users, making it easy to set up and the default option.
Change default passwords during setup, following best practices to ensure strong credentials.
Validate all input carefully to prevent injection and other common attacks. Use prepared statements, enforce strict syntax, and check value ranges.
Avoid hard-coded credentials and securely store all sensitive information like passwords, certificates, and API keys.
Encrypt sensitive data at rest and in transit to protect against unauthorized access.
The Code makes it clear that open source projects aren’t the main target here, as most of them aren’t commercial offerings with formal support.
That said, if development teams are using open source (who isn’t these days?), the responsibility is on them to manage those risks. Validate the components used, regularly update them, and ensure that what is deployed is trustworthy.
Just because a package is free to use doesn’t mean it’s free of risk.
As you know, modern software isn’t built in isolation, but it’s part of a complex system comprising APIs, services, and integrations. One weak link can expose a whole chain.
The NCSC’s Code helps build stronger foundations, promoting secure design, clearer visibility, and lasting resilience. It emphasizes building security from the start, instead of patching things later and hoping for the best.
For developers, this means less firefighting in the code that’s deployed.
Guidance is always great, but developers need to know how to apply it correctly.
The SecureFlag platform provides development teams with hands-on secure coding training to build security skills in the tools and environments they use day-to-day.
Teams get to practice secure coding, manage third-party risks, and apply the kind of principles covered in the NCSC’s Code, without waiting for a vulnerability to hit production.
And with ThreatCanvas, teams can model threats early and continuously, helping organizations stay proactive about risk throughout the entire SDLC.