Blog post

Secure development and deployment

Created:  22 Sep 2017
Updated:  22 Sep 2017
Author:  Toby W
Secure development and deployment

Today we are pleased to share with you an alpha draft of our secure development and deployment guidance. You may be wondering, 'who this is aimed at?' And 'why is it in alpha?' This blog post will answer those questions.

Increased automation

We have noticed the steady growth of agile development using continuous integration and delivery. You probably have too. Well, one of the chief characteristics of this relatively new approach to software development is increased automation. This puts incredible power in the hands of the developer, allowing entire system architectures to be defined in code and tied to tooling which will automate both testing and deployment. There's a lot going for this approach, you can see why it's catching on so fast.

But (there is always a 'but') with this power comes a new set of risks and security considerations. It's these which our guidance addresses. We've tried to ensure that every recommendation is possible. And though there might be some pain were you to adopt our advice wholesale, now is the time to make the effort - before insecure practices have had time to take root culturally. 


The primary audience for this guidance is development teams practicing continuous integration and deployment, an approach which is more common for the development of digital services. Despite this, we hope the advice we give will be of use to everyone involved in software development and procurement, whatever your style of development.

That's quite ambitious - 'everyone.' But the guidance itself is high level: there is no language-specific advice. It's human readable. Our goal is to help secure the entire process of software development, so we've looked at everything from establishing a security-friendly culture, through to implementation and ongoing management. This work is complementary to our existing design guidance.

Github first

We are publishing this guidance as alpha, acknowledging that we are dealing with a new and rapidly evolving field - one in which there are still questions to be settled about best practice. We welcome your feedback to help us refine our advice, before moving it to 'beta' and 'live' versions. 

And, due to the nature of the guidance, it seemed appropriate to share this with you on Github first. We welcome your feedback through comments and pull requests. Once the alpha period is completed, we'll integrate the suggestions we receive and publish a beta on our website. 


David - 04 Oct 2017
This says nothing and says it in poor English and management speak. Git Hub indeed.
Ben - 05 Oct 2017
I thought it was quite clear. It is good to see a modern, risk-based approach to security being discussed by people who know what they are talking about.

What in particular did you find so disappointing?
Rory Alsop - 16 Oct 2017
David - the good thing about GitHub is if you can see areas for improvement, you can write the improvement yourself. And it is pre-beta, so the expectation is that the community will pitch in. I have started adding my pull requests today for some changes - nothing major, but some hopefully helpful additions.
At this level it needs to be in English that anyone can understand, and you'll see links to lower level guidance for techies, sec folks etc.
Philip Sargent - 16 Oct 2017
Very good and impressively competent and restrained.
Excellent further detail on the github link too.
Nick C - 19 Oct 2017
Item 4 'secure your development environment' and Item 6 'secure the build and deployment pipeline' are exactly the same. Copy and paste error? Please can you update information about securing the build and deployment pipelines to make the relevant. Otherwise a good starting point for an 'alpha'.
NCSC Communications Team - 29 Aug 2018
This blog is now closed to comments.

Was this blog post helpful?

We need your feedback to improve this content.

Yes No