Wouldn’t it be great to not worry about compliance?
While it’s possible to argue that automation can be taken too far, one area where I’m sure many people would appreciate more automation is around compliance.
I recently had a great experience working for a client, where the team was sent a list of items that auditors would be focusing on for the next audit. I know, I know, how could that be a great experience?
Because we didn’t have to do anything!
The automated CI/CD pipeline and team practices that we had developed met all of the assessment criteria that were listed.
Further, if the team was audited and asked to provide evidence we followed the process, we could show logs generated by the automated pipelines and other services.
HOW AUTOMATION WON THE DAY
Here’s a list of the criteria (paraphrased slightly) and an explanation of how we were able to meet them using the automated deployment pipeline and team practices developed by the team:
1. ENFORCING A PEER REVIEW PROCESS IN APPLICATION DEVELOPMENT PHASE.
The development workflow of the team ensures that no code can be committed directly to the master branch. All code must be written in a feature branch, then a pull request created. The pull request must be approved by a different member of the team to the person that raised the request.
2. ENABLING STATIC CODE AND ARTEFACT SCANNING TO LOOK FOR POTENTIALLY EXPLOITABLE VULNERABILITIES.
The team currently has two different static analysis tools incorporated into their pipeline:
a. PyLint – https://www.pylint.org/
b. GitSecrets – https://github.com/awslabs/git-secrets
These analysis tools run as part of CI/CD pipeline. If problems are detected, the build will break.
3. RESTRICT DEPLOYMENT PRIVILEGES FOR CONTROLLED ENVIRONMENTS.
All of the teams software exists in AWS and hence deployment privileges are controlled though the use of AWS roles.
All deployments are conducted using the CI/CD pipeline, no manual deployments occur. The teams CI/CD tools are given the appropriate access to accounts they must deploy to.
All configuration has been stored as code, so manual configuration of controlled environments never occurs.
4. REGRESSION TESTS SHOULD BE CREATED AND MAINTAINED BY THE PLATFORM TEAM TO DETECT BREAKING CHANGES IN THE LOWER DEV AND TEST ENVIRONMENTS.
As part of the teams CI/CD pipeline, regression testing of all merges to master occurs automatically before they are deployed. The procedure:
- Merging code to master first triggers unit tests.
- If all of the unit tests pass, the application is deployed to a staging environment.
- In the staging environment, both functional and integration tests are run.
- If the all the tests have passed, then the application is deployed to production.
5. VALID CHANGE RECORDS HAVE BEEN RAISED AND APPROVED FOR DEPLOYING TO CONTROLLED ENVIRONMENTS.
The team uses JIRA to track all work done on applications.
As the team treats configuration as code, our source control systems provide an audit trail of all changes that are done to environments.
6. DEPLOYED ARTEFACTS MUST BE BUILT FROM CODE THAT HAS BEEN PEER REVIEWED AND MERGED TO MASTER/RELEASE BRANCH.
All team deployments are done as part of the CI/CD pipeline. For code to be merged to master, it must have been reviewed by another team member though a pull request. Therefore all deployments to production must have been peer reviewed.
