NCSC Software Security Code: a good start

Chris Wood at Immersive argues that organisations should adopt the NCSC’s Software Security Code of Practice, but that it’s only a first step

 

After many years of being seen as a ‘nice to have,’ secure coding is becoming a ‘must-have’ on the cyber-security agenda. There’s growing recognition that prioritising secure development is critical for organisations creating and relying on software applications.

 

The recent unveiling of the NCSC’s Software Security Code of Practice is a positive indicator of changing attitudes. By laying out 14 core principles, the code sets a clear, secure-by-design baseline for every stage of the development lifecycle. 

 

Yet there’s still work to be done. The Code takes a very good first step toward building a truly secure UK software ecosystem. However, it’s voluntary, not mandated. Making secure coding a universal baseline should be the goal. 

 

Security leaders need to push their developers to treat the NCSC’s Code of Practice as a foundation for secure coding practices, a baseline to build from. Let’s explore the most important points leaders should focus on.

 

The promise of secure-by-design

The Software Security Code of Practice distills best practices into 14 principles, covering everything from upfront threat modelling and secure requirements to build-environment controls and robust patching processes. 

 

This is the NCSC’s first big push in telling development teams to follow a specific code of practice. Embedding security early into the development cycle reduces the most common vulnerabilities and establishes market-wide trust in UK software. 

 

The framework’s voluntary nature is a double-edged sword. On one side, it provides flexibility that may encourage forward-thinking organisations to innovate rather than merely comply. 

 

Those who recognise the long-term value that secure coding provides across their operations can use the guidelines as a framework to actively invest in essential secure coding practices. Doing so will also build trust with stakeholders.

 

However, without clear incentives, some teams may treat application security as a “tick-box” exercise, either doing the bare minimum or safely ignoring the need for secure coding practices, with no consequences. We see time and time again that companies delay or disengage with secure practices. If too many opt out, the wider software ecosystem remains vulnerable. 

 

To achieve a genuinely resilient ecosystem, leaders must approach secure-by-design not as a burdensome extra, but as an opportunity. By demonstrating their security maturity, they will work ‘smarter not harder’, gaining predictability and delivery speed, reassuring customers, and outpacing competitors

 

By championing these principles at board level and across development squads, businesses can turn the Code’s promise into a practical, organisation-wide ethos.

 

Hidden complexity of software ecosystems 

One reason guidelines like the NCSC Code of Practice are so valuable is that individual apps and IT ecosystems have become dense and convoluted. 

 

Every enterprise environment I’ve audited resembles a platypus. Just as this odd creature is a hodgepodge of mammals, amphibians, birds, and reptiles, applications end up combining seemingly random elements. Bits of functionality and fixes are bolted together without a clear blueprint. The result is a messy, overly complicated ecosystem where no one quite knows how everything connects.

 

Two common issues allow this kind of complexity to creep in. First, when developers are under intense time pressure, they end up prioritising product release over security considerations. This means skipping key initial steps, such as early threat modelling, leading to shaky foundations with hidden attack paths deeply ingrained in the code. 

 

Secondly, over time, legacy code often gets handed between teams who lack the original context; attempted quick fixes introduce fresh flaws. The result is an increasingly deep bundle of spaghetti code, which is highly prone to vulnerabilities and breakages. 

 

 Threat modelling and secure design can’t be one-off tasks. Even if you check most boxes on the NCSC’s checklist, there’s a risk you’ll ship fragile software. Developers must address blind spots. 

 

Applications are complex, evolving, and sometimes unwieldy. Understanding that reality is the first step toward applying the Code’s principles to tame that complexity and strengthen your overall security posture.

 

Beyond checklists with a people-first approach

Code complexity can only be handled properly if security is a constant presence, rather than a checkpoint. Static compliance can only take you so far - security needs to be ingrained in both development culture and processes throughout the lifecycle.  

 

We need continuous validation with always-on testing of both technical systems and human processes rather than a one-and-done audit. Red-team exercises and targeted bug bounties mapped to the code’s 14 principles should be regular fixtures, surfacing gaps before they become crises.

 

Equally crucial is a people-first security culture. While automation is essential, keeping experienced humans in the loop remains the best defence. Tools alone miss subtle, emerging flaws. That means leaders must equip developers, operations teams, and other stakeholders with the context and skills to spot, escalate, and prioritise risks. 

 

Inevitably, when the pressure is on, theoretical knowledge falls short. Stakeholders now ask, “Can you prove they work in practice?” not just “Do you have security controls?” Real proof comes from practical, hands-on training in the tools your team is used to working with daily. 

 

Developers and security teams alike need the opportunity to work with real code to identify, understand, and address security risks in a safe environment where the company’s fate isn’t at stake. 

 

Contextual, scenario-based exercises are the best way to build his familiarity. Developers write code every day, so they’re the ones who will make mistakes. But if they don’t know about something, they can’t spot it. They need the chance to learn by doing, not just reading theory. 

 

Although they aren’t responsible for identifying and containing breaches themselves, it’s also helpful to bring development teams into full-scale crisis simulations. A post-breach developer sprint gives teams requisite experience, scrambling to triage and patch under pressure, building experience and muscle memory that is invaluable when a real crisis occurs. 

 

To measure progress, organisations should track metrics such as time-to-detect, mean-time-to-remediate and the percentage of teams passing red-team tests. Sharing these resilience indicators with boards, regulators, and customers transforms security from a checkbox into a competitive differentiator. When you can point to hard data, you move from theoretical compliance to demonstrable readiness.

 

From theoretical code to demonstrable resilience

Organisations often stall on voluntary standards until there’s a hard requirement. Many companies didn’t bother with Cyber Essentials until it was tied to winning public sector contracts, for example.

 

Leaders must link secure-by-design commitments to procurement and board-level KPIs. This means you must tailor training to real development workflows and make security metrics as visible as performance dashboards. Every stakeholder must know their benchmark in order to improve and be ready to combat threats on the front lines.

 

Today, the Software Security Code of Practice gives us a powerful baseline. But it shouldn’t be treated as the finish line. True cyber-resilience demands continuous, people-centric validation and hands-on readiness. 

 

---

 

Chris Wood is Principal Application Security SME at Immersive 

 

Main image courtesy of iStockPhoto.com and Moment Makers Group