Achieving basic IT hygiene is 99% of the game.

As your company's chief information security officer (CISO), you're responsible for IT and corporate security, as well as the safety and security of company data and assets. You navigate a fraud landscape of ever-changing and newly emerging threats, while analyzing, prioritizing, and communicating these threats to others at the C-level table. If security risks and vulnerabilities are not properly prioritized at an organizational level, your company is more vulnerable to breaches, hacks, and threats.

**A One-Stop "What If" Catalog of Risks**

Your risk register should serve as a standardized framework — a "what if" manual that includes current and potential security risks and how they could impact the organization. This risk register should identify threats, outline the probability they will affect your company, and illustrate the overall potential impact — and it should be continually updated. This inventory of risks may include risk description, cause, result, likelihood, outcome, and mitigation actions, all customized to your organization. Break out your risk register into sections that map to different business units and stakeholders (infrastructure, internal systems, physical security, etc.) and detail how each may be affected by various threats.

How do you decide what goes into your risk register? Much of that depends on your company's cybersecurity posture, identified risks, and potential risks. However, there are some general guidelines to keep in mind.

**1\. Zero trust is a must.**

Yes, hybrid work accelerates fraud. Many new technologies have come to the forefront as companies adapt and adjust to facilitating remote work for their teams scattered across the globe. We now live in an environment of heightened risk, new types of threats, and constant alerts. It's been a year since President Joe Biden issued a cybersecurity executive order outlining the importance of adopting a zero-trust cybersecurity approach, yet only 21% of critical infrastructure organizations have adopted such a zero-trust security model.

Zero trust is something security teams have been talking about for a few years. Think about how the "business perimeter" has changed with multiple teams, multiple devices, and multiple locations. Historically, many thought of zero trust as "trust, but verify." The new zero trust: "check, check again, then trust in order to verify." This means validating every single device, every single transaction, every single time.

**2\. Plan "outside the lines" when it comes to business continuity, disaster recovery, and potential cyberattacks.**

As you construct your risk register, there are remote workplace-specific items to keep in mind. Of course, you want to put security measures in place that will minimize downtime for employees. Bolster your identity and access management via methods such as multifactor authentication. Ensure corporate data is encrypted to prevent sensitive data from getting into the wrong hands. Also, consider current world events, global economic forecasts, and even unpredictable natural disasters, and how each may affect your company's operations.

**3\. Mind the gaps.**

The rise of remote work has corresponded with a rise in shadow IT — those devices, software, and services that employees adopt without IT department approval. The number of software-as-a-service (SaaS) apps running on corporate networks averaged three times the number that IT departments were aware of in 2022.

Here's the problem: You can't protect what you can't see. Shadow IT can introduce information security vulnerabilities in the way of data leaks, compliance violations, and more. As you enable your remote workforce to be more flexible in how they work, visibility should be top of mind. This is, of course, in addition to tightening up identity and access management across the board and doubling down on zero-trust policies.

You should be having continuous conversations with stakeholders to stay one step ahead of shadow IT and application sprawl. Consider creating policies that open a dialogue with IT and the rest of the company. These policies could also encourage employees to go to IT if they want to request a new application.

**4\. Seek the highest common compliance denominator.**

The current global data protection landscape is an ever-changing one, with several regulations, compliance initiatives, frameworks, and mandates (GDPR, FIPS, ISO 27001, SOC, FedRAMP, and more). And there are also country-, region-, and state-specific mandates, such as Brazil's General Data Protection Law and the California Consumer Privacy Act (CCPA).

So, how can you ensure your organization is compliant? Look for the highest common denominator across various regulations. Take bits and pieces from different mandates, regulations, and guidelines and wrap them into your own company's unique framework. You may take some regulations from the EU's General Data Protect Regulation (GDPR) that are more stringent, while taking other tougher regulations from Brazil's law. This way, you adhere to the highest levels of data privacy regulations in real time while supporting your global customer base.

**A Final Word About Basic IT Hygiene**

As you consider the guidelines above, remember this: If you properly patch your machines, keep a close eye on configuration management, and add/remove users in a timely manner, you are mostly there. Even though there will always be new challenges to address (new government mandates, compliance updates, potential security risks), achieving basic IT hygiene is 99% of the game.

Are You a CISO Building Your Risk Register for 2023? Read This First

Compliance activities are often viewed as frustrating but necessary. That's an understandable view as teams often have to apply a set standard to existing systems and figure out how to collect enough evidence to answer an audit.

Compliance activities are often viewed as frustrating but necessary. That's an understandable view as teams often have to apply a set standard to existing systems and figure out how to collect enough evidence to answer an audit.

That work requires a lot of documentation, verification, and digging up answers to questions long forgotten. Approaching compliance in this way — while common — does your security practice a disservice.

Let's ignore the word "compliance" for a bit. Can you answer this deceptively simple question: "Is your security practice doing what you think it is?"

Are the controls you've rolled out effective? Do other teams follow the appropriate process for changes? Can you follow a transaction across your systems to respond to an incident?

**Are We Supposed to Test?**

One area with a shocking lack of attention is testing, and that's probably because testing in development is always a challenging balance of effort vs. return. But at least within the build process, it's accepted that code and integrations must be tested.

When was the last time you saw a standardized regular security control test?

At best, teams will engage in a penetration test or a red-team exercise. While these are often a heavy lift, they often generate excellent results, even if they take a significant investment of resources and time. Unfortunately, you won't see that level of effort applied for each and every deployment to production.

If we keep digging, we'll find teams that do, in fact, have some testing integrated into the CI/CD pipeline. Vulnerability scanning and infrastructure-as-code (IaC) template scanning are the most common tools implemented here.

Vulnerability scanning aims to find known vulnerabilities in out-of-date software. These issues can often be addressed by updating code dependencies, applying a path to update key software, or rolling out a mitigating control elsewhere in the infrastructure.

IaC template scanning is looking for potential issues _before_ they hit production. Misconfigured permissions, gaps in logging, unencrypted connections, and other issues can be addressed by builders much easier at this stage when compared to addressing them in production.

But these two steps are often the end of any security testing. Why is that?

**Too Many Competing Priorities**

One simple answer is that it just usually isn't done. Security testing typically happens when evaluating a control or process but after that, the assumption is that it continues to work.

If you shuddered a bit at "assumption," you should. As a community of practice, if we want to keep our tin foil hats, testing should be top of mind.

Nothing is ever that simple, though. Testing security controls can be tricky, which makes figuring out how to automate tests even more challenging for teams that historically don't have a deep bench for development activities.

With the move to the cloud, the barrier to security testing has dropped significantly. We've seen the first steps with the inclusion of vulnerability and IaC scanning inside the CI/CD pipelines used by development teams.

It's time for security teams to implement regular testing not only in the build pipeline but in production.

**Simple Wins the Day**

Testing doesn't have to be complicated. Simple checks will go a long way.

Validating that a security group actually prevents access from unlisted IP blocks, verifying access for users and systems, making sure that logs are being written to the correct location, and other tests are a good place to start.

These basic checks provide a safety net beyond vulnerability and IaC scanning to verify that your security controls and processes are working as expected.

**What About Compliance?**

The bonus? That type of testing and verification _is_ compliance. When you peel back the layers, compliance activities are really just proving that you are doing what you said you were going to do.

Organize the results of these tests with compliance audits in mind, and you're doing the work as you go. That's continuous compliance. If you and your team can build that habit, it not only improves your day-to-day security practice, it will greatly simplify your compliance work as well.

This isn't a different approach to compliance; it's just a different way to look at it. Hopefully, it's a perspective that helps you understand the value.

Your next steps are to start to build and automate these simple tests, roll out tools such as vulnerability and IaC scanning, and start practicing continuous compliance.

**About the Author**

    

I'm a forensic scientist, speaker, and technology analyst trying to help you make sense of the digital world and it's impact on us. For everyday users, my work helps to explain what the challenges of the digital world. Just how big of an impact does using social media have on your privacy? What does it mean when technologies like facial recognition are starting to be used in our communities? I help answer questions like this and more. For people building technology, I help them to apply a security and privacy lens to their work, so that they can enable users to make clearer decisions about their information and behavior. There is a mountain of confusion when it comes to privacy and security. There shouldn't be. I make security and privacy easier to understand.

Security Testing Improves Headaches & Compliance

Bolster delivers intelligence and remediation across web, social media, app stores, and Dark Web, with 24/7, live SOC support.

**Los Altos, CA- October 20, 2022 —** Bolster, Inc., the automated digital risk protection company, today announced the addition of Dark Web Intelligence and 24/7 support. Bolster’s new Dark Web offering is the easiest to use actionable threat solution on the market - adding to the value of the entire Bolster product portfolio. Customers will have access to a comprehensive platform able to monitor and protect their brand across the web, social media, app stores and dark web; with access to experts 24/7.

Designed for actionable insight, Bolster’s Dark Web monitoring allows organizations to gather threat intelligence across the dark web and predict how threat actors will behave and act. Organizations can discover hacking tools, exploit kits, relevant chatter and how that affects a brand. The Bolster platform offers automated and curated responses that deliver the most effective risk mitigation strategy internally.

“Because the dark web can be a place of great intelligence on pre and post breach information, having dark web monitoring is essential to understanding threats to your brand,” said Abhishek Dubey, co-founder and CEO of Bolster, Inc. “We have designed our solution to be completely actionable by allowing customers to create curated, automated workflows when they spot a certain type of alert or activity. This allows for an easy method of both obtaining instant insight and responding quickly and effectively to threats.”

When a threat or suspicious activity is discovered, customers now have the ability to call a security expert 24/7 and 365 days a year. The 24/7 support offering provides the following services:

*   **Around the Clock Support:** Whether it be active online threats or questions about reporting, Bolster’s 24 hour, 7 days a week, 365 days a year SOC team support will put customers in direct contact with a security expert.

*   **Strategic Planning:** A dedicated, curated quarterly business review and executive reporting will be available to provide consulting, configuration strategies, best practices, strategic adversary services, and more. Strategic planning will help organizations plan for and mitigate future risks.

*   **Expert Management:** Bolster managed services allow customers to focus on their core business objectives while they handle the detection, monitoring, and takedown of threats to brands. Customers will have a trusted team of experts to navigate the digital risk landscape.

With dark web intelligence and around the clock expert support built into the Bolster platform, customers have the one consistent, intuitive experience to track threats across any online channel. Ease of use and a hands-off remediation process will help ease training and administration as well as refocus IT resources to other core business objectives. Bolster offers the industry’s best user experience for detecting, monitoring, and remediating digital risk.

For more information on Bolster, please visit: https://bolster.ai/

**About Bolster, Inc.**  

At Bolster, our mission is to make the internet safe for everyone. That's why we created the first and only fully automated platform purpose-built from the ground up to detect, monitor, and take down fraudsters on the Internet. We call it Automated Digital Risk Protection. Our comprehensive platform offers the most efficient protection across web, social media, app stores and the dark web to combat fraudulent sites and content. Bolster was founded in 2017 by security industry veterans with headquarters in Los Altos, CA. To learn more, go to www.bolster.ai.

Bolster Deepens Platform with Dark Web Threat Intelligence and 24/7 Support

CISOs and security leaders in state and local governments are dealing with increasing threats like ransomware — with varying degrees of cyber maturity.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

8 Trends Driving Cybersecurity in the Public Sector

The data exposure was the result of an "unintentional misconfiguration on an endpoint" and not a security vulnerability, Microsoft said.

Sensitive information for some Microsoft customers were exposed by a misconfigured server, Microsoft Security Response Center said on Wednesday. The misconfigured endpoint was accessible on the Internet and did not require authentication.

The exposed information included names, email addresses, email content, company name, phone numbers, and files "relating to business between a customer and Microsoft or an authorized Microsoft partner," the company said. The endpoint has already been secured to require authentication, and affected customers have been notified.

"This misconfiguration resulted in the potential for unauthenticated access to some business transaction data corresponding to interactions between Microsoft and prospective customers, such as the planning or potential implementation and provisioning of Microsoft services," Microsoft said, noting that there is no indication that customer accounts or systems had been compromised.

Microsoft learned of the misconfiguration on Sept. 24 from a research team at SOCRadar.

SOCRadar's researchers claimed in their own blog post to have found 2.4TB of emails and project files containing Statement of Work documents, product orders, project details, personally identifiable information, invoices, price lists, and "documents that may reveal intellectual property." The researchers claimed the exposed information could be linked to more than 65,000 entities from 111 countries.

Microsoft said SOCRadar "greatly exaggerated the scope of this issue" and did not account for duplicate records in its estimate of affected entities. Microsoft also said SOCRadar's decision to release a search tool to look through the files "is not in the best interest of ensuring customer privacy or security and potentially exposing them to unnecessary risk."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Microsoft Customer Data Exposed by Misconfigured Server

Research shows 1 in 7 employees involved in a cyberattack exhibits clinical trauma symptoms months after the incident.

The ransomware crisis hasn't just cost companies time and money, but also the mental health of their employees. New research shows that in the wake of a ransomware or other cyberattack, IT and security staff tasked with responding to a cyberattack can experience intense adverse psychological impacts for years afterward.

Research conducted by organizational psychologist Inge van der Beijl, director of behavior & resilience at Northwave, revealed that 1 out of every 7 employees experiences trauma symptoms months after a cyberattack, including trouble sleeping and back pain. Some 75% reported having "negative ruminative thoughts," and 1 in 5 impacted by a breach has considered a job change, according to the Northwave findings.

"Top management and HRM \[human resources management\] need to take measures against this, in fact right from the very beginning of the crisis," van der Beijl said in a statement. "They are the ones bearing responsibility for the well-being of their staff. The study reveals that effects can linger throughout the organization."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Emotional Toll From Cyberattacks Can Linger Among Staff for Years

Increasingly vendors are looking for ways to take security awareness beyond checkbox compliance courses to more context-dependent interactions — a "shift left" to the average worker.

Companies need to move beyond security awareness and training (SA&T) efforts to find ways to reinforce security concepts at the right times, security experts said this week.

While security awareness and training (SA&T) programs are an effective first step in raising cybersecurity awareness, the focus is too often on compliance and less on improving security — to the point that checking the required boxes is all that matters, says Russell Spitler, co-founder and CEO of cybersecurity startup Nudge Security. Security training classes are less than scintillating — employees generally dislike mandatory classes — and active phishing exercises often seem more like attempts at "gotcha," he says.

"These are approaches that set up an artificial antagonism between the organization and the employees," he says. "It is not intended to be that way, but when the people running the exercise say, 'Ah, ha! You fell for my trick!' ... It feels like such a nonproductive action."

In the midst of Cybersecurity Awareness Month, companies are increasingly realizing that they need more than SA&T and compliance to harden their workforces against the cybersecurity threats they are currently facing. The shift in perceptions follows the exodus of workers from their offices to work-from-home arrangements, in the process becoming the first line of defense against attackers.

**Improving Culture, Not Just Courses**

Organizations should focus on awareness, behavior, and culture — the ABCs of human risk reduction — not just courses and training, according to Forrester Research. A focus on quantifying human risks and determining those risks based on actual user behavior leads to better outcomes, the research firm stated in "The Forrester Wave: Security Awareness And Training Solutions, Q1 2022."

"With employees operating remotely or physically, security awareness is now borderless — so it’s paramount to instill a 'security everywhere' culture," Forrester's analysts wrote. "All of this is causing well-needed disruption in a long-stagnant market. Fortunately, many vendors have risen to the challenge, creating solutions that no longer function solely to train people for the sake of it."

Nudge Security, for example, is not primarily a security awareness training tool, but a method of gaining visibility into software-as-a-service usage and automating security for those services. The company grants businesses visibility into their employees' actions by scanning for emails that indicate when users have signed up for a service.

However, the service also automatically sends users reminders to reinforce good cybersecurity behavior by using context-specific interactions — or "nudges" — that iteratively improve the security know-how of the user.

"The point of those relatively simple interactions is that the opportunity for compliance is much higher when you are engaging those employees as part of your team and extending that trust," Spitler says. "We are not treating the employees as an extension of the computer. We are assuming that the employee is going to get their job done, and then we are presenting them with more context for the situation."

**'Micro-Training' to Change Behavior**

Nudge Security is not alone. In November 2021, the most established player in the security awareness and training (SA&T) sector, KnowBe4, acquired SecurityAdvisor, a provider of real-time behavior analysis and micro-learning. The company aims to combine the two approaches to create a "human detection and response" service that delivers training at the right moments, says Erich Kron, a security awareness advocate with KnowBe4.

"I see a future where, if an employee replies to a phishing email and includes PII \[personally identifiable information\] or other sensitive information, a favored tactic of bad actors, not only does the data loss prevention \[DLP\] control stop the information from leaving the organization, but it also triggers a short training session about protecting information and that type of scam," he says. "In those situations, the person is likely to be thankful that the technical control stopped something bad from happening but will also be motivated to learn how not to make the mistake again."

Another firm, CybSafe, has focused on changing behaviors as well, using data-based metrics and behavioral psychology to create a platform that measures specific actions and provide context-specific feedback.

"Awareness is good to have, sure, but it doesn't change behavior," the company stated in a blog post. "Yet, organizations keep assigning more traditional security awareness training to their people. Yes, we're puzzled too."

**Managing and Reducing Risk**

Companies involved with security awareness and training need to find better ways, not just to educate employees about cybersecurity, but measurable ways to reduce risk. Security groups should determine the best metrics to track human risk, and find improved ways to reduce that risk, Forrester Research stated in its report.

"Innovation is important to \[businesses\] because the way the industry has long addressed SA&T has yielded nothing but frustration for employees, eroding security's brand and goodwill," the analysts stated. "You need a different way to manage human risk, not better ways to train people."

Security Awareness Urged to Grow Beyond Compliance

FBI warns that cybercriminals are stealing personal information by posing as administrators of the Student Loan Debt Relief Plan.

Fraudsters are contacting people through email, text, phone, and online claiming to be administrators for the Federal Student Loan Forgiveness Program in an effort to steal personally identifiable information, the FBI warned this week.

In late August, the Biden Administration announced that the US Department of Education would cancel up to $20,000 in student loans per borrower.

The FBI says anyone contacted by someone purporting to be working for the federal student loan forgiveness program should not provide any sensitive personal data, particularly any payment information.

"Cybercriminals and fraudsters use their schemes to receive payment for services they will not provide or collect victim information they can then use to facilitate a variety of other crimes," the FBI announcement said. "Entrance into or assistance with any federal student aid program through the Department of Education or their trusted partners never requires payment."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Scammers Targeting Those Seeking Student Loan Forgiveness

Experts say CVE-2022-42899 is a serious vulnerability, but widespread exploitation is unlikely because of the specific conditions that need to exist for it to happen.

Researchers who have analyzed the recently disclosed vulnerability in Apache Commons Text — referred to by some as Text4Shell — described it this week as serious but unlikely to be as disruptive as last year's Log4j bug.

The flaw (CVE-2022-42889) is present in versions 1.5 through 1.9 of Apache Commons Text and gives attackers a way to run malicious code remotely on vulnerable systems. The Apache Software Foundation (ASF) disclosed the flaw last week in a brief advisory and recommended that organizations upgrade to Apache Commons Text 1.10.0, a version that the ASF released on Sept. 24 or more than two weeks before bug disclosure.

CVE-2022-42889 stems from insecure defaults when Apache Commons Text performs a function called variable interpolation, which involves the process of looking up and evaluating code strings that contain placeholders. According to the ASF, the set of Lookup instances in versions 1.5 through 1.9 of Apache Commons Text included interpolators that could trigger arbitrary code execution or contact with remote servers. Since the vulnerability was disclosed, several researchers have released proof-of-concept code showing how it can be exploited and scanners for finding potential targets to attack.

Shachar Menashe, senior director of security research at JFrog, says Apache Commons Text (ACT) is an extremely common Java library focused on algorithms that work on strings. "ACT provides an API to perform variable interpolation — or substitution — allowing properties to be dynamically evaluated and expanded," Menashe says. "Some functions of this library were found to lead to remote code execution if attacker-controlled data is passed to these functions."

There are three potential substitution sources that could have a security impact if an attacker has control of the string being interpolated: script, dns, and url, he explains. Attackers could use the script source to execute arbitrary JavaScript code; they could use the dns source to proxy dns requests, and the url source as a server-side request forgery vector, Menashe says.

However, "the vulnerability can only be exploited in cases where some Java code exists that uses \[Apache Commons Text\] and passes attacker-controlled data to specific functions," he says. "We believe exploitation won't be as widespread as Log4Shell since these functions seem to be less likely to receive external user input." 

An attacker would have to research the target Java application and find an input that is passed to the vulnerable functions, which the attacker can control, Menashe says. At the same time, it's unwise to rule out that possibility.

"It's still possible this will blow up if researchers start finding other popular third-party services that use this library and pass external input to these vulnerable functions by default," Menashe notes. "But as of now, no such third-party services have been found."

ASF describes the Commons Text library as providing additions to the standard Java Development Kit's (JDK) text handling. Sonatype's Maven Central Java repository lists 2,588 projects that currently use the library. Among them are Apache Hadoop Common, Apache Velocity, Spark Project Core, and Apache Commons Configuration,

**Widespread Exploitation Seems Unlikely**

Erick Galinkin, principal researcher at Rapid7, says the fact that CVE-2022-42889 is a library vulnerability makes it hard to say for certain what its impact will be. A lot depends on how the vulnerable object is used in a particular application. "Overall, our assessment is that the vulnerability is potentially serious," he says. "It is certainly important to patch affected applications as those patches become available, but not worth panicking over."

The severity is really a function of how the vulnerable object — the Commons Text StringSubstitutor interpolator — is used. "If there's an application out there that is using the interpolator on arbitrary untrusted input, a user of that application is going to have a bad time," he says. 

But based on initial research, the vulnerable object isn't very common, and it is implausible for an unprivileged attacker to actually gain control of the relevant strings. "That said, there may still be some application using this in a way that is risky, and in that case, the potential for code execution is very high," Galinkin said.

He adds that the ability for an attacker to discover vulnerable targets depends on how an organization might have implemented the vulnerable component. "Many of the proofs-of-concept for the vulnerability, including ours, just involve passing a crafted string to the interpolator — so in that sense, it is extremely easy to exploit," he says. In many other implementations an attacker would need to already have some level of access, making it difficult to exploit.

Menashe notes that JFrog has written an open source tool to detect Java binaries that are vulnerable to this issue. The tool can help organizations determine whether the version of commons-text is vulnerable.

He adds: "The tool also locates the calls to the vulnerable functions in compiled \[.jar files\] and reports the findings as class name and method names in which each vulnerable call appears."

Apache Commons Vulnerability: Patch but Don't Panic

We need more than the incomplete snapshot SBOMs provide to have real impact.

With Executive Order 14028, a large regulatory push toward mandating the production of a software bill of materials (SBOM) began. As this new buzzword spreads, you'd think it was a miracle cure for securing the software supply chain. Conceptually, it makes sense — knowing what is in a product is a reasonable expectation. However, it is important to understand what exactly an SBOM is and whether or not it can objectively be useful as a security tool.

**Understanding SBOMs**

SBOMs are meant to be something like a nutrition label on the back of a grocery store item listing all of the ingredients that went into making the product. While there currently is no official SBOM standard, a few guideline formats have emerged as top candidates. By far, the most popular is the Software Data Package Exchange (SPDX), sponsored by the Linux Foundation.

SPDX, as with most other formats, attempts to provide a common way to represent basic information about the ingredients that go into the production of software: names, versions, hashes, ecosystems, ancillary data like known flaws and license information, and relevant external assets. However, software is not as simple as a box of cereal, and there is no equivalent to the Food and Drug Administration enforcing compliance to any recommended guidelines.

**Everything Is Optional, Therefore Nothing Is Required**

One of the biggest and most obvious gaps in SPDX and other standards is that, like the open source ecosystem at large, it is a set of communities built on general guidelines, not verified standards. Open source communities are wide and sprawling, with contributors from across the globe. Often, package managers and hosting environments are designed by separate committees, each operating in isolation. While SBOM mandates represent an early attempt to unify these many silos of information, they suffer from some of the fundamental limitations of applying a standard retroactively.

First and foremost, the cracks begin to show when we consider what SPDX actually provides. As it turns out, nearly every field in the standard is optional. While this optionality of fields is clearly an artifact of how different the many software ecosystems the format attempts to cover really are, an SBOM loses its value as a real source of truth if there is no requirement for cryptographic hashes or other information that would allow us to positively associate the library with the information presented in the SBOM document.

**SBOMs Miss the Mark on Provenance**

In addition to being incomplete, many of the inputs cannot be properly represented in the current formats, especially from places like version control system repositories. While some emerging frameworks like SLSA attempt to apply notions of provenance, no format hits the mark. We must incorporate accurate provenance data into the SBOM format in order to ensure that we get a reasonable view of what is inside the software we are consuming. This should include the following, at minimum:

*   **Author identity information:** Both maintainers and contributors are a critical part of the software supply chain. They hold the proverbial keys to the kingdom, and choose how the software we consume downstream is released. Even if complete data cannot be captured, we can absolutely do better than what is provided today, which is nothing at all.
*   **Development tools:** This includes build tools, CI/CD infrastructure, and tools used during the development of upstream software. What good is securing your internal development infrastructure if a compromise in any library you use could still cause an internal compromise?
*   **Controls and protections:** If one of the goals is third-party risk management, we must ask: What does the security posture of the development team look like? Is branch protection being used? What sort of review processes are applied?
*   **Artifact attestation:** We absolutely must be able to tie an entry within an SBOM document back to an actual artifact. This should include both an actual build artifact, such as a compiled package, as well as continuously developed artifacts such as tagged branches in a version control system.

Realistically, we must build an understanding of each of these elements to comprehend what goes into the software we are utilizing before even considering how an SBOM may be operationalized.

**We Can't Rely On a Simple Snapshot in Time**

Finally, the biggest challenge with broad SBOM adoption is that the static format only provides the truth in that moment. In order to be meaningful, SBOMs must have the ability to be delivered and accessed continuously.

Consider, for instance, that you were to receive a vendor SBOM from your cloud storage provider. Not only would this SBOM be a document containing tens of thousands of individual pieces of software, but it would also contain many multiples of versions of those software packages. Now, consider that by the time you receive that information, it is likely already out of date. This is because large enterprises often ship hundreds or thousands of builds per day. By the time you have processed, consumed, and reasoned about an SBOM for any large vendor, the data is already stale.

Versions will have changed, new packages will have been added, and some packages may have been removed. Modern development best practices mean that builds and delivers are meant to be continuous, which leads to faster iteration and faster release cycles. It also means that the delivery of a single SBOM is all but meaningless. What this really implies is that there is a strong requirement for scalable automation around SBOMs in order for them to provide true value.

The intent behind SBOMs is to pave the way to improved visibility, both internally and externally. However, don't be fooled into thinking they will secure your software supply chain. We need more than an incomplete snapshot in time to have real impact.

Source

DARKReading