Complete security coverage for Azure DevOps

by Paul McCarty | Dec 14, 2022 | Application Security, Blog, developer insights, DevSecOps, SMB Security

SecureStack is excited to announce that we now support Azure DevOps through the use of our native Azure Pipelines templates!

SecureStack provides comprehensive security coverage with our brand-new Azure DevOps integration. Our customers asked us to support Azure DevOps so we’ve delivered! You can now generate a custom pipeline template document right from the SecureStack SaaS web portal and copy that directly into an Azure pipeline and have it work. No changing it to work or customization is necessary. Just drop it in and it runs!

One Pipeline: Complete security coverage

SecureStack provides complete coverage for your Azure DevOps Pipelines and the associated secure software development lifecycle (SSDLC). As part of our native Azure DevOps Pipeline workflows we provide:

Secrets and sensitive scanning
Scanning for vulnerable third-party or open-source libraries
Dynamic application security testing for any web or API endpoints
Scanning for misconfiguration in your public cloud resources
Asset discovery and attack surface mapping for your public assets

Once all those tests pass, SecureStack will package up a software bill of materials (SBOM) for the application environment, and there you have it: Complete Security Coverage for your SDLC!

See how it works –>

If you like what you see, book a demo!

Book Demo!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

Comprehensive SBOM

by Paul McCarty | Oct 23, 2022 | Application Security, Blog, developer insights, DevSecOps, SMB Security

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.

What is a comprehensive SBOM?

As we said above, modern applications are complex and use components other than open-source libraries. These apps use third-party APIs, SaaS providers, and cloud-native resources, among other things. This data needs to be collected from the target application and used to provide a better more realistic SBOM.

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:

Data from source code, third-party APIs and SaaS dependencies as well as any cloud-native and identity providers that the application requires.
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.
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.

See how it works!

If you like what you see, book a demo!

Book Demo!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

The SBOM Lifecycle

by Paul McCarty | Oct 14, 2022 | Application Security, Blog, developer insights, DevSecOps, SMB 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.

Asset discovery

You can’t onboard what you don’t know about. This stage is all about helping the customer find the applications they need to ultimately provide an SBOM for, which hopefully, is all of them. Most companies only know about 50% of their public-facing application names. The other 50%? Well, that’s the problem. Finding assets with domain names like app.niftybank.org and api.niftybank.org seem obvious but how do you find the less obvious apps?

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.

Application data analysis

In this stage, the data that is needed to create an SBOM is collected about the target application. Historically, SBOMs got this info from package manifest files, but now, that’s typically not enough. Modern SBOMs are able to incorporate data from cloud providers, third-party services and SaaS solutions in addition to source code.

SBOM creation

In this stage, the actual SBOM file is created and will include all the relevant application data. Typically, you will want this to happen every time your engineering teams deploy a new version of the application. After all, if you aren’t building a SBOM every time you deploy a new version, is your SBOM going to match the state of your production app? The only thing worse than no SBOM, is a *wrong* SBOM.

SBOM storage

SBOMs need to be stored somewhere centrally and protected with a rich authorization layer. This centralized storage can be an S3 bucket or other secure managed file server, but make sure that they’re stored in an encrypted manner! Otherwise, you might run afoul of compliance requirements!

SBOM searchability

Finally, customers need to be able to search across some or all of their SBOMs. Ultimately, all the steps before this one led to enabling this functionality. This searchability is the most important aspect of the SBOM process because this is the central source of truth. This is how you look up vulnerable software in your environment and find which applications to tackle.

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.

See how it works!

If you like what you see, book a demo!

Book Demo!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

SecureStack is sponsoring NDC Sydney 2022!

by Paul McCarty | Oct 10, 2022 | Application Security, Blog, developer insights, DevSecOps

SecureStack is super excited to be a gold sponsor for NDC Sydney 2022. NDC is a global high-end conference for software developers. We will be on the main floor right behind the registration area at booth #8. Our CEO Paul McCarty will be there as will some of our customer success engineers.

We will be giving away a brand new super rare “Back to the Future” DeLorean LEGO set while we are there! To be added to the draw all you have to do is create a free account in the SecureStack web portal (https://app.securestack.com) and create at least one managed app.

The drawing will be held at 2:50pm on Friday the 14th. You must be there to win.

You can learn more about NDC at https://ndcsydney.com/

If you like what you see, book a demo!

Book Demo!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

What is a SBOM?

by Paul McCarty | Sep 5, 2022 | Application Security, Blog, developer insights, DevSecOps

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 government gets involved

Risks against the software supply chain are increasing. One of the problems historically has been a lack of visibility into how your vendors or partners create the software products you consume. The Solarwinds hack and the ongoing struggles for package managers like NPM prove that this part of our ecosystem needs better protections.

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.

The UK government is thinking about how to create supply chain protections including SBOMs. The UK government is seeing opinions and looking to build a working group which you can read about here.

It is reported that the Australian government is going to mandate SBOMs for critical infrastructure organizations later this year. This will be a multi-stage process and will eventually mandate SBOMs for organizations of a certain size or in specific industries. This is an important step and will force many Australian organizations to learn about and implement SBOMs.

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:

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.

If you like what you see, book a demo!

Book Demo!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!