The primary goal of DevOps best practices is to automate the process of building, deploying and running applications. But, teams need to make sure they understand and can access the right tools to help simplify automation, while gaining visibility across deployments.
But there’s now the danger of DevOps being implemented in various ways, with limited or no security considerations. With this in mind, businesses are seeing the need to introduce security aspects to DevOps. Enter DevSecOps.
DevSecOps is an evolution of DevOps, bringing the additions of threat modeling, vulnerability testing and incident management into the mix. As the current security climate is constantly changing, it’s vital to take these into consideration when planning and implementing DevOps-like practices in your organisation.
And, when done right, DevSecOps work smoothly and won’t feel like the burden these kinds of tasks can be when a security layer is added.
Let’s break down how these tools and processes can help at each phase: build - deploy - operate
1. DevSecOps at the build phase
Build a trustworthy image foundation
To begin with, we need to trust the image registry being used. We’ve come across some very odd database images from various sources that can be very vague. These can lead to potential takeovers by hackers - costly errors that are time-consuming to fix afterwards. In short: be very aware of what you use as a base image.
And base images should be as minimal as possible. The more elements included in the image, the more potential vulnerabilities there are to be exploited.
Images need to be updated regularly
This should be mainly automated, with some reliance on occasional manual work. Also remember to check dependencies and act on them. It’s something that might be overlooked, as with image changes there can be the need to adjust something on the application level. But this is where non-production environments are handy, to test and troubleshoot, allowing you to easily take updates into your production environment.
Keep images clean - in an automated way
Take time to remove any unnecessary and potentially exploitable software from your image, including package managers, network tools, shells, compilers and debuggers. These are ideal footholds for hackers to find potential vulnerabilities. We highly recommend using SCA tooling to automate this task.
SCA tools perform automated scans of an application's code base and related artefacts such as containers and registries, identifying all open source components, their license compliance data, and any security vulnerabilities. As well as providing visibility into open source use, some SCA tools also help fix open source vulnerabilities through prioritisation and auto remediation.
And use automatic scanning to go through your image registry and spot potential and known vulnerabilities. SAST tools are used in the build phase for proactive scanning with inside access to perform static analysis and check application source code or bytecode for insecure elements. They can pinpoint issues accurately (but are prone to false positives). They are also language-specific and cannot identify runtime vulnerabilities, as SAST scanning is done without the application running.
Sensitive and confidential information and how it’s accessed and used is a key consideration when running tight operations. Do not store files or codes unencrypted, do not use them as environment variables and make sure you have complete knowledge of where and how any confidential information is being used and use common sense to limit visibility.
2. DevSecOps at the deployment phase
During deployment, there are some basic rules to help get you up and running fast, securely.
Using data gathered from the build phase to assess the readiness of each deployment, you can determine things like:
- Is the image used really safe?
- Is privacy being handled correctly and in the necessary way?
- Is privileged access used in a limited manner, or is it too widespread causing a potential problem if there’s a leak?
- Is deployed resource visibility limited in the network and isolated in a way that it cannot be used as a starting point to gather more data from your network?
Deployments should be done with limits to the resources used. But this is something that may need to be bypassed when building something resource-intensive and on a large scale.
Always communicate deployments
If there’s an issue, it needs to be tracked down by the individual who triggered it. This might be by Slack, email or sms, but there needs to be a clear communication thread for those who are responsible for it. And, if you feel that deployment is risky, use necessary caution and block the deployment. Explain why and inform developers how to correct it.
Automate vulnerability scanning
During the deployment phase DAST scanning is used to probe a live application to safely simulate actions of real-life hackers. Modern products can find runtime vulnerabilities and often confirm them to eliminate false positives, while they have no access to the application source, they are language-independent and can test the entire application environment.
3. DevSecOps at the operate phase
When build and deployment is complete and the application is running, it’s vital to keep a close eye on operating applications. It’s where all those decisions made earlier come to fruition.
Use dynamic scanning
From our experience, this is the phase where automation can be applied to a lot of steps to keep everything manageable. Use and implement dynamic scanning to detect any vulnerabilities and running containers to build a process and also to act fast when malicious activity is flagged.
This allows you to build a list of approved processes while blocking unwanted actions such as privilege escalation, cryptomining, malicious and exploitable processes. This is something that might require some extra work or third-party software unless you have good knowledge of anti-hacking techniques and tools.
And ensure you’re building processes and automation how to handle when threats are found - this is a must to limit the damage and potential harm to the company you are handling these for.
Deciding which DevSecOps tools and processes to adopt and where to prioritise first can cause something of an “analysis paralysis” - even with teams that have been working with DevOps for some time. Don’t worry, we’re here to help.
We’re known for being DevSecOps pioneers, with a proven track record in helping teams automate deployments. We can help you reduce release cycles from months to hours – and ensure teams are empowered to continue improving service delivery with security aspects taken care of. Contact our security experts today.
Hey agile heroes! We’re hiring DevOps engineers across our European markets right now. Find out more and apply here.
Get in Touch.
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.