[0:15] First of all, welcome everyone to our webinar. Today we’re going to talk about understanding and implementing SaaSBOMs for enhanced resilience, focusing on the newest release of our SaaSBOM and how it relates to the SBOMs you’re familiar with, but also taking it further into building an actual pipeline bill of materials: understanding more...
[0:15] First of all, welcome everyone to our webinar. Today we’re going to talk about understanding and implementing SaaSBOMs for enhanced resilience, focusing on the newest release of our SaaSBOM and how it relates to the SBOMs you’re familiar with, but also taking it further into building an actual pipeline bill of materials: understanding more than just the libraries, including the connected SaaS elements and APIs, so that as we expand the inventory and visibility we have a complete view of everything that’s happening. Please ask questions during the session. Quick agenda: we’ll start with the story everybody’s been talking about from last week and deconstruct it simply, then provide key takeaways, lessons learned, and practical guidance you can use today; then we’ll introduce our newest SaaSBOM and explain how it relates to the Sisense breach; and finally I’ll demonstrate the practical best practices, including the SaaSBOM.
[2:06] I want to start by revisiting our mission. Our vision is to eliminate manual AppSec. We see manual AppSec as creating considerable disruption in the software development life cycle; it dramatically slows the pace of innovation, makes hiring and retaining skilled personnel difficult, and prolongs the process so that only at the end do we get results, leaving friction between teams. The goal is to eliminate the dependency on manual AppSec practices that hurt speed, scalability, and innovation.
[3:30] The story started on April 11th, when CISA, the Cybersecurity and Infrastructure Security Agency, issued an urgent advisory for Sisense customers: they needed to reset their credentials following a security breach. The incident underscored the susceptibility of companies to software supply chain attacks, where compromised software, in this case the Git environment, was exploited to allow attackers to infiltrate other areas, in this case the S3, and exfiltrate data, potentially causing widespread consequences. The CISA alert urged customers to reset credentials and secrets, and noted two aspects: first, reset the credentials and secrets potentially exposed; and second, investigate any suspicious activity involving potentially exposed credentials.
[4:58] If we deconstruct how the attackers worked, simplified: first, they gained access to Sisense’s self-managed GitLab. We don’t have all the details, but they probably had some username, password, or access token, or a way to access the self-managed GitLab, perhaps from an internal network or a bridge system. Once they had that access, they found a hardcoded token for an Amazon S3 bucket in the cloud, and the token was active. They were then able to use it to access the S3 and exfiltrate terabytes of data, including access tokens, passwords, and SSL certificates. We don’t know the full scope, but the issue Sisense sent to their customers is really an in-depth rotation and change of certificates, passwords, and tokens.
[6:36] So what does a company need to do? If you’re a Sisense customer and you know it, these are the actions to take. But if you’re not sure where Sisense is connected in the code, this is where the SaaSBOM comes in handy: you can look into your entire organization and know exactly where different SaaS applications are connected, and find those secrets from a single screen. Instead of going through development to understand where it’s connected, maybe in undocumented places, you have that ability, and then from the platform you can open tickets and start rotating all the secrets, reducing your exposure.
[7:48] Let’s move to three key takeaways and recommendations, divided into the three elements I spoke about. First, attackers gained access to Sisense’s self-managed GitLab; this was the attack vector. We’re not sure how, maybe a phishing campaign, an insider threat, or other means. So first, I’d look at Git posture and access control: enabling MFA and providing strict access control and permissions narrows the attack surface and your exposure, because this isn’t a vulnerability, it’s exposure. Second, we see a lot of admins or leftovers in Git, so make sure the relevant people are admins, monitor usage, and understand if someone is connected who shouldn’t be. Going further, detect and prevent repo forking, so admins or people don’t fork the repo or copy the code elsewhere; disable repo forking and only enable it when needed.
[9:30] The second recommendation ties into the hardcoded secret found in code and used to access the Amazon S3 bucket. We want to know if we have hardcoded active secrets. If a secret is not active, it’s more of a hygiene aspect; if it’s active and hardcoded in code, it’s a problem. We also have git history and echoes in the pipeline; even if you removed it from code, if you didn’t rotate or revoke it and it’s still echoed, attackers might see and use it. So if you have an active secret in code, look at history and the pipeline to ensure it’s not echoed. Second, monitor and enforce the usage of secret management. One quick win with OX: once you connect OX, we immediately look for secrets and tell you which are active, which are inactive, and show generic secrets. If you have hundreds of those, the problem isn’t the actual secret, it’s the usage of secret management in your development environment, a much broader risk, so education, awareness, and enforcement matter. And finally, prevent hardcoded active secrets by integrating OX into your pipeline: if we detect an active secret, we can block the merge or the build.
[11:54] The third part is access to the S3 bucket. From this perspective, a SaaS service we use has been breached; we understand from Sisense that we need to rotate, revoke, and replace secrets and certificates. So as the person responsible for security, I need to locate first whether we were using Sisense, where, and when it was integrated. This enhances my security response and risk management to incidents that happen outside my company but are connected to me, helps me stay compliant with regulatory requirements, and helps me understand Shadow SaaS, where SaaS services are integrated or connected to our code that we don’t necessarily know about. This can create violations in compliance and regulation that we usually only see after an audit, exposing us to fines or even losing certification. Finally, when looking at software supply chain, we want to provide transparency, and to achieve that, as a security practitioner and from a developer perspective, I need to understand all the services connected to my code.
[14:04] Having read the incident breakdown and our recommendations, I want to first introduce the SaaSBOM: what we’ve released, why it’s important, and what to do with it. The SaaSBOM is the extension of the traditional SBOM principle. Even an SBOM is constantly changing and dynamic, and we need to extend our reach, because it’s not just open-source packages and libraries in code, but the entire environment, from the development environment to other connected SaaS applications, which constantly change. Once there’s an alert or a breach, it takes a lot of time to find where those services are connected, whether you’re exposed, and what mitigation you need. The SaaSBOM provides a comprehensive inventory that lists and documents all the SaaS components that interact with your software, application, and environment, so you can understand the SaaS, the vendor, the integration points, and where it’s found, with quick evidence to scope what you need to do, in seconds rather than hours or days.
[16:00] Why do I want a SaaSBOM? First, it’s an essential part of every application security strategy, no longer just nice to have, similar to what happened with the SBOM. It provides visibility and clarity into all the SaaS products and how they’re connected to your system. Second, it helps with security and risk management: when an incident happens, you can quickly search and see your exposure level and a plan to mitigate it. From a compliance perspective, it helps you stay compliant and understand the compliance level of the vendors you’re connected with; if you lose a certificate, you lose business. From a cost-management perspective, it aids in tracking usage and subscriptions; working with finance, you might discover you’re paying for a SaaS service for an application that’s no longer running, and free up that budget. And from a disaster-recovery and business-continuity perspective, when you hear about breaches like Sisense, you can immediately understand your exposure, how much work it’ll take, and whether you can mitigate it or stop using the service, keeping the business running and maintaining trust and transparency with your customers, which leads to more business.
[19:21] The strategic advantage: you can streamline vendor approval, because when a new application connects to a new SaaS service you didn’t know about, now you do, before the application is in production rather than after the fact or through an audit. You can proactively discover rogue applications and Shadow SaaS, and work with development to say a service won’t work for compliance or breach reasons. You can enhance data governance practices and vendor relationships, with insight into data exchanges with active vendors, and cut them down if needed, achieving transparency in data handling in minutes rather than days, just by connecting OX. Now let’s dive into the SaaSBOM in action and how to use those practical recommendations.
[21:01] Moving to our dashboard: you can see the new feature release banner. As you connect to OX, the first thing you’ll see is the entire pipeline bill of materials; the middle is the visibility aspect, done through connectors. If you use GitLab, similar to Sisense, with an identity provider token, or the GitHub app, Bitbucket, or other source control, once you connect, we deploy our own OX native scanners and start providing code security, secret scanning, PII scanning, open-source security, SCA, SBOM, and infrastructure-as-code. When you connect your CI/CD we provide the posture element, including showing if you have secrets echoed in the pipeline. With the registry we scan containers and show artifacts, and from cloud deployment you can connect a commercial tool or the OX cloud scanner. Once connected, we map everything. The top-left is issue prioritization: looking at all the original alerts, aggregating and de-duplicating is easy, everybody does it; the special part is our prioritization, how we enrich and consolidate the data, with real customer data showing more than 97% reduction in noise. I want to focus on three aspects, starting with the SaaSBOM, our new feature. On the BOM screen, part of the PBOM, we show the SBOM, the API BOM, and our newest release, the SaaSBOM. This is a simple demo environment; in real environments you’ll see much more connected. You can see the different SaaS services, the top categories, the app name and where it’s connected, and you can go directly to the application; the tags in every application also indicate the actual SaaS services, so you can filter on those tags from the application page too.
[24:43] On the SaaSBOM you can see the detection source: different types of evidence and where it’s connected. If you’re using Sisense, we show the applications and the exact locations and files where Sisense is connected, which you can see in the code. So you can understand all the locations, not just for a specific application but everywhere in code where, in this case, it needs to be handled, for any type of SaaS or application. You can filter by SaaS category or SaaS name; in your organization this list will be much larger, but you can filter for Sisense, see all the evidence and apps, and start monitoring, exporting, or opening tickets. The detection also helps me understand which applications are connected, so I can filter by a specific application and see, from an application perspective, the different SaaS services connected to it. This gives a good overlook on my critical assets, because not all repos have the same priority. So I can start not by a service but by an application, from the SaaSBOM screen or the application page. We map all your applications automatically and tag SaaS services in your code; we assign a business priority score per application, understanding when the last code commit was, differentiating between deployed applications and code that was built but not deployed, and the criticality. So when you need to rotate or revoke secrets, start with the deployed products you’re actually using.
[28:16] On Git posture: the initial Sisense read started from a self-hosted GitLab. When you connect OX, you can look at Git-posture elements; for example, we can see multiple admins for a repo, and you can reduce that directly from the platform, assigning read/write, removing users. So if you want a better posture for your Git without going repo by repo, you can see the areas that require attention, in GitHub or other tools, look at the number of admins, and reduce it or keep some users read-only. Furthermore, you can see that 2FA is not enforced, probably one of the issues with Sisense, as the attacker was able to infiltrate and get access to the repo; you can enable two-factor authentication so that even if a password or token is stolen, it’s harder for an attacker to use it. You can see other posture areas, for example outside collaborators on a private repo that’s a fork of the organization; we talked about repo forking, so you can understand you might have a code leak, and make sure the forked repo is private and the outside collaborator is still approved. From a CI/CD posture perspective, we can see cases where secrets are echoed in the pipeline, which is important to fix; we provide recommendations and guidance for every issue. The first attack vector is gaining access to your code; this is how you minimize that risk, and from there you monitor for changes.
[32:00] On secrets in code and hardcoded secrets: we also have OSC&R, a MITRE-like framework with the same tactics and techniques for software supply chain security, similar to what MITRE did for cloud, network, and mobile. You can map all the issues to the attacker’s point of view. Here we look for compromised tokens; it doesn’t mean you have a compromised token, just that an attacker could compromise an active token. The first one here is an AWS secret key found in a public repository, a critical issue; if that key is active, and we can tell you whether it is, this is something you need to immediately revoke, after handling it operationally so the application still works, releasing a new version with a new secret not in code, using secret management the right way. You can see different types of secrets and the evidence we provide: the commit, the type of secret, and where it is. You can see compliance elements, the app, and the flow, and we provide a graphical representation of the entire issue, with something really cool coming in a few weeks. The opposite example is a hardcoded secret that is inactive: we show the commit and where it is, but it’s more of a hygiene issue, because we validated that the secret is inactive, so you’ll probably remove it from code anyway. So two things: understand that you have active secrets, where they are and who needs to fix them; and reprioritize the inactive secrets automatically, because in a real environment you’ll have hundreds or thousands, and you want to focus on the active critical ones, so that even if someone gets access to your code, they can’t move laterally easily.
[35:51] To summarize the practical aspects: from the different attack vectors, the lesson from the Sisense breach is to have a SaaSBOM that shows, in case a vendor you use is breached, the implications and risk you’re exposed to and how to quickly mitigate it. From the attack itself: from a posture perspective, understand your Git posture, reduce the number of admins with strict access, enable MFA, disable repo forking, and enforce other posture areas. And the right way to handle secrets is not to put them in code, even though it’s easy; enforce that development mentality and awareness that one secret in code can create a lot of mess for you and for other companies.
[37:11] Let’s stop here. If you have any questions, please write them in the chat or Q&A. I see there are no questions, which is good, and not so good depending on the audience. I’d like to thank you for listening and help you take the next step: from OX, go to ox.security, click login, and start free; you’ll connect your environment in about five minutes and scanning will start automatically, showing results from posture, secrets, SaaSBOM, SBOM, SCA, and a lot of other capabilities. Or feel free to book a demo with one of us and we’ll deep dive and help you get started. Thank you very much for attending and listening, and I’ll see you in our next webinar.
