Why am I rooting for a new category in OWASP TOP 10 2021 — Insecure Build/Deployment environment?

Published in

InfoSec Write-ups

4 min readMar 28, 2021

Earlier this year OWASP announced a planned release of brand-new OWASP TOP10 2021.

OWASP released an open survey to gather information about vulnerabilities which cannot be easily identified during black/grey box testing, but are still relevant for overall security posture of applications.

As a result I decided to submit a candidature of a new vulnerability category “Insecure Build and/or Deployment Environment”.

This article is to provide some rationale behind submitting that category. Despite the fact it is not related to vulnerabilities in source code itself it may have an extremely negative impact on overall security posture of applications.

Agile software development

Traditionally Change Management is a very well-defined process. You can find hundreds of articles on the Internet explaining how each change should be properly requested, developed, tested and approved before being moved to the production environment.

Obviously, each of these steps requires documentation and formal approval (sign-off) from the appropriate person. This process was giving security engineers several chances to ensure that changes do not introduce any new vulnerabilities and infrastructure to which the application is deployed is hardened and patched.

Security around the Change Management process gets a little bit more complicated for agile software development and DevOps methodologies where tens of small changes are introduced every day. Each of these small changes is being automatically tested from various perspectives and if everything goes as expected it gets deployed to the environment of your choice without human intervention.

Source: https://intland.com/wp-content/uploads/2019/07/devops-infinity-1-1.png

Obviously, the level of automation and decision whether any manual approval is required heavily depends on your organization’s size and risk appetite, but in general the idea is to decrease human effort to an absolute minimum.

Security controls for agile software development

Without any manual review in place, change management and security controls rely heavily on the fact that:

humans cannot access sensitive environments in an uncontrolled manner
application’s and infrastructure’s code is independently reviewed to avoid unauthorized changes and detect flaws
pre-approved and verified artifacts are used while building applications to decrease the risk of insecure dependencies or malicious artifacts
automated tests are performed by pipeline to detect defects or security issues

It goes without saying, that ability to circumvent any of the above mentioned controls may introduce unauthorized changes and security issues to the application.

Surprisingly, you have plenty of articles mentioning security in the pipeline (SAST, SCA, DAST), but close to zero articles describing technical aspects of security of the pipeline. Hence, I believe it would be good to start raising awareness about this issue, as recent incidents show that attackers are exploiting these issues in the wild.

Examples of vulnerabilities in this category

Example #1:

Unrestricted access to poorly protected CI tools. Unauthorized user accesses and modifies pipeline configuration in an uncontrolled manner. As a result he/she disables all security checks which were stopping him/her from deploying vulnerable applications to sensitive environments.

Side comment — as CI tools usually have extensive network access inadequately protected Jenkins instances may lead to compromise of multiple systems.

Example #2:

Code review is not technically enforced by VCS tools, so malicious attacker or careless employee introduces a backdoor in the application and deploys that to the production environment.

Example #3:

Improper access segregation. If access to your build environment is not properly segregated and/or pipeline is executed on pull request, malicious users may use your production secrets (to which your CI tool has access) to deploy malicious versions of your application to sensitive environments.

Example #4:

Lack or incorrectly implemented signing process. Disgruntled employees or malicious attackers can modify your artifacts in an unauthorized manner and deploy it to sensitive environments.

Example #5:

Misconfigured artifact management tool or image registries allow developers to pull images and dependencies from untrusted sources without any additional verification.

Summary

Summing up, it is clear that the proposed category of vulnerabilities is not directly related to insecure coding practices, hence this candidature might be slightly controversial. At the same time, I believe that similarly to “Insufficient Logging and Monitoring” in OWASP Top 10 2017, we should raise awareness around other non-obvious security issues around Software Development Life Cycle.

I wanted to use this opportunity to encourage you to vote for new risk categories in OWASP Top10 2021. Even if you believe this vulnerability category does not make a good fit to OWASP Top 10, there is a plenty of other items on the list to choose from:

https://docs.google.com/forms/d/e/1FAIpQLSfi-uzBp52AyvImpebWwYnzqGqhLT8V5wpwOm30r8s3Cg1Yow/viewform

External references

For those of you who are interested to read about this problem I would recommend the following articles:

Why am I rooting for a new category in OWASP TOP 10 2021 — Insecure Build/Deployment environment?

Written by Marcin Szydlowski