ukncsc/secure-development-and-deployment

NCSC Guidance for secure development and deployment

secure-development-and-deployment's Issues

Individuals peer reviewing their own code

I disagree that

individuals can also peer review their own code

If I am attempting to peer review my own code, then I have simply not finished writing and testing my code.

Coding in the open

5-protect-your-code-repository.md:
"Limit exposure & access to your repository
Technically enforce a model of least privilege for who can read and make changes to your code repository. Only permitted individuals should be able to view and make changes, and all activity should be attributable. For some use cases, it may be appropriate to 'code in the open', but consider the impacts first."

The paragraph above can be summarised into "code in private by default and open when appropriate". It is a radically different spirit than "code in open and close when appropriate" that has been recommended for years by GDS. See articles below.

As a consumer of these two clashing recommendations, I'm confused and it will make my stakeholders even more confused and choose the NCSC recommendation by default.

GDS - Coding in the open
https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/

GDS - The benefits of coding in the open
https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/

GDS - Coding in the open makes better code
https://gdstechnology.blog.gov.uk/2017/07/18/coding-in-the-open-makes-better-code/

MOJ Digital & Technology - Why we code in the open
https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the-open/

Sections 4 and 6 could be merged?

They are very similar, and to be honest developer machines are effectively a component in the development pipeline anyway (though they are more distributed).

Secure development

Is there an argument to expand [1] to include things like:

• the use of threat modelling to identify risks and to align with the concept of continuous risk management.
• getting devs to do security is better than asking security people to do development - so create networks of security champions.

Ability to react to compromise and/or vulnerability

While this guidance is explicitly targeted to teams practising continuous delivery, it might be worth noting (maybe in section 8), that you should be able to fix and deploy quickly.

There is no point identifying a problem quickly if it takes you 6 months to get a fix out to Prod.