5 Reasons Why Achieving Compliance in the SDLC Is Challenging for AppSec Teams

user profile
Sr. Director of Product Marketing

Compliance isn’t a sexy topic, but it’s often mission-critical for organizations because failure to achieve compliance can have huge repercussions. Whether it be fines, reputational damage, loss of ability to transact business, or something else—no one wants to be responsible for a missed audit. With that said, AppSec teams are finding compliance across the software development lifecycle (SDLC) more challenging than it used to be. 

This post explores some of the reasons that compliance is becoming more difficult for AppSec professionals and what capabilities they need to implement to thrive under these conditions. 

5 Reasons Compliance in the SDLC Is Challenging

The following five items make compliance in the SDLC difficult for today’s application security professionals:

1. Modern Software Delivery Pipelines Involve a Myriad of Tools

The SDLC of the past was vastly less complex than those of modern organizations. Not only were there fewer systems that needed security controls but there were also fewer security controls to implement on each of those systems. Nowadays security teams must wrestle with an interconnected set of tools and infrastructure that span from code development to runtime cloud environments, including source control management (SCM) systems, build tools, container registries, infrastructure as code, and even cloud providers like Amazon AWS, Google Cloud, and Azure. Moreover, many organizations have multiple engineering teams, and thus multiple delivery pipelines, often using different toolsets. This is a lot more tooling to assess, determine gaps, and implement proper security controls around. Effectively implementing controls across all these teams, pipelines, and tools —enforcing least privilege, MFA, branch protection rules, etc.— is time-consuming and thankless work.

2. AppSec Has Limited Visibility into Development Tooling & Activity

Development tools— like GitHub, Jenkins, Terraform, Amazon Web Services—typically get selected, implemented, configured, and managed by engineering teams. But where is security in these discussions? Unfortunately, often security doesn’t have a seat at the table and are unaware what tools exist, what environments are present, how they are configured, what activity is happening, or what security controls exist. How do you ensure compliance for things you don’t know exist? When compliance audits roll around, best case is that your auditor doesn’t ask much about your software delivery pipelines, worst case is that security teams find themselves scrambling to understand the lay of the land and trying to implement requisite controls. 

3. Security Controls Are an Afterthought

But surely there isn’t that much work to be done! Right? If only that were the case. In actuality, the tooling that makes up modern software delivery pipelines are development tools. They are, by default, configured for efficiency and productivity. Each tool requires tuning and configuration to have basic security controls in place, let alone to match the requirements of a specific compliance framework like SOC 2 Type II, PCI-DSS, or ISO 27001. Each vendor has its own security settings, each type of tool has different considerations, and implementing something like least privilege may have a different level of difficulty in different types of tools. For example, in an SCM, privilege is maintained on a repo-by-repo basis. If you have 10 repos and 20 developers, regularly auditing and enforcing the concept of least privilege should be no problem. What if you have hundreds of developers and thousands of repos? Not so much.

4. Data Collection & Preparation Is Arduous

At some point it will be time to gather evidence and artifacts for auditors. The data needed to answer audit questions and satisfy requirements is far-flung across many tools, in natural silos split out by the phases of the SDLC (and its tooling), and thus centralizing it can be tough. The options are usually to gather it manually or write some scripts to bring it together in a more automated fashion. Once centralized, this data must also be normalized so it can be compiled into a coherent artifact that can be understood by an often non-technical auditor.

5. Auditor Requests Are Changing

Change is afoot. Macro-level trends in the attack landscape are starting to change what auditors are asking for in their audits. Attackers have shifted their focus away from well-fortified production applications to the software delivery pipelines that create those applications. This is what is known as a software supply chain attack. The crux of these attacks rests on compromising the SDLC to gain access to the software and its data, often with the purpose of attacking downstream users; a la the SolarWinds or Kaseya attacks. As these types of attacks increase in prevalence, it draws attention to the SDLC and its security controls. Thus auditors, ever a lagging indicator, have begun to inspect software delivery pipelines more closely than they did in the past. This means during your next audit you may be asked more, and more in-depth, questions about AppSec programs and the SDLC than you were in the past. 

Compliance Capabilities AppSec Teams Need to Thrive

AppSec professionals need to find solutions that can help them tackle compliance in the SDLC. The systems and processes they implement must provide:

  • Visibility across entire SDLC, and its tools, users, and activity
  • An understanding of their SDLC’s compliance posture, including gaps against requisite framework requirements
  • The ability to efficiently set consistent security controls across the tools, teams, and processes of the SDLC 
  • The capability for security teams to easily ask complex questions of the SDLC 
  • The ability to generate out-of-the-box and custom compliance artifacts/evidence that match auditor requirements.