DevOps is eating the software development world, providing a much quicker way for development teams to push code to production and get feedback immediately.
At the beginning of 2021, a survey of 3,200 enterprises determined that 74% of organizations had already adopted DevOps practices in some form. From this group, 63% agree that it has increased their productivity, even with remote working in the long-term.
What makes DevOps work so well for organizations is that teams can move at a higher velocity, ensure reliability, scale wider, collaborate more, and yes, even improve security. Increasing the frequency and quality of releases can go a long way for saving time and budget.
Adopting DevOps also means adopting more automated processes. This decreases manual work and increases consistency in production. Complex systems can be managed more easily and less risk is imposed.
An example of this is in Infrastructure as Code (IaC), where the infrastructure is provisioned and managed using software development techniques such as version control and continuous integration. In IaC, data flows through machine-readable definition files, rather than physical hardware, data center servers or networking infrastructures.
With IaC, entire systems are managed into a few lines of code. This is much easier to deploy quickly.
Within each DevOps approach to scale organizations, there are unique security areas which need to be considered. Below, we break down the seven main practices of DevOps and how they impact security in the SDLC.
As mentioned above, IaC simplifies infrastructures, making it easier to reproduce systems and reducing inconsistency in code deployments. IaC works with cloud environments, posing a unique set of challenges for security. Below are some of the top security risks in IaC to consider when figuring how to scale DevSecOps:
As mentioned in IaC, configuration management can greatly impact security if not properly handled. When scaling DevSecOps, administrative activities tend to be the biggest threat to configuration management security. Some examples of these activities include:
Continuous integration (CI) is an automated practice that brings together code from multiple contributors into one project.
While containers have a short lifespan and are often walled off from each other, they’re also usually deployed on the same IP space. Meaning, if a hacker can access one container in that cluster, they can then access any other container within that same group.
It’s also important to consider that continuous delivery and continuous deployment also have security implications. Since they’re all usually practiced together, all of these security concerns must be considered at the same time.
Continuous delivery pipelines are automated to help move application code along the SDLC, from developers to the end user or application service. Top risks in this automation include:
Using unversioned code. A great security risk occurs when a bug is identified, and it is not clear who is affected, which version needs to be fixed or which customer needs their customer updated. Also, a lack of a mechanism to update software could also pose security risks. For example, the development team could identify exactly what the bug is, fix it and have a release ready. However, if the customer is not ready or willing to update the software, then the issue ultimately goes unresolved. In these cases, there may be a lack of backwards compatibility or lack of training for the people using the software.
Continuous deployment (CD) is commonly practiced with continuous integration. CD, in itself, is an automated practice to ensure that software can be released effectively when requested. A CD process could or could not also include an approval process, depending on the organization’s policies.
While CD’s main function is to improve efficiency in the deployment of code, the practice does have some possible security risks including:
Continuous monitoring, or continuous security monitoring (CSM), is a practice which benefits the security of scaled DevSecOps. It is considered a threat intelligence approach that automates the monitoring of controls and vulnerabilities to then support organizational risk management decisions. A good CSM practice should provide visibility on all digital assets within your organization, including cloud storage, web applications, mobile applications, IoT and connected devices, email servers and public code repositories, among others you may have.
Integrating continuous monitoring into your DevOps practices has several key benefits, including:
In 2018, 61% of organizations said a lack of automated or integrated security testing tools was creating challenges for their business. Like continuous monitoring, automated security testing is another protective practice. Many types of automated security testing exist, including vulnerability scanning, penetration testing as a service (PTaaS), DAST, SAST, and more.
Vulnerability scanning can automatically run analysis on code and systems to identify security weaknesses. These tools can be affordable and quick, though they don’t always provide deep insights.
DAST and SAST are quite similar in this respect. DAST tools are used for web applications through performing black box testing. DAST is more beneficial in the design and build stages. SAST tools, on the other hand, reviews source code to identify possible vulnerabilities. Though, like DAST, it is also best used before release to production.
Penetration testing as a service (PTaaS) is the most comprehensive of the tests, though it does take more time. Like the other tools, it can integrate into an existing SDLC that frequently deploys new code updates. A unique difference between PTaaS and the automated scanners, is that PTaaS uses a real human penetration tester to search for and identify security risks. This produces more in-depth findings than other testing methods.
DevOps is a fantastic methodology which can certainly increase the agility and efficiency of code deployment. However, all DevOps practices need to be considerate of security implications when scaling an application’s deployment. Including the security considerations above, managers also need to have their teams properly trained on application security and develop an overarching, supportive organizational culture.