GitHub Actions, API, and SBOM

OpenContext has three new features that are all complementary of each other. We’ve released two GitHub Actions and our API.

Our new GitHub Action will create an SBOM as an artifact tied to your release. You may have seen our announcement for the first GitHub Action, we’ve expanded the feature functionality to help you on your audit readiness journey. This means you do not have to recreate an SBOM, take extra steps, or really even think about it, just your normal workflow and an SBOM artifact will be associated with your release. 

We are helping you with your audit readiness! There have been discussions around what in the world are we supposed to do with all the SBOM data? Is this really just security theater or is it solving a problem? How does this prevent the next Log4j shenanigans? The function of OpenContext is to capture your technical stack, your data lineage. Allowing our security friends to have insight into how the system works, overlay vulnerabilities with your technical stack. Help you with those pesky guardrails and make them manageable.  

The product provides human readable information to help you do all those bad ass things you already do. You may be responsible for capturing this information as a DevOps person, Release Engineer, AppSec, Developer. Like all things tech, it depends.  We are a load lifter, a one more step remover, and a now I know who is responsible for that so I can partner with them, tool.

With all of that goodness, we realized, if we want to make your life easier, perhaps you don’t need a new UI. So we have our REST API. If you have an internal tool that experiences drift, a tool that needs data augmentation, dashboards, spreadsheets, etc they could all benefit from the API! A few specific for examples:

• CMDB
• Service Catalog
• Home grown tool
• ServiceNow

Now you don’t need that sprint each month or quarter to update the system in order to keep it fresh. OpenContext automatically updates your data and we are building out a cohort of folks responsible for an aspect of your technical stack. More on that in the future.

These features reduce your toil so you can focus on those projects like scalability, migrations, reliability, best practices, security. 

API

Our REST API offering will pull your auto-discovered data into your existing internal projects. This allows you to fill in the data gaps and address any issues you currently have around data drift.  Most internal projects are populated after an incident and get stale quickly. API access will allow folks to automate this effort, making it more accurate without the additional toil.  

Think of the API as allowing you to update your internal tool that allows a cross section of teams to know who is working on what. Updating the teams, owners, subject matter experts. Often these systems are home grown and serve the DevOps teams during an incident, AppSec with vulnerability remediation, Product when navigating cross team collaboration for new features. 

This can also connect with ServiceNow or other third party tools that you might use for a CMDB, Service Catalog, etc where the data is not automated. 

SBOM

The Software Bill of Materials is a new requirement associated with the Executive Order on Improving the Nation’s Cybersecurity. As a result of this executive order there are vendors such as Splunk, Datadog, and Snyk who are developing products to provide insight into the SBOM. We feel there will be a greater need for insights around the cohort responsible for any vulnerabilities found via an SBOM. 

OpenContext has created a specific data category to help you track your SBOMs in real time, without additional lift. This simple addition allows DevOps and AppSec folks to  be audit ready. More importantly, you’ll be able to see where you have SBOMs generated and where you don’t. That allows you to assess the best next steps for your team, product, and organization. 

GitHub Action

We have two OpenContext GitHub Actions. First, one that will take what’s in the GitHub dependency graph when the workflow is triggered, generate an SBOM, and upload it as a release artifact. Additionally, it will generate an artifact context YAML for the SBOM. This can optionally be uploaded as a release artifact. The second one creates an artifact context YAML for any type of artifact when provided a link to the artifact.