Introducing Policy SBOM: A Software Bill of Materials for your Authorization Policies

We’re excited to announce the Policy SBOM feature is now generally available to all Styra DAS customers, giving enterprises transparency and traceability into deployed authorization policies. Just like a software bill of materials (SBOM) is an inventory of the components and dependencies in a software application, a Policy SBOM is an inventory of the policy modules, including their sources, versions, and dependencies, within an Open Policy Agent (OPA) policy bundle.

TLDR

Understanding the Need for a Policy SBOM

In today’s complex enterprise environments, where multiple teams deploy numerous authorization policies across different infrastructure and application layers, managing and understanding the contents of deployed policies becomes increasingly difficult. This is especially true when it comes to traceability and troubleshooting of deployed policy bundles. Previously, when you needed to trace the lineage of a policy or troubleshoot a policy bundle, teams had to manually track down each policy’s origins and dependencies, a process both time-consuming and error-prone In fact, responses to Styra’s 2023 State of Policy as Code Report revealed that 29% of organizations cited difficulty meeting security, compliance, or auditability requirements as their biggest challenge to implementing authorization, while 26% pointed to the challenges of managing policies at a greater scale or complexity.

The introduction of the Policy SBOM in Styra Declarative Authorization Service (DAS) addresses these challenges. Designed for organizations seeking to centrally manage policies from multiple teams and sources, the Policy SBOM provides a structured and automated way to maintain visibility and control over the policies deployed within their systems.

How It Works

A key feature of Styra DAS is the ability to define policies at various levels of hierarchy by using Systems, Stacks, and Libraries. This policy hierarchy allows teams to abstract and share common functionality using Libraries and enforce higher-level organizational policy requirements or foundational policies in Stacks, while Systems contain policies specific to the Policy Enforcement Point (PEP) and the associated team or application.

Trying to manage this hierarchy yourself to ensure the right policies and data go to the right PEPs is complex and time-consuming, which is why DAS automates this aspect of policy management for you. When DAS builds a policy bundle for a System to distribute to the configured PEP, it first determines all dependencies in the System’s policies. To do this, DAS identifies the Stacks which may apply to the System (based on System labels) and Libraries which are imported or referenced by System, matching Stack, or other Library policies. DAS then combines the policies and data sources from any Stacks and Libraries with the System policies and data sources to build bundles to distribute to OPA (in addition to some unique bundle size optimization steps).

The Policy SBOM builds on this process to automatically add additional traceability to the bundle contents. When using Git-backed Systems, Stacks, and Libraries to version control policies (a policy-as-code best practice featured in our Unified Authorization Maturity Model), DAS ties the current version of a policy to a commit SHA in its origin repository. During the bundle build process, DAS identifies the policy origins for all Git-backed resources in the bundle, combines identical origins to the highest level common packages to simplify the Policy SBOM record, and records these policy origins in the bundle manifest metadata in a STYRA_SBOM parameter. This provides full traceability from a policy package to a Git repository, commit SHA, branch or tag reference, and directory path. Traceability of this type is sometimes referred to as policy provenance.

How to Get Started

The Policy SBOM feature has been enabled for all SaaS Enterprise customers. Any bundles built since the end of July automatically include the STYRA_SBOM parameter in the bundle manifest metadata if the System, any matching Stack, or any imported Library is Git-backed.

As an example, an SBOM record for a Git-backed Library named customer_snippets may look like this:

{
    "id": "libraries/customer_snippets",
    "repo": "https://github.com/UserOrg/example-repo.git",
    "ref": "refs/heads/branch-name",
    "commit": "14114bf61f8dd72562e17b6b001a4330cd2cce70",
    "path": "libraries/customer_snippets",
    "timestamp": "2024-07-07T23:27:57.982127714Z",
    "roots":
    [
        "libraries"
    ]
}

The Policy SBOM is included in the policy bundle itself and can also be accessed via the Styra DAS API. For more details, see the Styra DAS Policy Software Bill of Materials documentation.

If you’re a Styra DAS customer and aren’t yet using Git-backed policy resources, now is a great time to get started and implement this best practice. Check out the Styra DAS Git Management documentation for instructions on connecting your Workspace, Systems, Stacks, and Libraries to a Git policy repository.

Conclusion

The launch of the Policy SBOM in Styra DAS is a significant step forward for organizations looking to enhance their policy management, policy governance, and policy provenance frameworks. By providing a clear, automated view of the components that make up your policy bundles, Styra DAS empowers teams to manage policies more effectively, ensuring security, compliance, and efficiency across all layers of application and infrastructure. Start leveraging the Policy SBOM feature today to bring a new level of clarity and control to your policy management practices.