Comprehensive SBOMs can help address software supply chain risks

One way to address the risks inherent to the complex applications we are building is to use “Software Bill of Materials” also known simply as “SBOM”.  At its simplest, a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component: Its name, who supplied the component, what license it uses, the version number, any known vulnerabilities, and a list of all the component’s dependencies.

Application complexity is increasing

The reality is that modern applications are complex and dynamic, and therefore hard to secure. They use programming languages that run entirely in the browser, they talk directly to their dependencies on the internet and they use technologies like containers, serverless and public cloud. All of these bring their own challenges, so we need visibility into all these other application components and dependencies as well. What third-party APIs and public cloud components is it using? Is it using an identity provider like Auth0 or Cognito? What infrastructure is required to make the app run? All of these things need to be understood to really be able to better represent what is in an application and how to secure it.

Traditional SBOM tools do not produce accurate results

Most SBOM tools that exist right now, simply focus on showing customer the open-source libraries that they are using in their applications.  Moreover, most SBOMs are stand-alone XML or JSON documents.   By themselves these documents don’t provide much value.  Even worse, most SBOMs are point in time generated and then never updated.  So, these “static” SBOMs quickly become out of sync with the actual application they are supposed to describe.

Application complexity forces SBOM to evolve

The reality is that existing SBOM implementations are not accurately describing the applications they are supposed to represent.  Instead, they represent a part of the application: open-source libraries.  There is a drive within the industry right now to provide a better, more comprehensive SBOM that does a better job of describing the complex modern web apps that we are building.  To do this, you need to use data from other sources than package manifest files.

The comprehensive SBOM is a document that describes this type of application fully.  Moreover, a truly comprehensive SBOM will also be up to date and searchable.  Let’s drill into this a bit more.

SBOMs need three things to be comprehensive:

1. Data from source code, third-party APIs and SaaS dependencies as well as any cloud-native and identity providers that the application requires.
2. Timely.  SBOMs need to truly represent what the application looks like and that means that any time there is a change to the application the SBOM needs to be updated.  The only thing worse than no SBOM is an incorrect SBOM.
3. Finally, SBOMs need to be searchable.  There’s no point to generating SBOMs if all you do with them is store them somewhere.  What happens the next time there’s a Log4shell-type incident?  You need to be able to search your SBOMs so you can find vulnerable technologies quickly.

The business value

Building a complete SBOM lifecycle can be a challenge, but in the end, the value that it provides to organizations is enormous.  Simply having the ability to quickly find all the software and application components in your estate of apps is huge.   But even better, being able to query that data for vulnerable components could save organizations millions of dollars in lost productivity.

Automated SBOM platform

SecureStack automates the whole SBOM process from end to end.  Our platform delivers all stages of the SBOM lifecycle in a fully integrated solution that is incredibly easy to onboard.  SecureStack integrates easily into your CI/CD pipelines and workflows so that SBOMs are generated, stored and made searchable, automatically.  Because they are generated directly at build and deploy time you know that they are accurate and provide the most business value for your organization.

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

Software supply chain attacks have grown exponentially over the last three years:  malicious packages, package manager corruption, continuous delivery pipeline attacks, dependency confusion, zero days in open-source software and more.  This is driving many organizations to look for better visibility across their software supply chain. 

Let’s dive in a bit to see why the problem is growing and some potential solutions.

Application complexity is increasing

The reality is that modern applications are complex and dynamic, and therefore hard to secure. They use programming languages that run entirely in the browser, they talk directly to their dependencies on the internet and they use technologies like containers, serverless and public cloud. All of these bring their own challenges, so we need visibility into all these other application components and dependencies as well. What third-party APIs and public cloud components is it using? Is it using an identity provider like Auth0 or Cognito? What infrastructure is required to make the app run? All of these things need to be understood to really be able to better represent what is in an application and how to secure it.

SBOMs can help address software supply chain risks

One way to address the risks inherent to the complex applications we are building is to use “Software Bill of Materials” also known simply as “SBOM”.  At its simplest, a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component: Its name, who supplied the component, what license it uses, the version number, any known vulnerabilities, and a list of all the component’s dependencies.

Most SBOM tools that exist right now, focus on showing customers some of the open-source libraries that they are using in their applications.  Moreover, most SBOMs are stand-alone JSON documents and by themselves don’t provide much value.  Even worse, many SBOMs are created once and then never updated so they quickly become out of sync with the actual application they are supposed to describe.

What’s in the SBOM lifecycle?

Most SBOM advocates believe that SBOMs should be automatically created during deployment, and should be as descriptive of the actual application as possible.  To do this, organizations need to have a process that identifies applications, creates SBOMs and then makes them available for the business to gain value from.  We believe the best way to do that is to create a SBOM lifecycle policy.

There are five stages in the SBOM lifecycle: Asset discovery, application data analysis, SBOM creation, SBOM storage and SBOM searchability.

Let’s go through each of these stages one at a time.

Existing asset discovery or attack surface mapping tools can help find assets but what do you do with the list that these tools have generated?  Most of those tools don’t have any SBOM functionality, so how do you get the list of assets into your SBOM creation pipeline?  It’s better if your solution can find your assets, show them to you and allow them to create a SBOM from that same workflow.

Imagine if you had this functionality back in December 2021 when the Log4j zero-day dropped!  Wouldn’t it have been nice to go to a central place you could go and say “hey, tell me all the places that Log4j is being used and what versions they are!”

Tying it all together

Building a complete SBOM lifecycle can be a challenge, but in the end, the value that it provides to organizations is enormous.  Simply having the ability to quickly find all the software and application components in your estate of apps is huge.   But even better, being able to query that data for vulnerable components could save organizations millions of dollars in lost productivity.  

Native SBOM lifecycle

You can build your own SBOM lifecycle or alternatively, SecureStack automates the whole process from end to end.  Our platform delivers all stages of the SBOM lifecycle in a fully integrated solution that is incredibly easy to onboard. Our platform provides an end-to-end SBOM solution that helps organizations address software supply chain risks holistically.  We find all your application assets, automate the creation of your SBOMs, store them for you in a secure central repository, and make them searchable.

Our role-based access control means you can give your security and engineering teams access to those pieces of the SBOM lifecycle that they need.

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

The SecureStack team has been working on this release for months as we were introducing several new concepts which meant we had to rearchitect many parts of the platform.  But most importantly we are introducing several new pieces of functionality in this release.

Role-based access control

The first of these new features is our new Organizations functionality which allows you to create a SecureStack Organization and share access to that Org with your teammates, partners, and compliance bodies.  Initially, the Organization functionality will allow the creation of users with 3 roles:  Owner, Admin, and User.  However, over the next two months, we will introduce even more granularity around access controls.  As an example, we want you to be able to share just the compliance report for one application with an auditor or partner and not the whole application.

Software bill of materials (SBOM)

We’ve been working on this feature for a long time and this feature is incredibly important to us.   The reason it’s so important is that we don’t believe that the SBOM tools that exist today are giving customers what they really need, which is a comprehensive “ingredients list” of their software.  Instead, existing tools focus on showing customers *some* of the open-source libraries that they are using in their applications.  Unfortunately, that’s like showing someone a wheel when they really want to see the whole car:  its just a small part of a larger, more complex thing.

Continuous Compliance

SecureStack is the first platform to provide its customers with real-time compliance reporting on their software development lifecycle (SDLC).  Every time your CI/CD pipeline is run we take a snapshot of the application’s compliance exposure.  SecureStack can map your SDLC to ISO27001, SOC2, CIS and the Australian ISM.  

SecureStack provides security coverage across the whole of your SDLC

Our platform helps you protect your most valuable asset:  Your source code.

SecureStack is easy to use as it’s a SaaS-based platform so you can be up and running in less than 3 minutes with complete coverage.

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

Enforcing HTTPS is a lot harder than most people make it seem

So, lemme break this down into the 7 (yes 7!) different things you are gonna need to have configured to meet the requirement in the top paragraph:

1. create the unencrypted “origin” service
2. create a load balancer, CDN or other service to answer inbound encrypted requests.  If you are going to do this all on one server it’s harder to get this all right.
3. create a valid certificate for the encrypted endpoint whether that’s on an origin server, load-balancer, CDN, etc
4. redirect requests from port 80 to 443 preferably at a load-balancer.  If you do this on a server, make sure that you are redirecting all inbound HTTP to HTTPS.
5. if you are using a load-balancer or CDN make sure that you firewall the origin server or service so that clients can’t connect directly to it and bypass the control.
6. check that all links (especially external links!) in your app or website are using HTTPS (ie., https://cdn.google.com/images/profile_pic.jpg)
7. enable HSTS which will *enforce* the “https://” part which means that if you haven’t ticked the box in #5 above you will get a HTTP error

See, not so easy!  Unfortunately, many security frameworks gloss over this complexity so the people actually implementing the control aren’t aware of how complex it is to “serve HTTPS exclusively”.

How do I enforce HTTPS?

Enforcing HTTPS is harder than it sounds and most software engineers don’t realize the complexity

,

SecureStack provides security coverage across the whole of your SDLC

Our platform helps you protect your most valuable asset:  Your source code.

SecureStack is easy to use as it’s a SaaS-based platform so you can be up and running in less than 3 minutes with complete coverage.

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!