DevSecOps Beginners Guide: How to Secure your DevOps Pipelines?

Simran Malhotra -

The transit to DevOps Security requires everyone’s involvement right from the top management to the developers, testers and the operations team. It starts from the moment you write the very first line of code and continues even after deployment to production, with the aim to make malicious attacks difficult, exquisitely impossible.

DevOps Security i.e. DevSecOps focuses on initiating a culture of security in the DevOps environment. It is a collaboration of the DevOps teams with system security personnel, where the end goal is to find a faster and more robust way to deliver the code safely in agile architecture.

Integrating security into CI/CD pipelines

Security means thousands of things and while trying to accommodate it in DevOps pipeline one can easily deviate and get overwhelmed! There should be a thorough understanding of the workflows and tools the team is using to put effective security checks and controls on pipelines.

Typically we can decouple our continuous integration, delivery and deployment pipelines into 6 main stages:

Dev: Development phase, before the source code lands into the repository.

Build: Building and performing basic automated testing of the system.

Test: After a successful build, the artifacts are deployed into staging and test environments.

Host: This stage involves the configuration or updates need to be applied to the infrastructure.

Run: If all green, one can deploy the application into the production environment.

Observe: Continuously measuring and monitoring production activity.

Now, one by one we will be discussing the ways in which we can infuse security in each of the six activities listed above. Let’s dig in.

Stage 1: Dev

DevOps practices put emphasis on writing clean and understandable code. The aim of DevSecOps is to boost these practices by adding checks for writing clean & secure code.

Practices like static code analysis and code reviews can be extended to integrate security from the very beginning, without impacting the productivity of developers. Common security issues can be fixed before any code commit.

Code reviews: Code review is very beneficiary as it can enhance security. It increases transparency among development teams which minimize the risks of internal threats and help in improving the code quality.

Stage 2: Build

After the source code is committed to the repository, the build and basic automated testing of the application is done. Critical security issues can be detected by adding security checks at this stage. The build should fail and send alert notifications if any serious problem is found.

  • SAST: SAST analyzes an application source code to determine if security vulnerabilities exist. It looks at the application ‘from the inside-out’, without needing to actually compile the code. Hidden bugs, that might be hard to find through other kinds of testing can be found easily this way.
  • Unit tests: UTs are important in catching regressions. Adding unit security tests to functions is something worth investing in.

Stage 3: Test

Soon after a successful build, the test stage is triggered by picking the generated artifacts and is deployed at the staging and testing environments. SAST, DAST, integration, and performance tests are executed in this stage.

This stage takes more time and resources to execute, therefore adopting the fail fast approach can be beneficiary! The more expensive and time-consuming tests are put on hold until the other tests are already passed.

  • Targeted dynamic scanning: Dynamic Application Security Testing (DAST) comes into play after deployment to find if the application is exposed to attacks such as cross-site scripting or SQL injection.
  • Fuzz testing: Fuzzing is a Black Box, brute-force reliability testing technique, which basically consists of finding implementation bugs using data injection in an automated fashion.

Stage 4: Host

Many tools over the years of development help in making infrastructure more resilient. Securing the runtime environment is as important as securing the application running on top of it.

  • Least Privilege: The PoLP states that every module must be able to access only the information and resources that are necessary for its legitimate purpose.
  • Configuration Automation: Configuration management tools make it easy to provide secure infrastructure repeatedly.

Stage 5: Run

After the successful implementation of the first four stages, we’re now ready to go to production. The goal here is to gain the assurity, designing the system resistant to attacks by avoiding any loopholes during configuration that can make the system less reliable and resilient.

Stage 6: Observe

Even after the systems are in production, security doesn’t end. There should be automated security checks and continuous monitoring feedback loops are essential for production operations.

We can gain insights into the traffic an application is receiving and helps spot the pattern of malicious users through continuous monitoring.

  • Security Monitoring: It starts by automating the process of collecting and analyzing indicators of potential security threats, define which types of behavior should trigger alerts, and take serious action on alerts.

Final words

Organizations wanting to remain relevant and competitive in the industry must consider DevOps security as their primary goal in 2019. You can use these as pointers to start your journey towards DevSecOps.