One of my friends messaged me on LinkedIn today and asked “What is this SBOM you keep talking about?”  I realized that he’s right and I should probably explain what an SBOM is.  So, let me start by defining the acronym: SBOM refers to a “Software Bill of Materials”.

An SBOM is a complete inventory of all the software and dependencies of an application and is typically delivered in the form of a JSON or XML document.  Although, for some vendors, the “SBOM” is really just their web portal and not a deliverable file.  This matters as many customers are looking to provide SBOMs for compliance requirements made by partners or customers.  In most cases, the requestor is looking for a file to be delivered, and at some point, inspected for accuracy.

Why is an SBOM critical?  Well, one reason is that they provide visibility into what is actually *inside* an application, but it also helps identify the software supply chain underpinning a particular application. 

Wikipedia defines an SBOM this way:
“A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product.  It is analogous to a list of ingredients on food packaging: where you might consult a label to avoid foods that may cause allergies, SBOMs can help organizations or persons avoid consumption of software that could harm them.”

Why is everybody talking about SBOM now?

The need for something like an SBOM specification has existed for a while now but has become more necessary in the last two years driven by several high-profile security incidents. In particular, the SolarWinds incident in early 2020 as well as ongoing issues with NPM have made it obvious that there needed to be more governance around the software supply chain than there was.

Applications have become increasingly complex which in turn makes securing and managing those applications more difficult. Cloud-native services and open source make up a growing part of the average modern web application. Software engineering teams don’t necessarily understand how adopting these new technologies or services changes the threat model for their applications. The SBOM is meant, in part, to at least make these components visible to the naked eye so teams can understand the scope and breadth of their applications.

But modern applications are complex and include dependencies outside of the libraries that traditional SBOMs cover. Modern apps use multiple languages, third-party APIs, cloud-native services, and a lot more. Unfortunately, most SBOMs don’t address any of these additional dependencies or the vulnerabilities in them either. So we need to expand the idea of an SBOM to include all of the other resources and dependencies in

The Biden administration passed an executive order in 2021 entitled “The Executive Order on Improving the Nations Cybersecurity”. This executive order requires that any companies wishing to sell to the US government must meet SBOM requirements.

What’s in an SBOM?

This is a tough question because not all SBOM tools agree on what should be in an SBOM.  At its simplest, an SBOM is a list of all the different component parts of an application.  So think of this as an index of all the dependencies built from a package manifest file.  That’s really pretty simple and doesn’t really offer any additional functionality or benefit of simply using the package manifests themselves to derive this information.  This is why most modern SBOM specifications include more info than just the package manifest.  Things like the dependencies of a package should be understood and cataloged too.  Many developers don’t realize how many additional pieces of software are being pulled into their projects because of dependencies, so this function is important.

I think most modern SBOM specifications agree on many things that should be in an SBOM.  This typically includes several types of information about each component:

• Component name
• Supplier or vendor of the component
• Software license type
• Component version number
• Known vulnerabilities for component
• Transitive dependencies to other software

Defining these core data points about each application composition object means that engineering teams are in a better place to be able to mitigate or remediate issues in these components. Tracking this information over time means that a properly built SBOM will catch and make visible any changes that can adversely affect the application.

How do you create an SBOM?

Because there are several different formats for SBOMs organizations will need to make a decision on which they will support internally. Or, alternatively, they will need to have the right data in place to create any format they are asked for.

Unfortunately, there is no consensus on what an SBOM should look like or include. There are LOTS of suggestions, and vendors describing their way as the only way to create and handle SBOMs. The reality is that there are at least 3 different formats for SBOMs:

• CycloneDX
• SWID
• SPDX

It’s important to note here that the SBOM specification or format, and the tool that is actually creating the SBOM are totally different.  The former is the agreement of what should go into an SBOM and the latter is what is actually *put* in the SBOM.

Use Cases for SBOMs

The traditional use case for a SBOM is to provide a list of ingredients for an application. Typically, a software engineering team will own that use case and create SBOMs to store them for future reference.  However, the idea of what a SBOM is has evolved.  SBOMs have become less of a point-in-time snapshot and become more dynamic.  SBOMs should be generated everytime an application is built and deployed.  This allows organizations to track how their applications are changing over time with more granularity.

Engineering teams and security teams will have different use cases depending on what those teams roles are.   In my conversations with security architects, their need for SBOMs is different.  One of the best infosec use cases will involve giving infosec teams a searchable index of all applications so they can search it anytime there is a new software vulnerability disclosed.

Remember back in December of 2021 when the log4j vulnerabilities went public and the world freaked out right before Christmas.  Teams spent days searching for applications that had log4j in them.  Imagine instead if you had a central repository of SBOMs and could simply search them for log4j and get back a concise list of where log4j was used and what version it was.  I can tell you from personal conversations I’ve had that would have saved thousands of hours of work by security and engineering teams globally.

SBOMs will evolve to become “Application Bill of Materials”

Software bill of materials (SBOMs) are a great way of capturing the software components and libraries that an application uses at a specific point in time. This gives the consumer of the software assurance that it is secure and built well.

Unfortunately, SBOMs don’t really capture the complexity of the modern application as those applications use multiple languages (monorepos, SSR), new types of infrastructure (Kubernetes, containers, serverless), third party services (Auth0, Stripe, analytics) and use cloud native resources from AWS, Azure and others. So we need to expand the idea of an SBOM to include these new components and evolve into an “Application Bill of Materials” or ABOM.

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!

Other than that, there are no other details, which is a bit concerning.  But, let’s take this at face value right now.   According to the LastPass press release no passwords appear to have been stolen or accessed.  This is a good thing!  Unfortunately, this type of attack is potentially more dangerous than a data breach where a set of point-in-time passwords was stolen.  Let me explain why.

How could this be worse than my passwords being stolen?

This attack appears to have targeted the LastPass development environment where the company writes, stores, and manages its source code.  It’s essentially where all the intellectual property for a software-based company is stored.  And the reality is that most companies are software-based now, with most of their revenue and growth tied to their software-based systems.  This centralized storage of a company’s intellectual crown jewels is a very sexy target for criminals.  Unfortunately, as we’ll see below, this core IP is not as protected as other parts of the IT infrastructure.

Developers are the best place to target it you want to own someone

Software engineers have access to the source code for the platforms they work on.  For LastPass that access probably includes how things like encryption of passwords are performed, when MFA challenges are performed and how LastPass detects anomalies.  Thes are core fundamentals of how the LastPass Vault works.

All of that is speculation, and hopefully, that’s not what’s happened with LastPass this time.  But the reality is that access to source code is one of the most sensitive things you can get, and yet we don’t generally protect it very well.

Okay, if it’s so easy to phish developers, what other security controls can we use?

The reality is that developers don’t typically use any other security controls other than a username and password, which we’ve just shown are under constant attack.  The centralized versioning system that most developers use is called Git and it has several security functions built into it.  Unfortunately, most development teams don’t take advantage of these security features, so if you can successfully phish them you are in.  I can’t say this is how the LastPass incident went down, but it’s certainly possible.

Contrary to what you might have heard, security is relatively easy to add to developers workflow

There are many security controls that software engineers can use to secure how they write, test and deploy code.  Even better, many of them are simple, easy to implement, and are automatable.  Why then do so few devs actually use these security controls?  In my experience, it’s a cultural thing.  They aren’t incentivized as software engineers to prioritize security, so they don’t.  We need to change this culture and instead help devs understand that if they use these security controls, we are all better off.

You can find the Playbook at: https://github.com/6mile/DevSecOps-Playbook

The DevSecOps Playbook is 58 controls and is very detailed and prescriptive.  If you are looking for some simpler tips you can use to protect your software engineers from the same thing happening to you that happened to LastPass, we’ve got you covered!

6 easy things to increase source code security

Enable MFA for SCM

Bitbucket, GitHub, and GitLab all support the use of MFA for logins.   This simple security control means that there’s more than just a crappy password between your source code and attackers.  Even better, if you use GitHub or Bitbucket or GitLab for SSO to other platforms the requirement to use MFA at login will propagate across automatically, providing security there too.

The obvious limitation with this method is that you are only going to get an MFA challenge when you log in, so doesn’t provide any security when you are actually interacting with code (pulls, fetches, clones, etc).  That’s why the next option is particularly important.

Use SSH keys to interact with SCM

There are two protocols that are supported when you interact with source code in your SCM.  The default is HTTPS which is encrypted but doesn’t offer any additional security.  The other option is to use SSH for transport which requires SSH keys as it’s PKI based.  This is significant as you can change, expire, and update your keys based on company requirements.

My team has gone even further, as we use an app that manages SSH private keys behind an MFA challenge.    This means that each time we push code we get a challenge on our mobile devices.  Combining this control with the first one (MFA) adds a layer of security that is very powerful.  You can see how to add SSH keys to your GitHub account here.

Signed commits

When an engineer makes an important change to source code they will “commit” that code to version control so it’s protected.  Unfortunately, by default git just keeps track of the author via the email address of the author which can be easily faked.  If you want to verify that the person pretending to be linus@linux.org really is Linus Torvalds, then you need to sign your commits with GPG. It takes 60 seconds to set up and then can be easily automated so that every commit is signed.  Find out how to sign commits here.

Scan your source code for vulnerabilities

While this control wouldn’t have stopped the LastPass hack, it’s still a super important security control.  Good engineering teams will use software composition (SCA), secret scanning tools, and static analysis (SAST) code scanning solutions in their local environments.  It’s super important to scan source code for issues when it goes through your CI/CD pipelines, but it’s important to do on your developer’s laptops too.  Git provides an automated function to do this when you commit code with something called a pre-commit git hook.   Unfortunately, a lot of engineering teams are NOT running security tooling on their laptops so there is no way to stop security issues or malicious code from getting into the centralized source control system.  Yes, you can eventually remove it there too, but it’s a lot harder to do than if you stopped it before it got there.  I like to use the analogy of someone poisoning a city’s water supply.  It’s a lot easier to stop them from pouring the poison into the lake than it is to take the poison OUT of the lake.

Sync your SCM provider to AD

One of the common themes I see is that enterprise orgs will use a cloud-based SCM like GitHub or Bitbucket, but not connect their active directory to it (usually because of cost).  Because they aren’t linked, the users in the SCM platform must be managed separately.  This causes challenges as users have to manage two separate sets of credentials, one for AD and one for SCM.  It also means that accounts are often out of date with people still having accounts in SCM when they no longer work for the company.  Onboarding, off-boarding, password resets, and everything else is more complicated in this scenario.

Security training for your software engineers

Because of the unique security challenges presented to developers, they need specialized security training.  That’s why we use partners that teach how to create more secure code, but also how to secure the systems they use to manage the code.  Reach out to me if you would like an intro to one of our partners that does this.

SecureStack provides automated security for your software engineers

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!

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!

You can think of the ISM as a single document that helps Australian businesses and government know how to address cybersecurity challenges.  In reality, the ISM is really a collection of different guideline documents that focus on specific areas of IT.  Some of the existing guidelines address things like system hardening, database management, network management, using cryptography, and many others.  These guideline documents as an aggregate can be thought of as “the ISM” and can be used to increase an organization’s cybersecurity maturity which benefits both the organization itself, but also Australian society.

What’s in the Guidelines for Secure Development section of the Australian ISM?

In December of 2021, the ACSC released the latest version of the ISM which for the first time included a Guideline for Secure Development.  This document lays out a framework for building and maintaining secure software development processes.  It is a total of 21 controls and is more prescriptive than what we typically see from other frameworks like APRA.

You can find the Guidelines for Secure Development here: https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-software-development

The format for this blog post

I wanted to write this blog post to help Australian orgs know about this new compliance requirement from the ACSC.  The new Guidelines for Secure Development document is split into two sections which we’ll address separately below.
Those two sections are:  Application development and web development.  

We’ll break both of those two sections down into their individual sub-sections and the controls that exist at each one of those stages. At the end, I talk about how you can assess and implement the controls in the ISM.

From this point on I’ll refer to the Guidelines for Secure Development as “GSD” for brevity’s sake.

Okay, let’s dig in!

Section 1: Application Development

This section of the GSD is applicable to all forms of software development including: client/server, web and mobile.  So special emphasis on this section should be placed on all assessments you make using the GSD.

Within this top level section there are 6 sub-sections:

• Development environments
• Secure software design
• Software bill of materials
• Secure programming practices
• Software testing
• Vulnerability disclosure program

Development, Testing, and Production Environments

Segregating development, testing, pre-production and production environments into discreet separate workspaces is one of the core security principles of secure software design.  This segmentation can limit accidental issues and malicious attacks from spreading from one environment to another.  Software engineers are limited to dev and testing environments so that bad code or third-party issues can’t be added to production directly.

Software Bill of Materials (SBOM)

This section only has one control and it’s all about SBOM.  SBOM stands for “Software Bill of Materials” and the reason that it’s so important is that it delivers something we never had had before:  a complete “recipe” of what is in an application.  An SBOM is a single source of truth for all software dependencies, frameworks, libraries, resources, and services that went into making a specific software solution.   Most definitions of SBOM agree on the above, but some go further and say that any known vulnerabilities and cloud-based services should also be included in the SBOM.  To me, this makes sense as an SBOM should be both an end-to-end description of the application, but also should list any deficiencies and liabilities.  If one of the components used to build an application has a known vulnerability, it should be codified in the SBOM.

Unfortunately, SBOM hasn’t delivered on its promise yet as very few organisations are actually creating SBOMs when they build software.  If you want to know more about SBOM please check out our blog post on them here:  https://securestack.com/sbom/

Even though there are only two controls here the description specifically calls out static analysis (SAST), dynamic analysis (DAST), web vulnerability scanning, and software composition (SCA) requirements.  It also calls out penetration testing and it also mentions “prior to their initial release and following any maintenance activities”.  To me, this sounds like automated tests during continuous integration and deployment (CI/CD). 

So that should really be 6 controls minimum.  I expect this to be fleshed out on the next version of the GSD.

Vulnerability Disclosure Program

There are actually four controls in this sub-section.  The first three are somewhat redundant switching the terms “policy”, “program” and “processes” which might confuse people.  Luckily the last control is straightforward and requires that orgs use a security.txt file to advertise their VDP information.

I think we can simplify this section in this way:

• Are security researchers able to come to your website and find how to contact you if they’ve found a security issue?
• Have you partnered with a platform to allow security researchers to bring security bugs they find to you?
• Do you have a set of documents that describe your security policies?  And can your employees find it?

Section 2: Web Application Development

This section of the GSD is applicable to applications available on the web that users interact with primarily via a web browser.  This section should be carefully following if you are building web apps.

Within this top level section there are 6 sub-sections:

• Open Web Application Security Project

• Web Application Frameworks

• Web Application Interactions

• Web Application Input Handling

• Web Application Output Encoding

• Web Browser-Based Security Controls

• Web Application Event Logging

Open Web Application Security Project

The OWASP is an organization that is trying to help encourage application security through its community and projects like Zed Attack Proxy (ZAP) and the purposefully vulnerable Juice Shop project.

This section has only one control and it explicitly states that orgs should be following the Application Security Verification Standard (ASVS) when building web applications.

Web Application Interactions

This section has one control and it’s pretty specific:  All web application content is offered exclusively using HTTPS.  That sounds pretty straightforward, right?

Unfortunately, enforcing encrypted HTTP traffic is more complicated than many people think and require multiple controls and functions to be aligned.  Engineers need to make sure that HTTP is redirecting to HTTPS, that HSTS is enabled and that SSL/TLS is terminated in a secure environment.

I wrote a blog post about enforcing HTTPS which you can read here: https://securestack.com/enforce-https/

Web Application Output Encoding

This section has one control which is:  Output encoding is performed on all output produced by web applications.  This is a necessary requirement as the use of un-encoded data can cause serious issues as special characters can be interpreted incorrectly by the web application.

Web application event logging

The final sub-section has two controls associated with it.  The first says that all access attempts and errors need to be logged.  The second, stipulates that all logs are stored centrally in another location.

Unfortunately, we see less web server and application logging than we used to.  In the era of the public cloud, many engineering teams misinterpret logging functions like AWS’s Cloudwatch and Cloudtrail which log events at the cloud layer, and NOT at the application layer.  To be very clear:  Enabling Cloudwatch and Cloudtrail are NOT effective application logging solutions.

How do we assess and implement these controls?

Okay, so now that we’ve laid out all 16 controls in the new Guidelines for Secure Development document, where do we go from here?   Well, part of the challenge of this new ISM document is that it spans across the whole software development lifecycle (SDLC).  It talks about things the developer needs to do (local software testing) and it talks about segregating deployment environments.   It talks about things that happen at the beginning of the lifeycycle, and things that happen at the end of the lifecycle.  It talks about how to build your web applications and it talks about how your customers should be protected while using that application in a browser.

How can SecureStack help you assess your ISM compliance?

The SecureStack platform can help you assess and quantify your ISM GSD compliance with our SaaS platform.  We help you integrate your source code platform, CI/CD processes, build environments and your public cloud providers, and we do it all in less than 5 minutes.

Thanks right!  You can see assess your entire software development lifecycle in less than 5 minutes with SecureStack.  Check out the video to the left to see how!

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!