Creating a Governance Policy

Sitting Down And Getting Started

The governance policy is an important tool in your component risk management toolbox. It serves as a public statement about your risk tolerance and a set of guidelines that others will use to guide decision-making. The best governance policies are short, plain-language, and available to everyone in your organization. 

If you don’t have a governance policy already, start small and be focused. Your first governance policy should be limited in scope, make small and calculated asks, and include just key stakeholders. As muscle memory is built and processes are refined, slowly build out to include more teams and bigger asks. It’s not wise to try and implement a mature, nuanced governance policy right off the bat – you’ll burn through resources and goodwill almost immediately. For that reason, if you’re just getting started, consider the crawl/walk/run model.

As your governance policy comes online, watch for bottlenecks, and open feedback channels so that others can alert you when they arise. These bottlenecks will first appear where Development and Operations meet Security. Solving these bottlenecks is a matter of scalability and repeatability, and that means automation.

Crawl – SBOMs and Risk Assessment

During your first pass at a governance policy, focus on getting SBOMs created for all new and existing apps. Assign accountability to your Development teams to generate and store an SBOM for every deployment build of their app. These SBOMs serve as point-in-time records of your apps, and legal requirements around SBOMs are on the horizon, so plan to keep these for 10 years or more. 

Additionally, look to perform risk assessments on new and existing apps. Likely your AppSec team is already accountable for this. Store these along with your SBOMs (ideally, your SBOMs should include the risk assessment) and make a point to review them regularly at cross-functional team meetings. Even if you’re not remediating issues, being aware of risks is a huge step in the right direction. If something *does* go wrong – and it will, inevitably – having risk assessments on-hand reduces your response time.

There are automated tools that can help keep this low-effort and scalable. Sonatype’s Lifecycle is one such option. [The CycloneDX project has a number of open-source tools]( that can help to keep your initial costs low.

Walk – Remediate

Once your organization is comfortable with Crawling, update your governance policy to address the topic of remediation. At the micro level, assign accountability for the act of remediation, and enable them to make component risk management a priority. For example, give them the authority to create and move tickets in your issue tracking software (Jira, Assembla, etc.)

Also at the micro level, establish the ideal remediation path. Usually, the best way to remediate is to update the component to a non-vulnerable version. If that’s not possible, describe what other remediation paths should be attempted. If remediation isn’t possible, lay out how mitigation efforts should be documented, or how risk can be temporarily waived until a later date.

Run – Establish Goals and Enforce

Once the remediation process is familiar, you can start to Run. In this stage, update your governance policy to establish what your organization’s goals are vis a vis component risk management. This goal will evolve as your organization evolves. As a result, your goals should be revisited often and have some flexibility built-in.

For example, you could start by declaring that your apps can’t be deployed if they contain component security risks over a certain severity level. Later, you might update to include a rule about component licenses, as well.

This stage is also where you’ll start enforcing your goals by actively blocking builds, deployments, and downloads of packages with unacceptable levels of risk. Enforcement is always a tricky subject – we’ll talk more about it shortly – but you can set yourself up for success by automating this enforcement. Ideally, blocking should happen automatically, based on a numerical score generated by a tool, with feedback piped directly to the people who are involved. Don’t rely on the instincts of someone from your AppSec team; that’s prone to human error and will only lead to frustration.

Acknowledge the Tension Between Rules and Innovation

There’s always a tension between making rules and encouraging innovation. This is especially true when it comes to enforcing your governance policy. You can alleviate that tension in a few ways.

First, make it clear that managing component risk is a company-wide effort, and not the “fault” of any individual or team. For example, a developer who picks a risky component hasn’t failed; component risk management isn’t so simple. You’ll notice that we like to use the word “accountability” rather than “responsibility” for this reason. Assigning responsibility is like assigning blame, whereas accountability is like asking for an explanation. 

Second, avoid the scan-and-scold mentality. It’s not sustainable, and pitting AppSec against your developers guarantees slow, complex, and frustrating deployments.

Third, be crystal clear about what, when, and how things will be blocked, and lay out the path for getting unblocked. Handle blocking and unblocking in an automated way. Waiting to see if a build is blocked, and then waiting to see if it’s unblocked, is unpleasant enough to discourage innovation.

Finally, acknowledge the tension in plain language! A governance policy isn’t about shooting down new ideas or slowing development to a crawl; it’s about ensuring that your apps are high-quality, stable, and innovative. Say that much, and create a place for feedback. LIke any DevOps effort, your governance policy is a collaboration. 

And, as you might expect, socializing your governance policy will be key. We’ll discuss how to socialize and set expectations later in this content.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments