DevSecOps-Pt1

Shifting Security to the Left

Shifting security to the left means moving things closer to the development phase which we used to do in QA or in production phases. Things which we talking here are vulnerability scanning (used to do in production), static and dynamic scanning or interactive scanning (used to do in QA).

Security has to be moved to the left and has to be done and own by the dev teams. So to achieve this they have to have a fundamental understanding of security.

How do they do that?- A security team has to provide a guidance to dev teams on how to do, what type of tests do they need to run, what things they need to fix, what should be priority, what are considered critical or high, what tools to be used and help them understand how to fix the issues. We should also provide a framework that they can work within.

This is security team and DevOps team job to jointly ensure that the application is secure. The DevOps team is responsible for security testing and ensuring that application is secure, however security team is ultimately accountable for it.

Shifting left is great but it doesn’t just means to shift everything on left only. As a DevSecOps, we should shift everywhere, not just left or not just early. Vulnerabilities can be found any part of the SDLC.

Merging Security in DevOps

Let’s look at introducing security into the DevOps cycle to produce DevSecOps. Starting with the planning phase, we should introduce threat modelling and code standards. Then as code is written, we can perform static code analysis (SAST), software composition analysis (SCA) and other types of code analysis techniques. This will identify the vulnerabilities in the code as being written or committed to the code repository.

Once the software is built and ready for testing, we can run vulnerability scan before releasing the software to testers. During the testing phase, we can run penetration testing. During release, we can look at the compliance validation to ensure that the software complies with regulatory or idustry standard.

When we deploy the software, we should sign it cryptographically to ensure the integrity of the software as it’s released. In operate & monitor phase, we can monitor and detect, respond and recover from the security incidents.

Sec merging in DevOps

Overall, DevSecOps is scattering the different processes throughout various phases to encompasses better security, visibility and control.

CICD Pipeline

Pipeline is sequence of steps that occur in sequential order, usually highly automated. There are different components associated with every pipelines like:

1. Source code as one component in the pipeline where all your code management repos will be located. Dev teams will commit and pull code from these repos for modification.
2. Continuous integration pipeline is another component which contains Build, Unit Test & Integration test. Once a code is ready, software will be built, unit tested and certain amount of integration tested.
3. Third components could be continuous deployment pipeline in which deployment takes place once the integration stage passed. There can be multiple different environments including Acceptance, staging & Production env.

Security in CICD Pipelines

Let’s now fit the security in above mentioned different pipelines.

1. Design review before the code is written
2. Code review once the code is written, this should be automated review
3. Integrate security testing during testing phase as part of CI pipeline
4. Secure deployment should be done during deployment by using automation technique to ensure all the environments that are being deployed to are securely configured.

Security becomes embedded in the pipeline is no longer an afterthought, although it is a repeatable, consistent and embedded approach.

Where DevSecOps is appropriate?

There is not hard and fast rule to say where to apply DevSecOps and where you can’t. However, DevSecOps implementation will be very suitable in cases like:

1. If you have agile methodology.
2. If you have an existing DevOps in place.
3. If you are having multiple releases per year, per day or per hour.
4. If you have some automation already in place in your deployment lifecycle, then you can plug some of the DevSecOps controls into this pipeline.

DevSecOps might not be suitable in cases like:

1. If You are using a different type of structure and using a waterfall methodology.
2. If you work in a highly regulated environment that requires significant changes or approvals to any improvements or variation on the SDLC
3. If you are doing one or two releases per year
4. If you have no automation in your current environment.