Shadow engineering exposed: Addressing the risks of unauthorized engineering practices

Shadow engineering is present in many organizations, and it can lead to security, compliance, and risk challenges.

In this Help Net Security video, Darren Meyer, Staff Research Engineer at Endor Labs, discusses why it causes issues and how it should be addressed.

Developers using code repositories, tools, or processes that are unsanctioned, untracked, or don’t adhere to an organization’s best practices are the natural outcome of pressure for faster application release velocity and a lack of guardrails and paved paths.

But rather than trying to stop it, which can turn into a frustrating game of whack-a-mole, security teams need to understand how shadow engineering negatively impacts their initiatives so they can work around the problem.

It affects security in two main ways: compliance and risk.

Organizations must show that their pipeline tools to support compliance are deployed for in-scope repositories. However, developers using untracked tools and bypassing compliance controls within pipelines can threaten compliance requirements.

Security teams also need visibility into the supply chain to build and deploy software, including the tooling used within CI/CD pipelines. A security team that can’t rapidly identify shadow pipelines and risky toolchains within known pipelines will likely experience extended periods of vulnerability and all of the stress, time, and opportunity costs associated with an extended response.

So, what can be done?

One way to address shadow engineering is to create a change review process and enforce it with preventive controls. This could be accomplished by establishing a code owners file requiring a security reviewer for pipeline changes. But this has some significant drawbacks. Not only does it require a lot of process overhead and application security resources, but it also undermines the advantages of engineer-owned pipelines. Slowing down engineers’ ability to make pipeline changes by turning an application security team into a bottleneck imposes a massive productivity tax on developers.

Darren believes a better model is establishing automated controls that give organizations clear insight into what’s running in their pipelines and which configurations don’t align with organizational requirements. This allows them to create a responsive process that surfaces critical issues promptly to developers while providing a more complete risk picture to the security team.