Security in our Process
Our aim is to make our products as secure as possible while maintaining usability for end users. This is in line with the GDS service standard. You should be aware of the MOJ Security Guidance, which will help with specific policy issues at an MOJ level and follow the National Cyber Security Centre for updates at a government level.
As part of our local development culture all our products should aim to have the following as a minimum in their process, build pipelines and GitHub setup:
- Security to be considered as part of ticket prep and refinement, with reference to OWASP Top 10.
- Write automated tests to verify code and infrastructure security
- Do Threat Modelling of your product every 6 months
- Have an ITHC or Pen Test once a year or after a major change
- Enable dependabot security updates on all repositories
- Enable container vulnerability scanning (either ECS container scan or a tool like Trivy)
- Require pull requests to be reviewed before changes are merged to the main branch
- Enable Pre-commit hooks to prevent secrets being added to version control
- Static analysis of code run in IDEs, pre-commit and pipelines (using the appropriate tooling for the languages used).
- Maintain Architectural Decision Records of security related decisions
You may also want to look at:
- Adding a pull request template with expectations for checks specific to your product
General principles
- We will automate as much as we can
- We will build security into the process, rather than tag it on via external checks
- We will actively fix, and where issues occur improve the process to prevent them happening again
Asking for help/Raising issues to security
Sometimes you need to make a call between a security fix and a business or user requirement. Or you may not know the best way to handle or fix a security issue in your code base.
Where you are unsure of how to proceed, you can get advice from the Security team. To contact them you can either
- Post a message in their slack channel #security
- Email their inbox at security@justice.gov.uk
- Raise a security concern via their google form
What to include
If possible, supply them with as much context in regard to the issue.
- CVE (if available)
- OS/Environment
- Description of issue
- Any business context
- Any recorded conversations around the security issue
- What data could be comprimised if attacked
If a security issue cannot be fixed, then Security will add it to their risk register with the details provided. This is to ensure MoJ have visibility of all threats and weaknesses across their estate.
Responsibilities
As a Developer or WebOps Engineer you should
- Be aware of common vulnerabilities and how to code to prevent them
- Pair with colleagues to be a 2nd pair of eyes for potential security issues
- Raise security concerns if you identify a risk (chance that something might happen) or issue (something has happened).
- Use the incident process for urgent issues
- Actively build an understanding of the security posture of your product over time
- Actively monitor your product for security issues
As a Technical Architect you should
- Organise regular threat modelling for your teams
- Ensure security tickets are prioritised in backlogs
- Coordinate incidents if they occur
- Liase with stakeholders and security around security issues
- Highlight potential risks on product and OPG Digital Risk registers