DevSecOps — What’s it all about? Part 2
In this part we will incorporate security controls in our DevOps Lifecycle. Disclosure — I won’t be explaining installation and all the configuration of each and every tool. I would highlight some important configurations that i did to setup the tool. The idea is to explain the concept and not the technical specifics as they may differ from environment to environment. Also this is not a definitive guide to all the tools and they may vary based on your requirements and environment.
Let’s have a look at how the architecture looks currently —
Generally the DevOps cycle starts after the developers push their code into SCM. However we will try to secure our code even before that i.e. when the code resides at the developer machine. There are Various measures that can help in securing the code.
Security at Developer’s Workstation
At developers end we can use following measures -
1. IDE extensions: IDE or editor extensions can be very helpful in early detection of security flaws. These extensions provide functionality like Static Code Analysis, Secrets Tracking, etc.
2. GIT hooks: Git hooks provide applying certain rules to various stage like pre-commit, pre-push, etc. They can help detect common errors in the code.
I’m using VS Code for development. In my code i have kept some secrets purposefully (or i may have forgotten to remove them ;) ). I searched for some extensions that perform SCA and secrets tracking. I found a great extension HCL AppScan CodeSweep that does the same and much more. So i installed it and it immediately detected my secrets and security flaws —
Another aspect of SCA is the packages and libraries that you use. Their security is also crucial to your application’s security. Vuln Cost is an extension that provides security scanning of the third party libraries that you use in your code.
There are also many proprietary extensions that provide you all the features in a single place. Most of SCA tools that you may use to centrally, provide IDE extensions to directly scan the code at developer end before they push it into the SCM.
Now to setup git hooks, i used Talisman which adds a git hook to prevent secrets from getting checked in and it worked like a charm. You can also add many other hooks according to your need.
We are talking so much about preventing the secrets getting into the source code but what about when it gets pushed ? Any secret that gets pushed into source code should be considered as compromised and be revoked and rotated immediately. Even if we delete the secret from our repository files the secrete still remains in the commit history. You may want to remove all the traces of the secret from the history even if the secret is expired to prevent attackers from gaining insights about patterns (which ideally should not be there) in your secrets. One of my favorite tool to achieve this is — BFG. It cleans all traces of the secrets from commit history and also provides additional features like secret substitution, large file cleaner, etc. This involves altering commit history which is not preferable to track the application versions and therefore stress on avoiding placing the secret in the source code in the first place.
One Important thing to understand here is that these controls are on developer’s workstations. These cannot be considered as a full proof security measures as they can be bypassed easily or fail their purpose due to negligence. The aim of these controls is to detect common issues early so that the developer can fix them even before entering them into SCM.
Secrets Management
We talked enough of preventing the secrets in code. But you need secrets to authenticate your application components. Earlier secrets files, environment variables and other similar techniques were used to use secrets. However they do not provide abilities like rotation of secrets and versioning. A Secret Management Tool provides a secure central storage for secrets with capabilities like rotation, accessibility, logging, etc. A good secret management tool should be easily integrated into your environment with least overhead which is mostly achieved through exposing APIs to perform secrets accessibility and management. If you are in a cloud environment then there are native secrets management service available like Azure Keyvault or AWS Secrets Manager. Another approach is to eliminate the use of secrets by using token based authentication. These tokens can be granted based on the user identity, machine identity or any unique identity that can be associated with the application. Azure Managed Identity is a good example of it.
For our Pools-App I found a good opensource secrets management tool — Knox. It is a tool open sourced by Pinterest which they developed to tackle their problem of managing secrets. It is written in golang and has a dockerized version available. It has logging capabilities to track the usage of secrets and a cool feature that i liked is it provides authentication based on machine identity using certificates which enables to directly call the API to fetch the secrets with no authorization details in my code. The only problem i found is it lacks documentation and there are other tools with rich documentation available like the Vault by Hashicorp.
Source Control Security
We are well aware of various hacks where backdoors were implemented into source code. Source Control Management Security is crucial to maintain security posture. Different SCM provide different security measures. Some common controls present are-
1. Secrets Scanning
2. Dependency Security Scanning
3. User validations using git hooks
4. Logging
The free version of Github’s Gitguardian provide some basic features to monitor public repositories which also includes ‘Dependabot’ to monitor all the third party libraries used in your code.
Static Application Security Testing (SAST) & Dynamic Application Security Testing (DAST)
SAST & DAST are two methods of scanning the application for security. SAST as the name suggests scans the static state of the application. It can be performed before building the application to avoid the overhead of building if there are any security flaws. SAST can also be done in parallel to building the application to avoid long deployment time. SAST should not only check for security vulnerabilities but also check dependencies that your application uses. Security of these packages is also crucial to your security posture. DAST on the other hand deals with testing you applications security once it is built. It needs the application to be built and ideally it should be in a state which is as close to the state that will be seen by the end users as possible. It scans for runtime vulnerabilities and common attacks like OWASP Top 10.
In addition to SAST & DAST, Interactive Application Security Testing (IAST) can also be used to test your application wherein an agent can be deployed at runtime to ‘interact’ with your application to test out security flaws. IAST depends highly on your application environment. However it cannot completely replace manual pentesting and i did not find any good open source tool as of now.
So for our Pools-App i used Semgrep which supports many languages including javascript and typescript (believe me they are different !!!). It has dockerized version available and since i was already using docker for the Knox secrets manager i spun its container. I’m writing all the logs from different stages in a mysql database . For dependency scanning i used native npm audit as i have used npm for managing all the packages and it servers the purpose without additional overhead. For DAST there are various tools available and it can be quite overwhelming. So i went back to the basics and choose Nikto. Im storing all the logs in mysql database, however you can use your preferred log management application.
Our pipeline looks like this right now:
And the overall architecture looks like this:
We have integrated some security features in our devops lifecycle. In next part we will focus more on the security controls which are generally excluded from the devops lifecycle and could benefit if automated using the same pipeline.
