Why Your Next Security Audit Should Include the Procurement Process

TLDR: Security researchers often focus on code-level vulnerabilities, but the most critical flaws in government and enterprise systems are frequently baked into the procurement and compliance lifecycle. This talk highlights how rigid, non-technical compliance requirements like NIST SP 800-53 controls and manual Software Bill of Materials (SBOM) checks create massive security gaps. By forcing technical teams to prioritize checkbox compliance over actual security, organizations inadvertently create "security theater" that leaves systems vulnerable to real-world exploitation.

Security researchers spend thousands of hours hunting for zero-days, yet we often ignore the most glaring vulnerability in the room: the process that decides which software gets deployed in the first place. When you are performing a red team engagement or a penetration test, you are usually looking for misconfigurations, weak authentication, or unpatched services. You rarely stop to ask why the system was built with such a convoluted, insecure architecture in the first place. The answer usually lies in the procurement process, where non-technical decision-makers force engineers to implement "secure" controls that actually degrade the security posture of the entire environment.

The Compliance Trap

The fundamental issue is the disconnect between technical reality and bureaucratic requirements. When a government agency or a large enterprise decides to deploy a new system, they rely on frameworks like the NIST Risk Management Framework. These frameworks are designed to manage risk, but in practice, they often become a checklist of arbitrary requirements.

For instance, an organization might require that all software be accompanied by a comprehensive SBOM. While an SBOM is a great idea in theory, the implementation often devolves into a manual, error-prone process where a developer generates a static JSON file just to satisfy a procurement officer. This file is rarely updated, never audited, and provides zero visibility into the actual supply chain risk. As a pentester, you know that a static list of dependencies is useless if the underlying libraries are vulnerable to a Remote Code Execution (RCE) attack.

When Policy Becomes the Vulnerability

The most dangerous aspect of this friction is how it forces engineers to bypass security controls just to get their jobs done. If a developer needs to deploy a Kubernetes cluster but is blocked by a six-month procurement cycle for a "compliant" load balancer, they will find a workaround. They might expose a service directly to the internet or use an insecure, unmanaged proxy.

This is where the "hacker" mindset is actually a liability for the organization. If the security team is too rigid, the developers will treat them as an obstacle to be circumvented rather than a partner in security. You see this in every engagement: the "shadow IT" infrastructure that is completely invisible to the CISO but perfectly visible to an attacker. When you are scanning a target, look for these gaps. They are not bugs in the code; they are bugs in the organizational policy.

The Cost of Inefficiency

The talk highlighted a specific, painful example: the "landing fee" for software. In many government environments, you cannot simply deploy a tool. You have to pay a fee to have it "vetted" and "authorized" for use. This process is so slow and expensive that it effectively bans open-source innovation. If a team wants to use a new, secure tool, they have to wait months and pay thousands of dollars.

This creates a perverse incentive structure. Teams are forced to stick with legacy, proprietary software that is already "authorized," even if that software is riddled with vulnerabilities. As a researcher, you are essentially fighting against a system that prefers a known, insecure status quo over an unknown, secure innovation.

How to Pivot Your Testing

If you are a pentester, you need to start looking at the "why" behind the infrastructure. When you find a system that is clearly misconfigured or running outdated software, ask the client about their procurement process. You will often find that the technical team is aware of the risk but is powerless to fix it because of the compliance framework.

Your report should not just list the vulnerabilities. It should highlight the policy failures that made those vulnerabilities possible. If you can show a client that their procurement process is directly contributing to their risk, you provide much more value than a simple list of CVEs.

Moving Toward Real Security

The solution is not to abandon compliance, but to automate it. We need to move toward "policy as code," where compliance requirements are enforced through automated testing in the CI/CD pipeline. If a container image doesn't meet the security baseline, it shouldn't be a manual review process; the build should simply fail.

We also need to bring technical expertise into the procurement room. If the people making the decisions don't understand the difference between a secure Kubectl configuration and an insecure one, they have no business signing off on the architecture.

Stop treating compliance as a separate, non-technical track. It is a technical problem, and it requires a technical solution. If you are a researcher, start challenging the assumptions behind the systems you test. You might find that the most interesting vulnerability is not in the code, but in the policy that allowed that code to be deployed in the first place. The next time you are on an engagement, look for the "shadow IT" that was created to bypass a broken procurement process. That is where you will find the real, high-impact findings.