Setting up Secure SDLC Processes for a Pension Application

Team processes

• All architectural solutions and technology decisions included threat modelling using standard techniques
• All code developed by the team was peer-reviewed by a colleague before it was merged into a feature branch, with peer reviews (or Pull Requests) documented in Gitlab. The peer review process was performed against documented security guidelines.
• All team members reviewed relevant security and compliance policies prior to developing code. This review was tracked and documented in JIRA tasks.
• All services developed by the team were subject to GDPR regulations.
• Development teams proactively seeked reviews and support from security specialists and architects, early in the solution design or development cycle, aiming to "shift left" the identification of any issue, and therefore increase the likelihood and lower the cost of its resolution.

Technology controls

• All code commits were subjects to static analysis with a focus on security
• (e.g. Sonarqube, FindBugs, FindSecBugs).
• The continuous integration processes included dependency checking, to validate project dependencies and to check for known, publicly disclosed vulnerabilities (OWASP A9).  OWASP Dependency Check, Lighthouse, snyk.io and retire.js were used.
• The continuous integration processes includes dynamic security checking (DAST) with security scanners to help automatically identify vulnerabilities, such as OWASP Zed Attack Proxy and Arachni.
• AWS infrastructure was used to host all the services developed by the team. Ensuring the cloud security was done by corresponding embedded AWS tools (e.g. WAF, IAM, CloudTrail, CloudFront, Security Groups).
• All applications hosted externally were integrated with the IBM QRadar SIEM solution, and other group-wide network controls.