ReversingLabs Blog

4 ways hero culture is killing your security program's effectiveness

ericka@chickowski.com (Ericka Chickowski) — Wed, 21 Feb 2024 14:00:00 GMT

Who doesn't love a good hero? In the movies, when the hero swoops in and averts disaster, they receive copious accolades, everyone's satisfied, and the credits roll. In the sequels, new disaster scenarios that no one planned for unfold, but the hero is as fresh and ready as ever to repeat the cycle, singlehandedly taking on the challenge du jour.

In cybersecurity, however, the story is more nuanced — and less cheery. In the trenches of cybersecurity, the hero is often burned out after running around fixing other people's problems. And that leads to them making more mistakes than saves, because they've run out of superhero strength to do anything well anymore. Every time they do fix something, the accolades are few, but the demands increase — while the resources decrease.

Does this sound familiar — and maybe even strike a nerve? While security hero culture is born from good intentions, it is doing more harm than good to companies — and to the health and well-being of the security heroes themselves. Top experts believe that if organizations are going to improve their security posture, they must acknowledge the problems with hero culture and launch a multifaceted effort to overcome it.

Here's why cybersecurity hero culture is a problem — and four examples of how companies and the industry can avoid its negative effects and develop more resilient security operations.

[ Key takeaways: The State of Software Supply Chain Security 2024 | Get the full report | See the Webinar discussion ]

The toxic nature of cybersecurity hero culture

Ali Khan, field CISO at ReversingLabs, suggests a quick gut check: Ask, "Does my security organization put personalities over process?" If the answer is yes, that's a red flag that your organization could be in in the throes of hero culture.

"This happens when you rely more on a person than you do on a good, solid process, where you trust the process and everyone in the team to act according to it. Here's a very simple example: Each time a midsize organization has some kind of cyber-incident, are people in the business most likely to email a specific person about it, or do they email security@organization.com?"
—Ali Khan

Security leaders have been exploring the toxicity of cybersecurity hero culture for a while, spotlighting that it could be hurting organizations' cybersecurity outcomes. Some recent examples:

Meta's Ryan Nakamoto: "The Detriments of Hero Culture"
Google's Anton Chuvakin: "How to Banish Heroes from Your SOC"
Security veteran George Sandford: "Don't Get Tangled Up in Your Cape: Hero Culture As a Negative Force in Cyber"

One of the most comprehensive explorations on the topic to date was a recent in-depth examination of where security hero culture comes from, why it's hurting security professionals and security performance, and why management is disincentivized to stop it.

Application security (AppSec) veteran Kymberlee Price, founder and CEO of Zatik, who wrote the piece with Ross Haleliuk, head of product for LimaCharlie, said in an interview about the piece that the problem is clear: "It feels good to be a hero." However, hero culture leads to a counterproductive outcome.

"[If] you take it to the extreme, it can be incredibly detrimental for both the people and the companies. And that's the conversation we're trying to start, which is, How do we not only make sure that the security workers are healthy and sustainable, but in a way that's better for the companies?"
—Kymberlee Price

Haleliuk and Price's takedown of hero culture gauges the pain being felt in organization's today as cyberattacks ramp up generally — and as software supply chain security becomes front and center for organizations. Kelly Shortridge, a longtime product security advocate and senior principal engineer in the office of the CTO at Fastly, recently took on a related issue with software engineering, in a post titled "Cybersecurity Isn't Special." In it, she rails against "power-tripping" cybersecurity programs and professionals that treat security concerns as separate from the whole — to the detriment of the outcome.

"[Security] can’t pretend like security failure is so distinct in importance and impact that it requires completely separate workflows, stacks, reviews, tooling, design, and basically everything else. We should care about cybersecurity but we should not silo it or treat its concerns as separate because it actually worsens the outcomes we purportedly care about long-term."
—Kelly Shortridge

4 problems stemming from hero culture

When you boil down the issues that all these thought leaders bring up about cybersecurity hero culture, certain themes start to emerge across all those talking points. Foremost among them is that when cybersecurity hero mentality prevails, the following consequences ripple out from that culture:

1. The risk prioritization anti-pattern

One of the biggest dangers of cybersecurity hero culture is the underlying drumbeat of perfectionism that drives those in its thrall.

"We see this happen in a lot of places where it's like you feel like, as a security leader, you have to be perfect and you have to save every person from every crime. We simply can't do that."
—Kymberlee Price

Succumbing to the perfectionist mindset puts security teams into the anti-pattern of sound risk management. Whereas risk management is all about prioritizing risks because there's no such thing as a risk-free environment, hero culture tends to get caught up in the snipe hunt of risk elimination.

This is where the storyline links up with the security exceptionalism problem highlighted by Fastly's Shortridge in her recent post. Security practitioners become gatekeepers when they start to believe they can eliminate every threat. And that's exactly when they're most likely elevate cyber-risks above all the other risks the business must consider: business risks, speed to market risks, software resiliency risks, etc.

"Reliability failures are arguably both more frequent and more damaging when they occur; developer productivity failures can mean the difference between successful market differentiation and losing market share."
—Kelly Shortridge

2. Burnout begets burnout

Security burnout is one of the biggest mental health and productivity issues in the industry today — and the experts believe that hero culture is a huge contributor to the problem. The harder security heroes are worked, the less headspace they have to come up with creative ways to address root causes to problems and help the business build security by design.

"If you're grabbing all the dropping balls and throwing them back up in the air, then you don't have time to take a step back and think creatively about secure design, or 'How do we partner with the architects to develop this more securely?' because you're so busy trying to patch up the last thing that got shipped. If we continue this hero culture, the burnout cycle continues."
—Kymberlee Price

3. Cybersecurity's free-rider problem in reverse

The burnout cycle is also self-perpetuating because the business managing the heroes expects — implicitly and explicitly — that these passionate workers will always put in the extra hours to get things done. Which means they can get away with understaffing the security teams. It's like the free-rider problem in reverse. "I think being passionate about your profession is great. Trying to do your very best and having that drive to overdeliver. Having that drive to spend your free time to learn more about the things you're passionate about is great," said LimaCharlie's Haleliuk.

"The problem becomes when companies see it [but are] incentivized to exploit that passion, to double down on that passion, and to underinvest in their security operations because they know that there are people on their teams who have the desire to do the best they can, and they know that they'll step in and cover up for the gaps and goals the organization just lets persist by design."
—Ross Haleliuk

4. Lone rangers aren't team players

The most fundamental problem with hero culture is that it kills so many chances for effective teamwork. Heroes tend to work in isolation. Even when a security leader can put together a team of heroes, they're still working in isolation of the rest of the business, which means you lose the chance for cross-disciplinary excellence.

As long as companies continue to believe that they are making the best business decisions by doing what they're doing today, they won't change, ReversingLabs' Khan said.

"I've worked with a lot of people who are really good at what they do and are specialists, and so that provides a really good advantage, but it doesn't really help in a team culture environment because cybersecurity is a team sport and software development is very much a team sport. It's really hard for engineers, pen testers, security orchestrators, playbook builders, architects, and overall solution managers to work with a superhero. Someone with that mentality can put a damper on the team because their teammates sometimes step aside and take less responsibility."
—Ali Khan

Process over personalities

Hero culture is hurting both AppSec and SecOps in a lot of ways. So how does the industry fix this problem? Price and Haleliuk argue that many practitioners are addicted to the habit of heroic overwork — and the intermittent dopamine rewards they get when they do manage to save the day.

"The employees who say, 'I'm going to break out of the security hero model,' they have to detox just like somebody trying to give up a gambling addiction. That habit of constantly thinking about work takes time to break. And that won't break without cultural support at work, without a boss being like, 'Hey, why are you online on the weekends? I don't expect you to be online on the weekends. What'd you do this weekend that was fun?'"
—Kymberlee Price

When that kind of support is lacking, setting boundaries against managerial expectations of heroism can threaten your career track. Price points out that people who read her and Haleliuk's piece and decide to set boundaries at work and put in no more than 45 to 50 hours per week could end up losing their job if their employer isn't on board with that.

That is why Price thinks the industry needs to find ways to collect data and research that shows how burnout affects security outcomes and that measure what realistic work scoping looks like in a security operations center (SOC) and other parts of the security team.

Haleliuk noted that, to truly move business leaders, studies would have to demonstrate how poor outcomes detrimentally affect the bottom line, but he isn't optimistic that the industry will be able to find that.

"As long as companies continue to believe that they are making the best business decisions by doing what they're doing today, I don't anticipate they will be incentivized to change."
—Ross Haleliuk

Khan said individuals and security managers can make a dent at their own organizations if they start recognizing the power of processes over personalities. This goes for SOC incident response as much as for creating less-risky software development patterns.

"What we really need is good, solid processes and playbooks and crisis communication plans — and we've really got to follow those plans."
—Ali Khan

Attackers leverage PyPI to sideload malicious DLLs

Petar Kirhmajer — Tue, 20 Feb 2024 13:00:00 GMT

ReversingLabs researchers have observed a clear trend in which open-source platforms and code have become the stage for a growing and diverse range of malicious activity and campaigns. This trend includes hosting malicious command-and-control (C2) infrastructure, storing stolen data, and delivering second- and third- stage malware including downloaders and rootkit programs. The team's most recent discovery suggests that trend is continuing in 2024.

On January 10, ReversingLabs reverse engineer Karlo Zanki discovered two suspicious packages on the open-source package manager Python Package Index (PyPI). The packages, NP6HelperHttptest and NP6HelperHttper, were observed using DLL sideloading, a well-documented technique that malicious actors use to execute code without attracting the attention of security monitoring tools.

The latest discovery is an example of DLL sideloading executed by an open-source package that suggests the scope of software supply chain threats is expanding. Here is how the two packages were discovered — and key implications for both development teams and end-users.

Discussion

One of the biggest challenges to developers who rely on open source code (and that is pretty much every developer) is assessing the quality and reliability of what they find online. The open-source ecosystem is vast and diverse, with a constantly shifting landscape made up of new software modules and actively managed code, not to mention the long, long tail of loosely managed, inactive, or obsolete open source code. Complicating matters for developers, there is no common identity or reputation provider for open-source modules. That makes it easy for malicious actors, with minimum effort, to insert themselves and their wares into otherwise legitimate software supply chains.

As ReversingLabs has documented, typosquatting and repojacking attacks are two common methods of doing this, with malicious actors floating malicious look-alike packages for active or abandoned open-source modules in the hopes of fooling developers into incorporating them into their applications. But there are even more subtle ways to infiltrate legitimate applications, as ReversingLabs' latest discovery shows.

This discovery happened as a result of our standard monitoring of open-source repositories for packages with specific combinations of suspicious behaviors. In this case, our platform was looking for network communication features hidden in the setup.py file. That scan turned up the two malicious PyPI packages, NP6HelperHttptest and NP6HelperHttper. With further investigation, it became clear that the targets of those files were two existing, legitimate PyPI packages: NP6HelperHttp and NP6HelperConfig. These are helper tools originally published by a PyPI developer with the username NP6.

If that name sounds familiar, it is because NP6 is also a marketing-automation tool developed by the firm Chapvision. However, the NP6 PyPI account is not an official Chapvision account. Instead, it is a personal account linked to a Chapvision developer. It is unclear whether the company was aware of the existence of that account or the NP6HelperHttp and NP6HelperConfig tools. However, when informed about the existence of the packages, Chapvision confirmed to ReversingLabs that the helper tools were published by one of their employees. Around the same time, those packages were removed from PyPI.

The malicious packages uncovered, NP6HelperHttptest and NP6HelperHttper, employ typosquatting, using names that are nearly identical to one of the legitimate NP6 packages. The goal is to fool developers into downloading and opening the malicious wares, thereby facilitating further attacker access, as explained below. Zanki said the blurring of lines that separate official from unofficial or even malicious packages poses a major challenge to development organizations.

“Development organizations need to be aware of the threats related to supply chain security and open-source package repositories. They also need to be proactive about supply chain security. Even if they are not using open-source package repositories, that doesn't mean that threat actors won't abuse them to impersonate companies and their software products and tools."
—Karlo Zanki

Several open-source package repositories offer features to counter issues such as the one raised by the NP6 account. For example, both the npm and NuGet package managers allow publishers to register package or username prefixes (such as NP6) without the need to publish any content. That can prevent easy impersonation attacks that float malicious packages. “Think of it like registering a domain name, to prevent others from registering it before you," Zanki said.

Malicious script abusing DLL sideloading

Close examination of the malicious packages by ReversingLabs revealed that both contain a setup.py script, which extends setuptools commands with custom code designed to download two files:

ComServer.exe, a legitimate file from Beijing-based Kingsoft Corp., and properly signed with a valid certificate belonging to the same company.
dgdeskband64.dll, a malicious file that downloads and runs a stage-two payload.

Figure 1: setup.py - Downloading the files

Hiding malicious code in setup.py is a strategy that RL researchers have seen employed in previous attacks, including a December 2023 campaign. In that instance, custom setuptools commands were used to decode a Base64 encoded URL and fetch malicious, Base64-encoded Python commands that were then executed in a new process.

In this latest campaign, the setup.py Python script downloads the ComServer.exe and dgdeskband64.dll files, and then executes the signed file ComServer.exe in a new process.

ComServer.exe is a legitimate software application that is a part of the larger DriverGenius software package, a popular driver management tool. One of the purposes of ComServer.exe is to load a library, dgdeskband64.dll, and invoke its exported function Dllinstall, which is used to install a specified module inside the named software. The catch: The version of dgdeskband64.dll included in the malicious packages is not the legitimate version of the library that ComServer is expecting to find on the system where it is executed. Instead, the threat actor crafted their own version of dgdeskband64.dll to facilitate the attack, with the same Dllinstall export function as the legitimate Dgdeskband64.dll library.

As the graphic below shows, the malicious dgdeskband64.dll contains only one exported function, rather than five.

Figure 2: Different exports for the legit and malicious dll

DLL sideloading is a well-documented hacking technique used by both cybercriminal and nation-state actors to load malicious code while evading detection. In one prominent example, the North Korea-linked Lazarus Group used DLL sideloading to replace an internal IDA Pro library, win_fw.dll, with a malicious DLL to download and execute a payload.

DLL sideloading also isn’t novel in the context of open-source software attacks. In February 2023, for example, RL researcher Lucija Valentić wrote about her discovery of Aabquerys, a malicious npm package that employed typosquatting on a legitimate npm module to carry out DLL sideloading of malicious components.

In that campaign, malicious actors targeted a Windows PE (portable executable) file, wsc_proxy.exe, which is known to be vulnerable to the sideloading attacks. It has been involved in a number of malware campaigns. The malicious Aabquerys package, when executed, placed a dll file named wsc.dll with an exported function named run in the same folder as wsc_proxy.exe. When the legitimate wsc_proxy.exe executable is launched, it would invoke the run method from the sideloaded, malicious wsc.dll. That DLL then downloaded a third-stage malicious component, Demon.bin, from an external command and control site.

In the case of the new PyPI DLL examples, sideloading was used to avoid detection of the malicious code, as was the case with Aabquerys. Specifically, that was carried out by loading malicious code located in an unsigned (and therefore untrusted) DLL from the context of a signed PE executable. With this method the attackers lower the risk that their malicious code will be detected by security tools.

Figure 3: Malware infection stages

Dllinstall brings malicious functionality

Looking closer at the various elements of this attack, it's clear that execution of the malicious code is achieved by registering an exception handler inside the Dllinstall export function.

An exception handler is a common component of modern operating systems that manages exceptions encountered by running processes according to policies that are specific to the operating system in question. Actions could range from displaying an error message, to terminating the program generating the exception.

In the case of this malicious campaign, however, the exception handler is used to pass along malicious code. Specifically, after the exception handler is registered, the program enters a loop where it divides numbers until division by zero happens, causing an exception and inherently transferring the code flow to the malicious subroutine.

The subroutine then establishes a connection with an external server (hxxps://us.archive-ubuntu.top/components/an.gif?type=lastest) and downloads an.gif. That action would not appear suspicious. However, the downloaded file is not a GIF file at all, but a payload file, x86_64 shellcode. Once downloaded, the shellcode is streamed to memory and the execution is then redirected to it through a callback registered for the NotifyIpInterfaceChange function.

As with DLL sideloading, this method of abusing windows APIs to execute shellcode is not new. It has been observed and documented by researchers for close to 10 years.

Analyzing the shellcode

Taking a look at the shellcode in question: we can see that it is encrypted using a simple XOR encryption with a moving key (Figure 4).

Figure 4: Shellcode decryption routine

After decrypting it, RL discovered traces of a PE file (Figure 5). The string “MZARUH'' appears in a place where the PE magic string “MZ\x90\x00” normally appears. Just that string alone is a good indicator that this is a Cobalt Strike Beacon.

Cobalt Strike is a security tool designed for red teams to aid in their penetration testing tasks. However, as with any tool (especially the ones designed for red teams), threat actors can leverage it without investing too much effort into building similar tools themselves.

[ See Webinar: How Cobalt Strike is weaponized against organizations ]

The portable executable (PE) file that was decrypted was located just after the decryption routine, so it starts executing it right after it gets decrypted. The reason “MZARUH” is here instead of the normal PE magic string is that the CPU is trying to execute the bytes that make up that string. Coincidentally or intentionally, the string MZARUH and the data coming after it make up valid assembly instructions which can be executed normally.

Figure 5: Hex-view after decrypting and traces of a PE file

Evidence points to a wider campaign

Is this latest discovery a single instance or a part of a bigger campaign? The ReversingLabs Titanium Platform helps answer that question.

Using ReversingLabs’ YARA Retro Hunt, RL researchers looked back in time to find other packages that share characteristics with previously discovered malicious packages. Retro Hunt scans all samples uploaded to RL's Titanium Cloud over the last three months and allows organizations to match them against a specific YARA rule.

In this case, the RL research team wrote a YARA rule to look for either the malicious C2 domain (us.archive-ubuntu.top) or the headers and user-agent used to download the fake dgdeskband64.dll and used that to perform a retro hunt, which turned up another sample that appears to be part of this campaign.

Figure 6: A1000 retrohunt matches

This second sample that turned up in Retro Hunt is also a DLL, but it is not exploiting DriverGenius’ ComServer.exe to load a DLL. Instead, it uses a different pair, including an .exe and target DLL, windowsaccessbridge-64.dll. Still, the functionality is identical, and the same URL downloads the same payload as the other PyPI packages, suggesting that this sample is part of the same campaign.

The ReversingLabs Titanium Platform can also display the sources of analyzed samples, providing even more insight into the packages. Analyzing that data, it appears that the top level container for the second discovered sample is a zip archive that contains the .exe and target DLL, windowsaccessbridge-64.dll. Similarly, using the RL platform to check the sources for the top level container yielded a Titanium Cloud Service source match: the zip file was downloaded from the web location hxxps://cdn.0c.sk/1101012.zip.

That web location has been spotted in Titanium Cloud Services previously in connection with a malicious .NET sample. That .NET sample was observed downloading a ZIP file (hxxps://cdn.0c.sk/1101012.zip), which extracted an .exe file from the archive along with the malicious windowsaccessbridge-64.dll. It then launched the exe, which performs DLL sideloading in an identical fashion as the NP6HelperHttptest and NP6HelperHttper PyPI packages that initially caught the RL research team's attention. Furthermore, the .NET sample was self signed using a certificate issued to “Sex Shop SRL” (cert-serial:e3214c81339540a3804fca656f5aea7d). Data from the RL platform shows that this is not the first time this certificate was used to sign malware. In fact, ReversingLabs has samples signed with that same certificate that date as far back as June 2022.

Taken together, the data strongly supports the conclusion that the newly discovered PyPI packages are a part of the same campaign as the .NET sample, which implied that these packages are not a final act. Expect to see more malicious activity from this threat actor.

Conclusion

As this latest discovery shows, malicious actors at all levels of sophistication are increasingly turning to open source code and related infrastructure such as package managers to further their malicious campaigns. As they develop the tools and techniques threat actors deploy are becoming more diverse.

Bad actors that might have previously turned to well-tested techniques such as spearphishing to lure their targets into installing malware are adapting their methods. Planting malware in open-source package repositories and then waiting to see who downloads and uses the compromised code is proving to be a popular choice for malicious cyber-actors, who are increasingly using subtle means to insert their malicious wares into software supply chains.

The emergence of DLL sideloading attacks are one clear example of this emerging attack vector. These attacks have been used for years by threat actors to increase their leverage and control within compromised environments while escaping detection, but less often seen in attacks leveraging open-source packages. This report suggests that may be changing.

The discovery of these two malicious PyPI packages, as well as the subsequent discovery of a larger campaign and additional, malicious packages proves that threat actors are warming to the use of DLL sideloading to further software supply chain attacks — and inflict harm on both software producers and enterprises that rely on them. Over time, that is increasing pressure on both software producers and organizations to monitor the security and integrity of their software supply chain and the software packages that flow out of that supply chain.

Indicators of Compromise (IOCs)

Indicators of compromise (IoCs) are forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IoCs play a crucial role in cybersecurity investigations and cyber-incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of ReversingLabs' investigation of this software supply chain campaign.

PyPI packages:

package_name	version	SHA1
NP6HelperHttptest	0.1	1fc236e94b54d3ddc4b2afb8d44a19abd7cf0dd4
NP6HelperHttptest	0.2	dfc8afe5cb7377380908064551c9555719fd28e3
NP6HelperHttptest	0.3	73ece3d738777e791035e9c0c94bf4931baf3e3a
NP6HelperHttptest	0.4	e3a7098e3352fdbb5ff5991e9e10dcf3b43b1b86
NP6HelperHttptest	0.5	575bcc28998ad388c2ad2c2ebc74ba583f5c0065
NP6HelperHttptest	0.6	a1bb4531ce800515afa1357b633c73c27fa305cf
NP6HelperHttper	0.1	a65bce340366f724d444978dcdcd877fa2cacb1c

Additional Indicators:

description	URI
Domain that’s hosting the malicious dll	https://fus.rngupdatem.buzz
Domain that’s hosting the shellcode payload	Us.archive-ubuntu.top

name	type	SHA1
dgdeskband.dll	PE/dll	1f9fcf86a56394a7267d85ba76c1256d12e3e76b
windowsaccessbridge-64.dll	PE/dll	84c75536b279a85a5320f058514b884a016bc8c8
an.gif	shellcode	2dc80f45540d0a3ea33830848fcf529f98ea2f5e

Complexity and software supply chain security: 5 key survey takeaways

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 15 Feb 2024 17:25:11 GMT

Organizations are struggling with software supply chain security. That fact was further exposed this month with the Enterprise Strategy Group's new study, “The Growing Complexity of Securing the Software Supply Chain.”

The 28-page study, based on a survey of 368 IT, cybersecurity, and application development professionals at organizations in the United States and Canada, found that 91% of organizations have experienced a software supply chain incident in the last 12 months. The most common security incidents were zero-day exploits on vulnerabilities in third-party code (41%); misconfigured cloud service exploits (40%); open-source software and container image exploits (40%); secrets, passwords, and tokens stolen from source code repositories (37%); and API data breaches in third-party software and code (35%).

The complexity of creating software in the modern era makes it difficult to secure the software supply chain, Data Theorem COO Doug Dooley said in an interview.

"This is a pervasive and deep problem. No company is building 100% of their software by themselves anymore. There's a long tail of software suppliers in the ecosystem right now, from cloud service providers to open-source software developers to software vendors."
—Doug Dooley

The ESG study found that one of the most critical needs of organizations trying to secure their software supply chain is to have a handle on what's in their software and how it's working. "Because of the massive number of suppliers and partners, continuous discovery of components across the software supply chain is a major challenge," ESG Practice Director for Cybersecurity, Melinda Marks, said in a statement.

Marks said a majority of organizations (88%) in the survey stressed the importance of having an accurate inventory of third-party APIs and cloud services, making software bills of materials (SBOMs) key. However, she said the study found that creating and maintaining SBOMs was proving to be a challenge.

Here are five key takeaways from the new ESG software supply chain security study.

[ Get the report: The Buyer’s Guide to Software Supply Chain Security | Join the Webinar discussion: Why you need to upgrade your AppSec tools for the new era ]

1. Organizations say their supply chain security is 'robust,' but challenges persist

Despite nearly three-quarters (74%) of organizations saying they have “robust” software supply chain security capabilities, they report multiple challenges and concerns with using third-party software. Specifically, at least one-third of respondents identified being too dependent on open-source software (OSS), struggling to identify vulnerabilities in the OSS code, or being victims of hackers that target popular OSS code.

2. Optimizing the efficiency of security in development is paramount

Organizations need to look for ways to optimize efficiency as they incorporate security into their development processes to secure their software supply chain. Currently, organizations use tools both periodically by set time periods and upon code changes.

3. Few organizations are using tools to generate SBOMs

Regulations increasingly call for SBOMs to ensure software supply chain security. However, organizations are struggling to build accurate inventories of their software code composition. According to the study, only 22% of organizations are using an SBOM-generation tool. Of those, only 48% currently generate an SBOM as a part of the application development process for all applications, while 49% do so on a case-by-case basis.

4. SBOMs are vital but still too difficult to generate

Those organizations generating SBOMs find them useful for managing software supply chain risk. Unfortunately, more than three-quarters of the organizations using tools to generate SBOMs find the process challenging (36%) or very challenging (43%).

"While it's understood SBOMs are important to software supply chain security, most organizations are challenged with creating and maintaining current SBOMs. Organizations need continuous runtime scanning, discovery and inspection of open-source components, third-party libraries, and APIs in source code to best secure their applications."
—Melinda Marks

5. Security can be scaled by enabling developers

Security organizations realize the need to empower developers to efficiently fix code issues to mitigate application vulnerabilities. Most organizations are prioritizing this effort to “shift security left” to developers, with more than nine in 10 identifying it as a high (39%) or top (52%) priority. The good news is that a majority of developers are completely (40%) or mostly (24%) comfortable taking on security responsibilities, with only 11% not comfortable with the idea.

When failure is not an option

The emergence of cloud-native applications and a growing reliance on third-party APIs and cloud services have fundamentally altered the software supply chain security challenge, by introducing new attack surfaces that have "already been exploited and are poised to remain in the crosshairs of hackers and cybercriminal activity," Dooley said.

Invest in modern software supply chain security tools

Nearly half or survey respondents said the scanning of open-source code components and third-party libraries for vulnerabilities (44%) was their top priority for investments in software supply chain security over the next 12 to 18 months. "That's a basic first step," Dooley said. Other items on the priority list include inspecting APIs in source code (39%), creating an SBOM (38%), and scanning production environments for vulnerabilities (37%).

"Where it becomes more complicated is when you're using a third-party API service and you don't have the underlying code. You're using it like a black box."
—Doug Dooley

Failure to rise to the challenge of supply chain security problems puts sensitive data and applications at risk and erodes the trust and integrity enterprise customers have built their business on, Dooley said.

Matt Rose, field CISO at ReversingLabs, said SBOMs are a great first step in an organization's software supply chain security journey. But they need to go beyond the SBOM's creation to a comprehensive software supply chain security program.

SBOMs can help in a lot of ways because they give a list of all the ingredients in a software package. But they don't give you information on how these ingredients interact. It is not realistic to think that a third-party vendor will send source code for you to inspect for supply chain risks. That's because no vendor is ever going to say, "My software is riddled with holes."

"Software supply chain security mechanisms need to be implemented in a way that is not cumbersome, complex, or disruptive to existing CI/CD and release processes. NIST's Secure Software Development Framework is the best standard right now, but there are others as well."
—Matt Rose

Given the complexity and disparity of software supply chains, Rose wrote recently, the complexity of modern development calls for modern tools to manage risk across the software development lifecycle (SDLC).

"While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on application source code, packages, and an application at runtime, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks."
—Matt Rose

With complex binary analysis, organizations can evaluate all of the software they produce and consume, including third-party commercial software. The Enduring Security Framework, a public-private working group led by the National Security Agency (NSA) and CISA, recently stepped up its software supply chain security guidance with a call for complex binary analysis and reproducible builds, Rose noted.

Meet the New RL Partner Program

contact@reversinglabs.com (ReversingLabs) — Wed, 14 Feb 2024 17:38:00 GMT

It’s Valentine’s Day. What better way to celebrate togetherness than to make a big gesture of love with the announcement of the new RL Partner Program?

The threat landscape is growing, and the only way to stay in front of malicious actors is through collaboration with the best and brightest security experts – Captain Planet style. Businesses struggle to identify compliance issues, exposures, and threats like malware, tampering, vulnerabilities, mitigation guidance, exposed secrets, and license issues.

The RL Partner Program is a testament to an ecosystem approach that’s paramount in building comprehensive security resiliency, especially as cybersecurity leaders grapple with understaffing that impacts the capability to manage the most common threats (of which supply chain threats are in the top three concerns).

The new partner program expands the impact of ReversingLabs’ solutions by ensuring seamless integration into existing security stacks while tailoring category expertise to ensure our solutions perfectly align with an organization’s security objectives – no matter the organization’s security posture or maturity.

It takes a hands-on relationship

ReversingLabs COO Peter Doggart said these customer benefits are only possible through a genuine hands-on relationship that includes mutual intelligence-sharing and in-depth training on the threat landscape.

“We are championing our partners' growth strategies with offerings that address various use cases, from SBOM generation and SOC automation to threat hunting and analysis."
—Peter Doggart

Announced in 2023, RL’s relationship with DigiCert has opened new opportunities to strengthen trust throughout the software development pipeline.

“DigiCert helps organizations put digital trust to work, and our partnership with ReversingLabs unlocks real value. Together our technology integration and go-to-market strategy have helped define and enforce policies for tamper-proof software delivery, building trust with customers and within software supply chains," said Deepika Chauhan, Chief Product Officer at DigiCert.

Another highlight of the RL Partner Program is ReversingLabs’ collaboration with PwC UK, establishing the next generation of third-party risk management (TPRM) for their European customers "[Our alliance provides] clients with the visibility they need to understand and reduce third-party risks to their software supply chain," said Ian Trinder, Director of PwC UK.

Working with Synopsys, RL is expanding and optimizing malware analysis to jointly tackle complex supply chain threats.

Spread the love with a trusted partner

Companies, both large and small, rely on ReversingLabs’ constellation of consultants, security advisors, and value-added resellers. They are the trusted advisors to thousands of security teams worldwide.

The RL Partner Program is a new initiative that reflects a long-standing ReversingLabs value: collaboration. For the past 15 years, ReversingLabs has delivered critical threat intelligence to F500 companies and over 60 of the world’s most recognizable and impactful cybersecurity companies.

Introduced swiftly on the heels of the launch of Spectra Assure for software supply chain security, our new Partner Program provides resellers, distributors, consultants, MSSPs, and technology providers the sales and marketing tools to ensure that RL solutions can reach even more organizations around the world.

Spread the love and visit our partner page to learn more about the benefits of working with a ReversingLabs partner.

If your organization wants to cuddle up with ReversingLabs to tackle complex security threats jointly, contact our Partnership team at partners@reversinglabs.com, or apply for the RL Partner Program online.

5 software supply chain attacks you can learn from

jpmellojr@gmail.com (John P. Mello Jr.) — Wed, 14 Feb 2024 13:00:00 GMT

While the notable software supply chain incidents of 2023 did not reverberate like the watershed attack on SolarWinds in 2020, they had plenty to teach security teams across software development, application security (AppSec), and risk management.

Software supply chain threats have spiked dramatically over the past three years (up 1,300%), and attacks continued to rise in 2023. The analyst firm Gartner found that almost two-thirds (61%) of all U.S. businesses were directly impacted by software supply chain attacks between April 2022 and April 2023.

Here are lessons learned from key software supply chain attacks that took place in 2023. Put these lessons to work to get out in front of risk at your organization in 2024.

[ Get the report: The Buyer’s Guide to Software Supply Chain Security | Join the Webinar discussion: Why you need to upgrade your AppSec tools for the new era ]

1. CircleCI raises red flags for secrets

In January 2023, software development service CircleCI discovered that malware had been deployed on an engineer’s laptop and was used to open a single-sign-on (SSO) session backed by two-factor authentication, which allowed the attackers to access the company’s internal systems. After discovering the breach, CircleCI began rotating all GitHub OAuth tokens on behalf of its customers.

Guy Rosenthal, vice president for product at DoControl, said one of the biggest lessons learned from the CircleCI incident was that even properly implemented multifactor authentication (MFA) can be defeated if an endpoint such as a laptop isn't secure.

"The takeaway here is that it’s not enough just to do MFA or just to secure endpoints, but that it must be assumed that each of these items can be defeated. Therefore, multiple security points and constant monitoring are critical."
—Guy Rosenthal

James McQuiggan, a security awareness advocate with KnowBe4, said organizations should understand the weak points of MFA and the importance of implementing non-phishable MFA for sensitive or critical systems.

"MFA session keys can be circumvented and stolen by cybercriminals. Using hardware tokens can reduce the risk of an attack and support other cybersecurity monitoring systems."
—James McQuiggan

The CircleCi attack also exposed the risk the human element can bring to software supply chain security, said Lorri Janssen-Anessi, director for external cybersecurity assessments at BlueVoyant.

"Cybercriminals will always try to come up with plausible solutions to get you to click on a link or download an attachment. Ensuring education, training, and then implementing a security program that has mechanisms in place to defend against this type of compromise is critical."
—Lorri Janssen-Anessi

Matt Rose, field CISO for ReversingLabs, said that good digital hygiene is important but that the CircleCI incident illustrates more broadly that organizations have to not only be concerned about malware injection and secrets leaks generally, but also of the tooling used to build software packages.

When assessing supply chain risk, the focus is on the artifact as it moves through the process, but risks can be lurking in the tools that make up the process itself. If all the testing is done on the artifact — whether it's software composition analysis (SCA), static application security testing (SAST), penetration testing, or something else — something will be missed unless the core competencies, such as IDE and CI/CD, are examined, Rose said.

If an organization looks only at the artifact and not the structure that builds it, that organization potentially has a software supply chain risk.
—Matt Rose

2. 3CX: Don't be complacent about tampering

Another lesson came in March, when 3CX notified its customers that the desktop application they were using may have been compromised in a software supply chain attack that let intruders plant, in a software update, malware that steals information from the computers it infects. Damage was minimized by 3CX's security provider, Crowdstrike.

The 3CX case is good example of why organizations need to use multiple tools and adopt a defense-in-depth approach to security, DoControl's Rosenthal said.

"By watching what applications are doing on endpoints and on the network and knowing what 'normal' looks like, we can detect and alert on anomalous behaviors."
—Guy Rosenthal

A ReversingLabs analysis concluded that 3CX was actually the victim of a targeted supply chain attack, not an opportunistic attack that exploited a vulnerability in a shared software library. It found discrepancies in 3CX's versions of two standard libraries used with the Electron open-source framework on which the 3CXDesktopApp client is built: ffmpeg and d3dcompiler_47.

The message for software vendors here: Companies cannot be complacent. In this case there was ample evidence of tampering with the desktop client updates that 3CX sent out. Even in the absence of warnings by endpoint detection and response, that evidence should have been enough to put a pause on distributing the update, wrote Paul Roberts, cyber-content lead at ReversingLabs.

With sophisticated actors increasingly interested in abusing the hard-earned reputation of software teams to distribute malware, vendors need to be on guard for signs that malicious actors are at work within vendors' development and build processes, Roberts wrote. That awareness may not stop compromises, but it will make it less likely that a software vendor's customers end up suffering the consequences of the company's security failings.

Karlo Zanki, reverse engineer at ReversingLabs, wrote that one key lesson is the need for modernizing security tooling. One requirement for detecting supply chain compromises is the ability to track the evolution of software packages through differential analysis of their contents, he wrote. This includes the raw metadata properties of each software component in the release, as well as their respective behaviors.

"Odd or inexplicable changes between builds should be considered a cause to investigate a possible compromise. This becomes even more important when software packages include components that are pre-compiled at offsite locations and, therefore, not subject to review prior to deployment."
—Karlo Zanki

3. NuGet is a nugget of takeaways

Some valuable lessons were learned from another attack in March. This time adversaries used sophisticated typosquatting techniques to target .NET developers using the NuGet repository. The poisoned packages were downloaded 150,000 times before the malware could be removed from the repository. The packages contained a "download and execute" payload, so as soon as they were downloaded, they automatically downloaded a second, more virulent payload.

Sarah Jones, a cyberthreat intelligence research analyst with Critical Start, said the NuGet attack illustrates why we need enhanced code signing, regular vulnerability audits, and efficient incident response. "Collaboration within the .NET community played a crucial role, stressing the significance of collective action, vigilance in dependency management, and prioritizing packages with community support," she said.

DoControl's Rosenthal said trust was compromised. "In DevSecOps, the devil is in the details," he said.

"It’s easy for developers to glance at the names and other metadata of the packages to select the desired code libraries, but, as this attack showed, that information can be misleading and even intentionally falsified to create trust. In the end, developers need to be careful in curating what code they use, taking time to verify the details before downloading and using. It also reminds us that automatic execution is not a great idea."
—Guy Rosenthal

4. MOVEit: A wakeup call

More key lessons were learned in the MOVEit attack in May. The assault on the transfer and cloud applications of the offering by Progress Software leveraged two critical SQL injection vulnerabilities, CVE-2023-34362 and CVE-2023-35036, that allowed the attackers to gain unauthorized access to customers' systems and steal sensitive data, execute malicious code, and manipulate or delete critical information. The attack affected more than 963 organizations worldwide, including prominent companies such as Shell, British Airways, Deloitte, and the BBC, and even government agencies in the United States and the United Kingdom.

Critical Start's Jones said MOVEit illustrated the need for prioritizing regular software updates, transparent communication between vendor and user, and thorough mapping of the software supply chain.

"The MOVEit attack served as a wakeup call for organizations relying on legacy software. The incident highlighted the interconnected nature of the supply chain and the importance of identifying vulnerabilities in all components."
—Sarah Jones

BlueVoyant's Janssen-Anessi said security teams aren't alone in learning from these kinds of attacks.

"In our annual supply chain survey of C-level executives, we found breaches like MOVEit led to 60% of respondents saying their budget would increase to protect against these type of breaches."
—Lorri Janssen-Anessi

More than anything else, the MOVEit attack shows that the full impact of this kind of breach will not be known for months or even years after it initially comes to light, said DoControl's Rosenthal.

5. HuggingFace: AI dataset poisoning gets smart

While many organizations grappled with artificial intelligence (AI) and its large language models (LLM) during the year, those technologies presented adversaries with more supply chains to attack, as the HuggingFace API compromise illustrates. HuggingFace is a popular resource for developers of LLM projects. It contains hundreds of thousands of AI models and datasets in its repository. At the end of 2023, cybersecurity researchers at Lasso discovered more than 1,600 leaked tokens that opened up access to the accounts of 723 organizations, including Google, Meta, Microsoft, and VMware.

Steve Wilson, chief product officer at Exabeam and project manager for the OWASP Top 10 for LLM, said poisoned ML models exposed a bigger software supply chain security concern.

"Hugging Face highlights the risks of tainted ML models as a supply chain vulnerability. This was a wakeup call regarding the potential for malicious actors to manipulate machine-learning models, turning them into vehicles for cyberattacks."
—Steve Wilson

Wilson said the detection of zero-day vulnerabilities in essential MLOps tools such as PyTorch "underscored the fragility of the AI supply chain."

"Such vulnerabilities in widely used tools can have far-reaching impacts, affecting numerous applications and systems built on these platforms."
—Steve Wilson

Put these lessons to work in 2024

Wilson called the AI supply chain "a war zone," where threats are constantly evolving, because traditional AppSec testing tools such as SCA and the focus on vulnerabilities using the CVE database, while valuable, "are still adapting to the unique challenges posed by AI supply chain security."

"The taxonomy around AI vulnerabilities is still developing, indicating that we are in the early stages of effectively understanding and combating these threats."
—Steve Wilson

Jeff Williams, CTO and co-founder at Contrast Security, said there were general lessons security teams can learn from 2023's class of software supply chain attacks.

"Hopefully, we learned that software supply chains are complex — an entire ecosystem of tools and technologies that have traditionally been ignored by both security and hackers. But that has all changed as hackers have realized the power of attacking supply chains."
—Jeff Williams

Williams noted that there are four major categories of supply chain targets: software you write, software you import, software you buy, and software you use to build software.

"Organizations should start with the basics. Think through the threat model, limit the breadth of the ecosystem, establish controls to minimize vulnerability, and establish infrastructure for fast detection and response."
—Jeff Williams

With software supply chain risk front and center for CISOs, the lessons learned from 2023's crop of software supply chain attacks need to be learned fast, as even more adversary activity is expected in 2024.

Software supply chain security: Upgrade your AppSec for a new era

matthew.rose@reversinglabs.com (Matt Rose) — Tue, 13 Feb 2024 14:00:00 GMT

The software supply chain security landscape has shifted considerably over the last year. Two of the most significant changes have been the move to a more formalized definition of the term "software supply chain security” and the development of a better understanding of what is needed to secure the software development lifecycle (SDLC).

A year ago, securing the software supply chain was all about open-source packages, software bills of materials (SBOMs)and using software composition analysis (SCA). Now, there is a realization that the risk from the increasingly complex software supply chain is multifaceted.

Software producers and enterprise consumers have come to recognize that, while securing source code and open-source packages is important, it alone is not enough to control risk from software supply chain attacks. Teams also need to have mechanisms to detect potential compromises of the development tool chain, from the continuous integration/continuous deployment (CI/CD) orchestration platform to the build environment to code repositories and binary repositories.

In addition to updated guidance from federal agencies and the White House, analyst firm Gartner has produced guidance on managing software supply chain risk that marks a shift in thinking. It goes into detail about software supply chain security best practices. (Hint: There's more to it than just saying, "You need an SBOM.") Then there's ReversingLabs' new research-based report, the State of Software Supply Chain Security 2024, which highlights the need for a new approach.

An evolution of application security (AppSec) is under way, and a key to it is complex binary analysis, which is like a final exam for your software package before release. Complex binary analysis allows your team to review the software in final form so that you can trust all of the software your organization produces and consumes.

Here's why you need to consider complex binary analysis a requirement in the new era of software supply chain security.

[ Get the report: The Buyer’s Guide to Software Supply Chain Security | Join the Webinar discussion: Why you need to upgrade your AppSec tools for the new era ]

Software complexity: Different lenses of attack

A couple of factors are driving this change. The first is the new and still largely unknown nature of the threats to software supply chains. To keep up with the demand for faster releases, organizations have moved from very staid and plodding development processes, where everybody knew what was happening, to fast development using shared code resources from platforms such as GitHub — which now is increasingly under attack. One result is that security teams are now siloed into specific responsibility areas.

Given the complexity and disparity of software supply chains, it is no longer possible to get a full picture of software risk until everything is brought together in the final package. And many software supply chain attacks are novel. Future attacks may match the severity of SolarWinds Sunburst, but they will almost certainly differ in their methodology.

In fact, several major supply chain breaches that have occurred since the attack on SolarWinds have used different execution. The breach at 3CX, for instance, resulted from a legitimately signed third-party software component. The CircleCI breach stemmed from a compromise of its CI/CD orchestration platform itself, and the breach at Codecov resulted from credentials theft and misuse.

All of these were serious software supply chain attacks, and they all took different paths. It's clear that attackers are testing the waters. They are trying to get out of the fenced yard by pushing on the fence panels to see which one will give. What these attackers are doing is looking at all aspects of the SDLC for potential weaknesses, which they can then attack.

Increasingly, teams responsible for managing risk are realizing that they need to stop thinking of SunBurst as a unique category of supply chain attack and focus instead on the bigger picture.

Technologies for identifying threats to the supply chain are vital at every step of the development process because you don't know whether a threat actor is going to try to attack the build system or code repositories or seek some other way to slip malware into the software pipeline. Increasingly, teams responsible for managing risk are realizing that they need to stop thinking of SunBurst as a unique category of supply chain attack and focus instead on the bigger picture.

The mandate for modernizing AppSec gets real

Another driver for change is that software supply chain attacks have garnered much attention as a primary risk category, and organizations are starting to freak out a little bit. Security teams are buckling down, trying to find a process for securing the SDLC. A lot of the initial momentum came from the federal government, starting with the May 2021 executive order from the White House, which called for increasing the United States' cybersecurity resiliency. That was followed by a memo calling for self-attestation by software producers and the creation of SBOMs. Gartner also joined the call for SBOMs in 2022.

One initiative that received a lot of attention in 2023 was Secure by Design, championed by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), because a key aim of the initiative is to shift liability from software consumers to the producers of the software.

More recently, the Enduring Security Framework, a public-private working group led by the National Security Agency (NSA) and CISA, stepped up its software supply chain security guidance with a call for complex binary analysis and reproducible builds.

[ Definitive timeline: Federal guidance on software supply chain security ]

In the next 12 to 18 months, it is reasonable to expect that higher standards for software supply chain security are going to apply to a wider swath of organizations and not just those doing business with the federal government. Ahead of that, organizations need a way to anticipate and answer questions about the security of their software supply chain. Those that can get out in front of that risk will have a competitive advantage — and stay out of the headlines.

Modern development requires modern tools

Software supply chain security mechanisms need to be implemented in a way that is not cumbersome, complex, or disruptive to existing CI/CD and release processes. NIST's Secure Software Development Framework is the best standard right now, but there are others as well. Organizations have to identify which standard works best for the way they develop or consume software because people code in different ways and with different kinds of technology stacks.

Organizations need to identify the standard that best works for them as they try to manage software supply chain risk, and they need to stick with it. With complex binary analysis, organizations can evaluate all of the software they produce and consume, including third-party commercial software.

While legacy AppSec testing focuses on source code, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.

While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on application source code, packages, and an application at runtime, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.

The evolution of AppSec must continue

Everybody is familiar with legacy AppSec testing — and it's not going away. But this new era is calling for your organization to get comfortable with an additional security technology that provides a completely different, but very important, lens of risk. If you are not doing real software supply chain security as part of your validation processes — that is, doing a final exam with complex binary analysis — then your software and your organization are not secure.

OWASP Top 10 for LLM 2.0: 3 key AppSec focus areas emerge

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 08 Feb 2024 17:04:22 GMT

The project team for the OWASP Top 10 list of vulnerabilities for large language models (LLMs) has kicked off preparations for releasing version 2.0 of the list. In a newsletter published on LinkedIn, project lead Steve Wilson called version 1.1 a considerable effort with a substantial impact, adding that version 2.0 will represent the first major revision.

Wilson said that a key driver of the next version of the Top 10 for LLMs was a survey that the OWASP project team recently completed. He said in an interview that the team was gathering expert opinion from the front lines of application security (AppSec) about "emerging risks that they're seeing that may not be showing up in our data."

"Since we released versions 1.0 and 1.1, we've been working in the background to do some data gathering about the threat landscape," Wilson said. "Now we've put out a survey asking people for their opinions on the current list and to rank possible areas to explore for the 2.0 list."

For the OWASP Top 10 for LLMs 2.0, Wilson said, "everything is on the table."

"We’ll reevaluate the top vulnerabilities, how we classify them, and decide on relative rankings. Version 2.0 will have a significant new focus on data gathering and using that data to improve our recommendations."
—Steve Wilson

Here are three key focal points for the next version of the OWASP Top 10 for LLMs.

1. Data privacy

Wilson noted that the team received more than 100 responses to its survey, with about 75% of them from new participants or followers (40%) who were becoming active participants (35%).

"The 1.0 project was very grass-roots. What's interesting with 2.0 is that six or seven months later a lot of people submitted comments saying their companies were interested in the project. A lot of them are new-generation startups around AI security."
—Steve Wilson

Wilson said that some of the themes from the survey will help drive some of the thinking of what to do on the list and provide grist for future projects.

One standout concern for survey respondent was data privacy. "Privacy has always been adjacent to security, but from the folks we interviewed and who responded to the survey, data privacy is at the top of line for AI applications," Wilson said.

2. Safety and bias in LLM systems

Another concern gleaned from the survey is safety and bias in LLM systems. "I was surprised that security people wanted more advice about things like safety and bias," Wilson said.

"They're not things that have fallen into an application security team's purview before, but they're getting asked to help with them. I think we'll be looking to offer some more guidance around those."
—Steve Wilson

3. Mapping out vulnerabilities

Wilson said the project team is dedicated to making the LLM list comparable to other OWASP lists, which are very data-driven and "based on CVEs and sources like that."

"What we've been working on is figuring out: How do we map some of these AI- and LLM-specific risks to some of the data sources out there. It turns out that some of the CVE descriptions and that kind of data are not conducive to recording the risks that we're seeing with large language models."
—Steve Wilson

Wilson said the project team needed to do some bridging of the processes. "We're working with teams at MITRE and other organizations to standardize some of this so we can get a grip on what's going on in the real world," he said.

A SQL injection, for example, is not the same in AI as it is with traditional AppSec risk.

"The security risks with LLM are much harder to pin down and put into the boxes that are in the same shape as some of the more traditional security risks. There's a binary answer to SQL injection: 'Am I vulnerable to a SQL injection attack if I allow untrusted strings into my database?'"
—Steve Wilson

With LLMs, each model is taking in prompts as untrusted data, he said. "Then the questions become: To what degree am I vulnerable, and what kinds of vulnerabilities are there?"

OWASP Top 10 for LLM 2.0: Coming later this year

The project team released a light update in August of its original document. Version 1.1, included a visual illustration of the data flow in a typical LLM application and the potential areas of risk from the vulnerabilities in the Top 10. For example, the data flow between an API and an LLM's production services could be vulnerable to a prompt injection or denial-of-service attack, or an application's plugins might contain insecure design excessive agency vulnerabilities.

Otherwise, the top vulnerabilities list remained the same:

LLM01: Prompt Injection, which is used to manipulate an LLM through crafty inputs, causing unintended actions
LLM02: Insecure Output Handling, which occurs when an LLM output is accepted without scrutiny, exposing backend systems
LLM03: Training Data Poisoning, which occurs when LLM training data is tampered with, introducing vulnerabilities or biases that compromise security, effectiveness, or ethical behavior
LLM04: Model Denial of Service, which happens when attackers cause resource-heavy operations on LLMs, leading to service degradation or high costs
LLM05: Supply Chain Vulnerabilities, which take place when an application’s lifecycle is compromised by vulnerable components or services
LLM06: Sensitive Information Disclosure, which can arise when an LLM inadvertently reveals confidential data in its responses
LLM07: Insecure Plugin Design, which results in plugins with insecure inputs and insufficient access control, leading to consequences like remote code execution
LLM08: Excessive Agency, which surfaces when excessive functionality, permissions, or autonomy is granted to the LLM-based systems
LLM09: Overreliance, which crops up when systems or people become overly dependent on LLMs without oversight
LLM10: Model Theft, which involves unauthorized access, copying, or exfiltration of proprietary LLM models

The project team is aiming to release the OWASP Top 10 for LLM 2.0 later this year.

"We want to get something out in the next six months. We expect to see drafts in the spring and maybe a new version of the list in the summer."
—Steve Wilson

Definitive timeline: Federal guidance on software supply chain security

carolynn.vanarsdale@reversinglabs.com (Carolynn van Arsdale) — Wed, 07 Feb 2024 13:00:00 GMT

With major software supply chain attacks including the SunBurst attack on SolarWinds in 2020 and the critical vulnerability Log4j, software security moved front and center for risk managers and software teams alike. These incidents, along with a string of other attacks that span the past few decades, show the problem is only getting worse as bad actors target an increasingly complex process for building software — and the software development toolchain itself.

The problem has accelerated dramatically in the past three years, with software supply chain threats via open-source repositories skyrocketing by 1300% between 2020 and 2023, catching security teams off guard. Also: Nearly nine out of 10 security and IT professionals surveyed in a 2023 study said that their companies detected security issues in their software supply chains in the last 12 months.

The problem of software supply chain security has also caught the attention of the U.S. federal government, which has been very active over the past few years in seeking to tackle the problem head on. Those efforts include the White House's Executive Order on Improving the Nation’s Cybersecurity, released in May 2021, and a flurry of other critical initiatives and guidance that have followed, including the Secure by Design initiative in 2023.

Here is a definitive timeline of the U.S.'s major software supply chain policy initiatives and mandates:

[ Key takeaways: State of Software Supply Chain Security 2024 | Get the full report ]

The Cloudflare source code breach: Lessons learned

paul.roberts@reversinglabs.com (Paul Roberts) — Tue, 06 Feb 2024 13:00:00 GMT

High-profile web hosting company Cloudflare said last week that a sophisticated attacker gained access to code repositories used by the company and made off with sensitive internal code. This was just the latest such attack targeting the firm.

In a post on February 1 co-written by Cloudflare CEO Matthew Prince, CTO John Graham-Cumming, and CISO Grant Bourzikas, the company revealed the details of a November 2023 malicious campaign that lasted roughly 10 days and saw malicious actors make off with 76 different source-code repositories from Cloudflare’s Atlassian Bitbucket source-code repository.

Cloudflare tied the incident to a breach at online identity provider Okta, which happened in October 2023. In that incident, malicious actors compromised the company’s internal network and downloaded a report that included names and email addresses of all clients that use its customer support system. The company said the malicious actors behind the campaign also accessed “additional reports and support cases” that contained contact information for Okta-certified users, some Okta employee information, and Okta Customer Identity Cloud (CIC) customer contacts.

The Okta breach led to an earlier attack on Cloudflare, disclosed in October, in which attackers used an authentication token retrieved from Okta to “pivot into” Cloudflare’s Okta instance. The company said it detected and blocked that attack at the time with no discernible impact on its security posture.

Here's what we know about the latest Cloadflare breach – and lessons your team can learn from the incident.

[ Key takeaways: State of Software Supply Chain Security 2024 | Get the full report ]

Okta: The breach that keeps on giving

In the latest attack, the threat actors leveraged a set of Cloudflare credentials exposed in the Okta breach that were meant to be rotated but that the company overlooked. Those included a Moveworks service token that gave the attackers access to Cloudflare’s Atlassian system and credentials for three service accounts leaked in the Okta compromise: one used by the SaaS-based Smartsheet application with administrative access to our Atlassian Jira instance; another for a Bitbucket service account used to access Cloudflare’s source-code management system; and a final set of credentials for an AWS environment with no global access —and no customer data or other sensitive data, Cloudflare said.

With those credentials in hand, the threat actors had what they needed to establish a beachhead within Cloudflare’s environment with administrative access to Atlassian Jira. That allowed the threat actors to leverage the Atlassian Bitbucket Git archive feature to download the 76 repositories to the Atlassian server, from which they could be exfiltrated to an external source. While Cloudflare said it does not have proof that the repositories were exfiltrated, it assumes they were.

According to the post, the repositories that were downloaded contained source code related to key Cloudflare functions, including how backups work, how the company’s global network is configured and managed, and how Cloudflare manages identity and remote access. There was also code related to Cloudflare’s use of Terraform and Kubernetes. (Terraform is an infrastructure-as-code application made by HashiCorp.)

Cloudflare was quick to point out that customer data was not compromised in the attack, noting the following in its post about the incident:

“We saw no evidence whatsoever that the threat actor got access to our global network, data centers, SSL keys, customer databases or configuration information. …Their access was limited to the Atlassian suite and the server on which our Atlassian runs.

It's no secret that stolen code can be a problem

If Cloudflare’s actual operating environment and customer data weren’t compromised, is the theft of raw source code a concern? The answer, say security experts, is "yes."

Ashlee Benge, Director of Threat Intelligence at ReversingLabs, said leaked source-code could include exploitable software vulnerabilities, plaintext passwords, certificates used for authentication, and more.

"There is a lot of stuff hidden in source code."
—Ashlee Benge

Eric Milam, senior cyber security executive at ReversingLabs, said that with access to the raw source code, attackers can also gain an intimate knowledge of how a company’s systems fit together.

“Removing the black box is another big advantage that may show its weakness over time."
—Eric Milam

Even as Cloudflare cast doubt on the raw value of the code itself in its post, the company acknowledged the risks of exposed secrets and code flaws.

“Our focus was not on someone having access to the source code, but whether that source code contained embedded secrets (such as a key or token) and vulnerabilities. [However], a small number of the repositories contained encrypted secrets, which were rotated immediately even though they were strongly encrypted themselves.”

In the wake of the attack, in an internal all-hands-on-deck effort dubbed Code Red (no, not that Code Red), Cloudflare directed its engineering teams to scour the stolen source-code repositories for code vulnerabilities and other avenues for a malicious actor to “mount a subsequent attack.”

That robust effort to remediate the attack may prove sufficient to ward off follow-on attacks leveraging secrets or intelligence gained from the source code. However, Cloudflare should be on guard for the myriad ways that exposed code might undermine its security. Those range from references to particular staff or developers that might lurk in source code comments, or metadata and that could provide valuable intelligence for future attacks.

“I would be preparing to spearfish them after the buzz had died down about this compromise."
—Ashlee Benge

Third-party risk and the scourge of leaked secrets

This latest Cloudflare incident underscores the continuing risks to organizations posed by both third-party software and leaks of development secrets alike.

Cloudflare’s zero-trust security model appears to have greatly limited the scope of the breach (at least by the company’s account). However, attackers' ability to leverage credentials stolen from a third-party identity provider (Okta) and gain persistent access to Cloudflare’s development environment underscores the acute exposure that even sophisticated firms have by way of third-party providers. A similar lesson lurked in the January 2023 disclosure by the firm CircleCI that it had been compromised .

Being prepared means being aware of what secrets and risks lurk in your code. ReversingLabs' State of Software Supply Chain Security 2024 reported the discovery of 40,000 secrets leaked in 2023 alone from four major open-source platforms: npm, PyPI, RubyGems, and NuGet. Those included embedded and encrypted private keys, web service API keys and access credentials, and plaintext credentials buried in network protocol strings.

While not all such credentials pose a security risk (placeholder and expired credentials may not pose any risk), organizations need to be aware of the security exposure that source code poses and the varieties of sensitive information that may lurk in both open-source and proprietary code repositories.

CISO accountability in the era of software supply chain security

sasa.zdjelar@reversinglabs.com (Saša Zdjelar) — Mon, 05 Feb 2024 19:45:00 GMT

Cybersecurity leaders are well aware that the industry is constantly evolving. Whether dealing with the kinds of threats organizations face or the security tools best fit to mitigate them, today’s leaders understand that they have to stay on their toes. But in just the past few years, there has been considerable change in one role specifically: the chief information security officer (CISO).

The way in which a typical CISO functions today is quite different from how a CISO would have conducted business in 2020. This is because the cybersecurity industry was forever changed by SunBurst, the software supply chain attack on SolarWinds’ Orion software in late 2020. That incident not only put software supply chain security and third-party risk management (TPRM) on the map, but also served as a paradigm shift for CISOs.

As those of us who have served as CISOs know, there is a constant tension between security, controls, and the business’s objectives; CISOs are expected to not head an “organization of no.” Prior to SunBurst, it was considered common practice for CISOs to have their security reports “prettied up” by marketing and PR teams for public presentation. More often than not, that resulted in their statements to be watered-down or lose their meaning. Even worse: Cleaned-up language might fail to capture the true state of security at their organizations. Doing this kind of whitewashing only a few years ago was the norm for publicly traded firms, which faced few if any consequences — legal or otherwise — for such activity.

These expectations for the CISO took a dramatic turn in October 2023, when the U.S. Securities and Exchange Commission (SEC) charged SolarWinds and its CISO, Timothy G. Brown, with fraud and internal control failures, alleging that the company “misled investors about its cybersecurity practices and known risks” in relation to the 2020 SunBurst incident. From the outside looking in, it seems as though Brown is being held personally liable for what had been considered common practice by many CISOs and their organizations.

Historically, the controls available to CISOs to ensure that commercial off-the-shelf (COTS) and other third-party components didn’t bring unacceptable risks into their corporate environments were generally limited to questionnaire-based surveys, rudimentary contract language, and technical security reviews (e.g., manual penetration tests). But today, these controls are seen as highly ineffective and unscalable in finding the types of risks we’ve seen in significant breaches in addition to SunBurst, such as 3CX, Kaseya, CircleCI, MOVEit, etc.

This new precedent brought forth by the SEC is now the defining event between two time periods. In this new era, which consists of concern for software supply chain security and newfound accountability, CISOs are now personally and financially responsible for the security outcomes of their enterprises’ security programs. Therefore, misrepresentation about the state of security at an organization is no longer acceptable.

Here's what CISOs need to know in this new era — and how they can leverage their new responsibility to prioritize security within their organization.

[ Webinar: Saša Zdjelar and Daniel Miessler discuss CISO accountability in the new era | See related: HPE, Microsoft breach disclosures mark new era for CISOs ]

The new CISO: A cyber-CFO?

To better understand this new level of scrutiny in the cybersecurity industry, it’s best to compare the newfound personal liability of a CISO to what is expected of a modern-day chief financial officer (CFO). Back in the early 2000s, the finance industry had its own paradigm shift, when the now-defunct energy company Enron collapsed, revealing a wide range of financial improprieties. Eventually, the company’s former CFO, Andy Fastow, was convicted by the SEC, in October 2002, on several serious charges, including “inflating the value of Enron’s investments.”

The SEC’s case against Brown and SolarWinds will “be like our (cybersecurity’s) Enron moment,” my friend Daniel Miessler shared in his writing about the SEC’s case against Tim Brown. That’s not in the sense of the alleged offense committed, but the reaction it spawns in regulators, he wrote.

Miessler and I agree that in this new era of scrutiny, CISOs will have to carry themselves in a similar manner to a CFO in the post-Enron world, making the modern cybersecurity leader more akin to a “cyber-CFO.” Rather than just being concerned about the enterprise’s security, cyber-leaders will likely be held personally liable for security assertions and external reporting and will be subject to regulatory standards, etc. – just as a CFO is today as a result of Enron and the subsequent Sarbanes-Oxley Act of 2002.

This is why I believe the following four changes will come (or have already come) for today’s CISOs:

1. Careful drafting training for all execs

There will be careful drafting training for senior executives, inclusive of CISOs and possibly the whole company. There will be a newfound priority within the C-suite to be extra careful regarding what is said and how it is said, both verbally and in writing, internally and externally.

2. Well-rounded CISO candidates will rise up

CISO candidates with multidisciplinary and well-rounded backgrounds are more likely to be considered for these positions. Enterprises want CISO roles filled by seasoned security leaders who are also business-savvy. This is because security leaders with this kind of diverse background will have a better understanding of personal liability in the areas of financial and fiduciary responsibility.

3. Seniority will come with the new responsibility

The CISO will be a more senior executive than previously thought and will be expected to have a broad consideration for risk. The work and responsibilities of a CISO will be taken just as seriously as those of the CFO, and CISOs may even become a Section 16 officer of the company. Any CISO who isn’t willing to do will find that others will gladly take their place.

4. CISOs will have the final word

CISOs will have the final word for their internal and external communications regarding the company’s security practices. Enterprises do not want to be held legally accountable for watering down the CISO’s factual messages about the company’s state of security.

CISOs can use this new responsibility to prioritize security

All of the above changes are why a CISO now needs to start acting like a CFO on their very first day in the role. CISOs no longer have the freedom to prioritize business interests and subordinate cybersecurity, because they will be found liable for misrepresenting security practices in the event of a cyber-incident. CFOs can’t let some fraud, financial crime, absence of key stated controls, or insider dealing go while they ease into the role, and CISOs will need to start acting the same way regarding their company’s security program.

While some may find this new era of CISO accountability a threat, they need to look at the massive opportunity as well — and the opportunity is quite big! Yes, CISOs will have more work to do with this new level of scrutiny and accountability. However, this new era will allow them to take a more senior and influential role in the organization, receive greater allocations of resources to maintain an appropriate level of perceived risk, prioritize critical enterprise security needs, and be fully transparent on what security issues their company is dealing with.

And because CISOs and their respective companies will be more transparent and accountable, this should lead to greater trust in them from customers, board members, investors, employees, regulators, and the communities in which they operate.

To all of the CISOs out there, this is your moment to seize the day!

[ Join the discussion on February 6 @ 11am EST with Saša Zdjelar and Daniel Miessler about CISO accountability in the era of software supply chain security ]

Lessons from the Mercedes-Benz GitHub source code leak

paul.roberts@reversinglabs.com (Paul Roberts) — Thu, 01 Feb 2024 13:00:00 GMT

The German automotive giant Mercedes-Benz found itself on the wrong end of a software supply chain incident after RedHunt Labs found a leaked GitHub token belonging to an employee of the carmaker that granted "'unrestricted’ and 'unmonitored'" access to the entirety of source code hosted on Mercedes’ internal GitHub Enterprise Server.

In a post published on Monday, RedHunt Labs said that the exposed token “laid bare sensitive repositories housing a wealth of intellectual property.” That included Mercedes’ “Database Connection Strings, Cloud Access Keys, Blueprints, Design Documents, SSO Passwords, API Keys, and Other Critical internal information.”

The leaked GitHub access token was contained in a public GitHub repository belonging to the employee. In a statement issued to TechCrunch, a Mercedes representative Katja Liesenfeld acknowledged the security lapse. The statement came after the publication informed Mercedes-Benz of RedHunt’s discovery. Mercedes revoked the leaked API token and removed the public repository immediately.

“We can confirm that internal source code was published on a public GitHub repository by human error. The security of our organization, products, and services is one of our top priorities. We will continue to analyze this case according to our normal processes. Depending on this, we [may] implement remedial measures."

Here's what we know about the source code leak — and lessons to draw from it.

[ Key takeaways: State of Software Supply Chain Security 2024 | Get the full report ]

Leaked development secrets: A common problem

Leaked secrets are a problem facing many organizations amidst the shift to modern, agile development with its heavy reliance on open source, third party codes, and platforms. ReversingLabs most recent State of Software Supply Chain Security report, for example, found more than 40,000 secrets spread across four major open-source repositories: npm, PyPI, RubyGems, and NuGet.

In many cases, loose developer practices and the absence of adequate checks for both raw and compiled code were the reason for the security exposure. For example, in the many cases of secret leaks via open source platforms that ReversingLabs observed during 2023, developers placed access tokens in their code or in comments to streamline publishing to these platforms. However, many forgot to remove these access tokens prior to uploading their code. For example, ReversingLabs found a package on an open-source repository with a “notes” file that included the developer’s log along with several tokens.

Mercedes-Benz and security: The best or nothing?

This isn’t the first time Mercedes-Benz has been tripped up by software supply chain security blunders. In May, 2020, for example, ZDNet reported that source code used in smart car components designed by Mercedes-Benz was exposed online as a result of a misconfigured Git registration system.

In that incident, Till Kottmann, a software engineer based in Switzerland, discovered a Git web portal belonging to Daimler AG, Mercedes-Benz’s parent company. According to the ZDNet report, Kottmann said he was able to register an account on Daimler's code-hosting portal, and then download more than 580 Git repositories containing the source code of onboard logic units (OLUs) installed in Mercedes vans.

In January, Mercedes-Benz also featured prominently in the report Web Hackers Versus The Auto Industry, in which a group of independent security researchers led by Sam Curry gained access to hundreds of mission-critical internal Mercedes-Benz applications via improperly configured single sign-on servers. That included accessing multiple Mercedes-Benz Github instances; SonarQube, Jenkins and other build servers; internal cloud deployment services for managing AWS instances; and internal Vehicle related APIs.

When every company is a software company

The struggles of legacy automotive and industrial firms to adapt to a modern and quickly evolving cyber threat landscape are well documented. (Curry and team ultimately discovered serious issues at 19 different automakers and suppliers to the automotive industry.)

What is less appreciated is the way in which cyber risks like software supply chain security lapses can quickly become matters of life and death, said Saša Zdjelar, Chief Trust Officer at ReversingLabs.

“Repositories such as GitHub can include software that eventually makes it to the vehicle as well (as part of the CAN, Car Area Network) and ultimately plays a role in safety and other critical systems such as breaking, sensing, steering, security (eg. Alarm, locking/unlocking), location/tracking, etc. not just media and entertainment."
—Saša Zdjelar

That raises the stakes for companies like Mercedes-Benz to prioritize software supply chain security.

“It’s more critical than ever in world of escalating software supply chain breaches such as this one that companies can attest to regulators, customers, and investors that their software is free of malware; hasn’t been tampered with by a malicious actor; is cryptographically sound; doesn’t include embedded secrets; doesn’t exhibit overly permissive behaviors (including network connections to nefarious hosts); and has been compiled with appropriate hardening and secure configuration.”
—Saša Zdjelar

Supply chain security must go beyond legacy AppSec

Traditional application security tools such as static- and dynamic-application security testing (SAST and DAST), and software composition analysis (SCA) products generally overlook such threats because they were designed in a different era and for different purposes, he said.

But pressure is mounting on companies like Mercedes to address gaps in detection and awareness around software supply chain risk. In its October 2023 report, Mitigate Enterprise Software Supply Chain Security Risks, the analyst firm Gartner noted that the presence of operational and supply chain risks including technical debt and software are “lacking appropriate security controls and checks. Poor maintenance and security hygiene practices suggest an increased risk of vulnerabilities, project abandonment, and other risks at some point in the future.”

HPE, Microsoft breach disclosures mark new era of CISO accountability

paul.roberts@reversinglabs.com (Paul Roberts) — Tue, 30 Jan 2024 13:00:00 GMT

Disclosures about cybersecurity breaches by Microsoft and Hewlett Packard Enterprise (HPE) underscore the influence of two entities that are reshaping the cybersecurity landscape: the SVR and the SEC: Russia’s Foreign Intelligence Service and the U.S. Securities and Exchange Commission.

Increasingly sophisticated hacks by state-sponsored groups such as the SVR, coupled with tighter disclosure requirements, are poised to drive a flurry of legal filings tied to cybersecurity incidents, throwing long-needed sunlight on the struggles of leading corporations to secure their environments, IT assets, and sensitive customer data.

And those firms' chief information security officers (CISOs) are also on notice, following the SEC's recent charges against SolarWinds and its CISO, Timothy G. Brown, for fraud and internal control failures, alleging that the company “misled investors about its cybersecurity practices and known risks” in relation to the 2020 SunBurst attack on SolarWinds.

Here's why this new reality should raise the eyebrows of enterprise leaders — and of CISOs in particular.

[ See Saša Zdjelar's post: CISO accountability in the era of software supply chain | Join Webinar: The Cyber CFO | CISOs and the New Era ]

Pwning 365

First, the hacks. According to statements from Microsoft and HPE, hackers believed to be part of the advanced persistent threat (APT) group Cozy Bear compromised cloud-based email accounts used by the two companies in attacks targeting high-value email inboxes belonging to cybersecurity and legal experts at the companies, as well as senior executives.

In an SEC filing dated January 17, Microsoft said that it detected the presence of a “nation-state associated threat actor” on Jan 12, that “gained access to and exfiltrated information from” the employees’ email accounts. The attack is believed to have begun in November 2023. Microsoft said it is still investigating the extent of the incident and analyzing the information stolen while it works with law enforcement.

A detailed analysis of the incident published on Thursday by the company’s Threat Intelligence Team described a sophisticated attack that began with the compromise of a “legacy, non-product test tenant account” using carefully calibrated “password spray attacks.” Password spraying is a process by which malicious actors use automated means to try to guess their way into protected accounts using lists of common passwords.

Once inside, the intruders gained full access to Office 365 Exchange Online, facilitating the compromise of the users' email inboxes. "Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment,” Microsoft wrote.

Fewer details are known about the attack on HPE. The company's SEC statement, filed a couple of days after Microsoft’s, on January 19, simply states that the company was notified on December 12, 2023, that a “suspected nation-state actor, described as the threat actor Midnight Blizzard (another name for Cozy Bear) gained unauthorized access to HPE’s “cloud-based email environment” — presumably being Microsoft Office 365.

HPE also said the latest incident is likely part of an even larger hack dating to June 2023, involving “unauthorized access to and exfiltration of a limited number of SharePoint files” as early as May 2023. HPE said that it investigated that breach at the time but found that it was not a major threat. “Undertaking such actions, we determined that such activity did not materially impact the company,” HPE said.

The SEC and 'materiality': The clock is ticking

How is it that a successful attack in June on a small number of SharePoint files wasn’t deemed “material” to HPE, but a related attack a few months later on a small number of Microsoft 365 email accounts was? Credit new rules adopted by the SEC in July, some of which went into effect in December.

Those changes saw the SEC redefine requirements for what public companies must disclose with regard to cybersecurity incidents and — even more important — when they must disclose them. Specifically, the SEC’s final rule requires public companies to disclose “the occurrence of a material cybersecurity incident and describe the material aspects of the nature, scope, and timing of the incident, as well as the material impact or reasonably likely material impact of the incident on the company, including its financial condition and results of operations.”

As to when an incident must be disclosed, the new SEC guidelines state that public companies must provide “the required cybersecurity incident disclosure within four business days after the company determines the incident to be material” — an internal inquiry that must take place “without unreasonable delay.”

The notion of “materiality” is a bit squishy, but it broadly defines any information that “a reasonable person would consider important when making an investment decision,” or information that would significantly affect what the SEC describes as the “total mix” of existing public information available about a company. Any doubts about whether information is material “should be resolved in the favor of the investor,” the SEC states.

The new SEC guidelines clearly influenced the disclosures by Microsoft and HPE in this incident. Microsoft, for example, indicated in its SEC filing that it didn’t believe the event was “material” to the company’s operations, but “the Company has not yet determined whether the incident is reasonably likely to materially impact the Company’s financial condition or results of operations.”

HPE said in its filing that “as of the date of this filing, the incident has not had a material impact on the Company’s operations, and the Company has not determined the incident is reasonably likely to materially impact the Company’s financial condition or results of operations.”

So what has changed? The attack on SolarWinds

So why disclose incidents that are “non material”? Simple: the attack on SolarWinds. The recent SEC case against that company and its CISO Brown alleges that SolarWinds and Brown “defrauded investors by overstating SolarWinds' cybersecurity practices and understating or failing to disclose known risks.”

In its filings with the commission during this period, the SEC stated, SolarWinds allegedly misled investors by disclosing only generic and hypothetical risks at a time when the company and Brown knew of specific deficiencies in SolarWinds’ cybersecurity practices, as well as the increasingly elevated risks the company faced at the same time. The group behind the attack on SolarWinds? You guessed it: Cozy Bear.

In other words, for both Microsoft and HPE, a first-take assessment of the most recent incidents may suggest that the operations of those massive, wealthy firms are not materially impacted. However, the SVR’s track record for rooting itself deep inside enterprises and finding novel ways to undermine the security of both them and their customers can’t be taken lightly. That recognition, coupled with the SEC’s tighter breach disclosure requirements and the specter of both corporate and individual fraud charges, tips the scales in favor of disclosure, shedding much needed daylight on incidents that were regularly shrouded in secrecy.

As we all know, sunlight is a disinfectant. The long-term effects of that on the overall security of our technology ecosystem should see some benefit.

More disclosures to come?

The story probably won’t end here. Writing for The Washington Post, Joseph Menn reported that sources inside and outside of the government put the number of affected companies at “more than 10” and “perhaps far more.”

The Cozy Bear attacks come amid heightened offensive hacking activity linked to state-sponsored hacking groups. A ReversingLabs researcher familiar with the work of Russian state actors noted the timing of the hacks:

“This kind of espionage activity is to be expected in times of unrest. Threat actors seek to gain access to privileged accounts with access to sensitive code or information to get the best payout for their efforts.”

Looking further down the road: A threat actor that was able to successfully compromise either Microsoft or HPE’s software supply chain, as happened in the attack on SolarWinds, could potentially gain the ability to push malware directly to the users of those companies' many products, the ReversingLabs researcher said.

GitGot: GitHub leveraged by cybercriminals to store stolen data

lucija.valentic@reversinglabs.com (Lucija Valentić) — Tue, 23 Jan 2024 13:00:00 GMT

ReversingLabs researchers have discovered two malicious packages on the npm open source package manager that leverages GitHub to store stolen Base64-encrypted SSH keys lifted from developer systems that installed the malicious npm packages.

Multiple versions of the malicious npm packages, warbeast2000 and kodiak2k were identified in January, and have since been removed from npm. However, the campaign is just the latest example of cybercriminals and malicious actors using open source package managers and related infrastructure to support malicious software supply chain campaigns that target development organizations and end-user organizations.

Discussion: Malicious packages target developer SSH keys

In recent years, open source package managers and code repositories became ground zero for malicious campaigns. As noted in ReversingLabs' new report, The State of Software Supply Chain Security 2024, the number of malicious packages found on open source package managers jumped 1,300% between 2020 and the end of 2023. That includes everything from low-threat protestware and automated phishing campaigns to more subtle malicious campaigns delivering malware, like the r77 rootkit, directly from open source packages.

Packages on npm grab private keys

In recent weeks, ReversingLabs researchers discovered two suspicious npm packages named warbeast2000 and kodiak2k. Here’s what the research team knows about each.

warbeast2000

On January 3, ReversingLabs researchers using the company's Software Supply Chain Security platform identified a package, warbeast2000, which was suspicious and appeared to be malicious. The package, in itself, was not very complicated. It contained just a few components. The corresponding npm page for warbeast2000 was basic and not obviously mimicking another package.

Furthermore, at the time it was discovered, warbeast2000 was in the process of being developed. There were eight versions (1.0.0 - 1.0.8), with new elements being added to the package with each new version. Malicious functionality was only observed in the last, posted version of the package.

It appears that the package author was in the process of building out the malware and adding layers of deception. Fortunately, the package was detected and removed from npm before that could happen.

Figure 1: Postinstall script

What did warbeast2000 do? Based on our analysis of the final version of the package, once it was installed on a victim's computer, it would launch a postinstall script that fetched and executed a javascript file. This second stage malicious script read the private ssh key stored in the id_rsa file located in the <homedir>/.ssh directory. It then uploaded the Base64 encoded key to an attacker-controlled GitHub repository. And that was it. Besides grabbing and copying the id_rsa SSH key, the package displayed no other behaviors.

The choice of the id_rsa key was a natural one, as id_rsa is the default file name given to ssh keys when running the ssh-keygen program, a standard component of the SSH package on Linux and macOS systems as well as with Git for Windows.

Figure 2: Malicious second stage from warbeast2000

As noted, the warbeast2000 package was probably still under development when it was detected, meaning that what was observed may not be the fully conceived package. It is possible, for example, that the entire contents of the .ssh folder would be sent to a GitHub repository owned by a malicious actor.

The warbeast2000 package was reported to npm administrators and removed on or around January 3.

Kodiak2k

Shortly after discovering the warbeast2000 package, on January 5, the ReversingLabs Software Supply Chain Security platform identified another npm package with very similar behavior: kodiak2k. Unlike warbeast2000, kodiak2k had more than 30 different versions and, apart from the first few, all of them were malicious.

Similar to warbeast2000, kodiak2k runs a postinstall script after the package is installed. That script downloads another javascript file and executes it. As with warbeast2000, that script reads the contents of <homedir>/.ssh directory, though the script is looking for a key named meow. It is not clear whether the developer had a specific key in mind or (more likely) used meow as a place holder name while the package was under development.

Whatever the case, when and if the meow file was located, the key contained in it would be encoded in Base64 and uploaded to a GitHub repository, as with the warbeast2000 package.

Later versions of the kodiak2k package also executed a script found in an archived GitHub project containing the Empire post-exploitation framework. The script also invokes the Mimikatz hacking tool, which is commonly used to dump credentials from process memory. There was more activity, as well, across different versions with additional functions that weren’t necessarily malicious. For example, the team observed functions for running notepad.exe, shutdown.exe and an executable that was deployed locally named cryptor.exe. The purpose of these functions wasn’t clear, though it is possible that the malicious actor responsible for creating the kodiak2k package was in the process of testing different malicious functions for future integration into kodiak2k.

The kodiak2k package was reported to npm administrators and removed on or around January 5.

Figure 3: Malicious second stage from kodiak2k

Keys to the kingdom

Malicious actors looking to obtain SSH keys from developers is an alarming development. SSH keys provide those who hold them the ability to access and contribute to GitHub repositories, including those containing proprietary (non-public) code. As attacks like those on SolarWinds and 3CX show, that level of access can have a serious and negative impact on the security of the software producer, as well as the end user organizations that deploy and use the affected software: fueling devastating software supply chain attacks.

Limited scope

Fortunately, the reach of this campaign was limited. ReversingLabs observed different accounts publishing warbeast2000 and kodiak2k on npm. The warbeast2000 package was downloaded a little less than 400 times, whereas the kodiak2k was downloaded around 950 times.

Abusing GitHub is going viral

One of the recent trends ReversingLabs and other security firms have noted is how attackers are expanding their reliance on open source software and open source development infrastructure to further malicious campaigns. That trend includes the growing use of the GitHub version control platform to host elements of malicious command and control infrastructure.

For example, two years ago, we wrote about the discovery of a malicious npm package masquerading as the Material Tailwind CSS tool that used GitHub to fetch the address of a malicious command and control (C2) server. Then, in a blog post published in August 2023, the research team at ReversingLabs wrote about LunaGraber, an open source information-stealing malware available on GitHub. There was the IAmReboot campaign that the ReversingLabs research team wrote about in October, which described the distribution of malicious NuGet downloaders as well as an obfuscated version of the SeroXen RAT hosted on a GitHub repository. Finally, in December, Karlo Zanki wrote about the discovery of PyPI packages that were using GitHub Gists for hosting two-stage malicious payloads.

These findings align with those of other security organizations. The threat intelligence firm Recorded Future, for example, recently published a report (PDF) that found GitHub was the online service that was the most abused by malicious actors. That abuse includes a range of malicious activity, from payload delivery to command-and-control (C2) and data exfiltration (as ReversingLabs has also observed). Recorded Future termed this behavior "living-off-trusted-sites" (LOTS), and said it is "expected to grow with [advanced persistent threats (APT)s'] increasing usage and less-sophisticated groups swiftly following suit."

Apart from abusing features of platforms like GitHub, there are also concerns that malicious actors might leverage flaws and vulnerabilities in those platforms to further attacks. For example, GitHub recently disclosed a serious vulnerability in the GitHub Enterprise Server (GHES) that potentially exposed sensitive credentials. The vulnerability, CVE-2024-0200, was reported to the company as part of its bug bounty program. It does not appear to have been found or exploited previously. However, SC Magazine reported that the company said it rotates credentials any time they are exposed to a third party.

Conclusion

Fortunately, these malicious packages were detected and reported to npm administrators before they could be widely distributed. That being said, the warbeast2000 and kodiak2k packages are more evidence that legitimate platforms such as GitHub are being used to support supply chain attacks.

That is a concern. With more and more open source malware available, GitHub is increasingly being used by malicious actors to support their campaigns. Often, these open source malware packages are feature rich and come with very detailed documentation allowing even low-skilled hackers (“script kiddies”) to deploy them.

These latest npm campaigns show how malicious actors are starting to use the GitHub platform in novel ways. In addition to GitHub Gists and commit messages being used as C2 infrastructure, we now see GitHub used as a place to store stolen information.

As malicious actors continue to develop new techniques for writing malware, developers as well as security researchers need to be on guard for new threats lurking in public repositories. Before including software or a library found on package managers like npm or PyPI, developers and development organizations should conduct a security assessment of those packages to determine if they are safe to use.

Indicators of Compromise (IOCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of ReversingLabs investigation of this software supply chain campaign.

package_name	version	SHA1
warbeast2000	1.0.8	2da32a4c9e2c3f345f46c6e06d6eb41e13da13d9
warbeast2000	1.0.7	ad888d4e2b05bee35acf61c3cc053ecdc5e6ffaf
warbeast2000	1.0.6	31abb6e4399138b33545ab5dfa3e12fe1ad4d16e
warbeast2000	1.0.5	d4a94f63a25891377334909cd544656b16c2b198
warbeast2000	1.0.3	ba5c8b0b76b798dea60110a296ba842702aacfa5
warbeast2000	1.0.2	d94e7e9f1965c248e17a6629c68f55ffa810e5d5
warbeast2000	1.0.1	f1317027456e02fa5c6cadaf897244fc28c24e31
warbeast2000	1.0.0	663d74c7b76e5aae72ed45b3680fa3efbd17586d
kodiak2k	1.0.42	909927bd61f3466d777bbbff38fd844ed8f5c134
kodiak2k	1.0.40	c6693fa7d0272562dd56ce8b44c0e99dd1210e43
kodiak2k	1.0.39	e762e1456a89218661f97e3ae356c07d35c298e8
kodiak2k	1.0.37	24e376fbbb4c76b6b3c2572efeaa68053fa35202
kodiak2k	1.0.35	7333b0ec183d34a104fd7b9a5f5b93541d39fed3
kodiak2k	1.0.34	8f1311588eae8e2fb4eff6dad523198d49d4a766
kodiak2k	1.0.31	5500ca40b5537f5b6782a143e8e2e9028b92de2d
kodiak2k	1.0.30	c6c77b4385978ab9cc1cab0826e75227d612b62a
kodiak2k	1.0.29	9ccc6f5756bb99c5a4eea9e6abc84b79cb3ae6bd
kodiak2k	1.0.28	8f1d36b074f2f6b7bc28718f88849a6aeb9dbbc6
kodiak2k	1.0.25	717fa522c6ee505002bf17d3e79385544834461e
kodiak2k	1.0.24	245f07892c85807e99a3d9da49677bbd6013ff4f
kodiak2k	1.0.22	5117a318483b62cd40298358618e57350cc4158a
kodiak2k	1.0.21	7165b6329ae524392812c534f9bb7e225e305ffe
kodiak2k	1.0.20	f6fda33768f859bc0b42bae40ac0c7dafa0f8d93
kodiak2k	1.0.19	e70476edc973548abba035993638c1bf3b829d54
kodiak2k	1.0.18	c1be7a6bd11236d1302fc6c0b206ec70b3b66d25
kodiak2k	1.0.16	55f6b8f098ce173f4bfba374fc6da3cd8e0ff435
kodiak2k	1.0.15	d80e1abd7efcd1304a3b5ce1f6302d3a7edaaad9
kodiak2k	1.0.14	13c0ff1347fe631974797aba94d17180ccc8eded
kodiak2k	1.0.13	6f819af455a3b25edc1f27c938cbaaffdbf3d910
kodiak2k	1.0.12	401b2fcd9359215f2f70f39d7d0aa1d50ab09b43
kodiak2k	1.0.11	d0c75071fc20f03d1b6d35ce7240b03c2a79f5c7
kodiak2k	1.0.10	ed6e04e810ff085a1a208788e47cce9352ab58bf
kodiak2k	1.0.9	1d5da7f3fbea3d3915bddeb4c223ba147667a6ba
kodiak2k	1.0.8	fa562e9f3374055812c463b8e36c113a2aafa61c
kodiak2k	1.0.7	3198a29d70628d1b9feaf8f7215c667383007f48
kodiak2k	1.0.6	94836b8471a22563c91d35df6f3a1f5b8e028aa7
kodiak2k	1.0.5	79c4359c0c21c4a6c43062a6e9e894ca0bd5617a
kodiak2k	1.0.4	562238aff7746bdc60f891670c0c8bff46cebe02
kodiak2k	1.0.3	96b336c4fddbd1d91a9d1eacb4c36441880ac5bf
kodiak2k	1.0.2	445922433303e38e227121046d38dd3f31a1d6e0
kodiak2k	1.0.1	30fb4cb07089d4e5773e1f20f0a0b25c34aa20ea
kodiak2k	1.0.0	9300a1ff6bc49aa3f0bfe46245a470f14fc7fac3

Second stage payloads:

SHA1

dba623bdad6bdb37359e047efcda34de4af5f518

9526b820a21fa70641361e061b0f99517ab1b184

GitHub Actions hack bolsters case for complex binary analysis

matthew.rose@reversinglabs.com (Matt Rose) — Wed, 17 Jan 2024 12:30:00 GMT

A novel attack method on GitHub illustrates yet again why application security (AppSec) teams should be implementing in-depth security measures — beyond what legacy application security testing tools can provide.

The attack, discovered by Praetorian security researcher Adnan Khan, involves GitHub-hosted runners, which are virtual machines that execute jobs in a GitHub Actions workflow. There are two kinds of runners in GitHub Actions, which is one of the biggest continuous integration/continuous delivery (CI/CD) services in the market, largely because it's free for public repositories.

Hosted runners are maintained by GitHub for Windows, OS X, and Linux. There are also self-hosted runners, which are build agents hosted by users. Since they're hosted by users, they're also secured by users, which is why GitHub advises against using self-hosted runners on public repositories.

Khan described in a deep-dive blog post how he discovered a critical misconfiguration vulnerability that provided access to GitHub's internal infrastructure, as well as secrets — and how that access could have been used to inject malicious code into all of GitHub's runner base images, allowing an attacker to conduct a supply chain attack against every GitHub customer that used hosted runners.

Here are the key takeaways from the threat research — and why you need to evolve your AppSec approach with complex binary analysis and reproducible builds.

[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]

How attackers could leverage runners for mischief

By default, when a self-hosted runner is attached to a repository, any workflow running in that repository’s context can use that runner. As long as the runs-on field is set to self-hosted, the runner will pick up the workflow and start processing it, Khan said.

For workflows that are on default settings and that feature branches, this isn’t an issue, he continued. Users must have write access to update branches within repositories. The problem is that this also applies to workflows from fork-pull requests.

By changing a workflow file within their fork and then creating a pull request, anyone with a GitHub account can run arbitrary code on a self-hosted runner.

There is one roadblock, but not a very formidable one: GitHub requires a user to be a previous contributor to a repository before their workflows from pull request forks will run without approval. Becoming a contributor, however, is as simple as correcting a typo or making a small code change.

Acceptance of contributors to these repositories may be too lax, but any criticism here must be tempered by reality. A lot of these projects aren't maintained by a lot of people. There's usually a small number of key individuals spearheading the project. They're trying to do things in the right way, but there are bad guys out there seeking to exploit capabilities that are intended for good.

An unforeseen attack vector?

One other condition must be met before an attacker can work their mischief. The self-hosted runner must be non-ephemeral, which means that it is possible to start a process in the background that will continue to run after the job is completed. By default, self-hosted runners are configured to be non-ephemeral.

Once the runner-images repository was set to the default approval setting, had a non-ephemeral self-hosted runner, and the attacker’ had a contributor’s account, they had everything necessary to conduct a public Poisoned Pipeline Execution attack against the runner-images repository’s CI/CD workflows, Khan wrote.

According to a SecurityWeek report, the researchers limited their investigation to repositories belonging to organizations that would pay out high rewards through their bug bounty programs, and have submitted over 20 bug bounty reports, raking in hundreds of thousands of dollars in bounties.

If you're having trouble fixing the flaws that you know about, how are you going to protect against the unknowns? If you don't know what to look for, you won't find it.

This discovery shows how software supply chain attacks are constantly changing. People using these runners never thought they could be used in this way. The organizations that paid the bug bounties after being told about the risk had no idea they were vulnerable. If you're having trouble fixing the flaws that you know about, how are you going to protect against the unkowns? If you don't know what to look for, you won't find it.

Software complexity demands better AppSec tooling

Developing software these days is very complex. There are many moving parts — first-party code, open-source code, and third-party code — and it's hard to think of every potential lever and dial that needs to be appropriately configured. That's why, in addition to traditional application security testing, before the software is released, you need a sort of final exam for the complete software packages, to comprehensively vet and compare complete software packages.

This compromise of GitHub Actions illustrates why organizations need defense in depth. You can't just look at one or two things and feel secure. You have to look at everything. That's why software versions need to be compared to one another. You can't just look at the pieces of the puzzle because, even if the pieces fit together, the final picture may not look like what's on the cover of the box. Only by comparing one version or one build to another can you see what's changed and if those changes are acceptable and correct. That kind of differential analysis is needed to discover the fingerprints of tampering, compromise, or the insertion of malware.

[Differential analysis] is needed to discover the fingerprints of tampering, compromise, or the insertion of malware.

Evolve your AppSec approach

There's no such thing as a 100% secure software application. You never know when something is going to be manipulated in a way you never thought about. There are always risks that are either unknown or being addressed.

Security teams try to do the best they can with what they have. AppSec tools have evolved — from SAST, to DAST, and then software composition analysis (SCA). With the pace and complexity of modern software development, AppSec tools that allow defense in depth to be done at many stages of the process, including the final stage — post-compilation, pre-deployment — are now a requirement.

The Enduring Security Framework, a public-private working group led by the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), recently stepped up its software supply chain security guidance with a call to for binary analysis and reproducible builds to manage risk.

Complex binary analysis, which focuses on malware, can help organizations evaluate and verify the security of not just internally developed software, but also third-party commercial software in their environment, providing that much-needed final exam.

The State of Software Supply Chain Security 2024: Key takeaways

carolynn.vanarsdale@reversinglabs.com (Carolynn van Arsdale) — Tue, 16 Jan 2024 15:55:54 GMT

Software supply chain attacks are now mainstream events — a change in tactics by cyber-attackers that you can measure in headlines, which in recent years have delivered news about attacks on popular software tools including MOVEIt, 3CX, and CircleCI.

What’s behind this change? An explosion in supply chain threats, for one thing. ReversingLabs' State of Software Supply Chain Security 2024 report finds that incidents of malicious packages found on popular open-source package managers have increased by 1,300% over the past three years. Despite that, however, the software industry at large still hasn’t woken up to the changing landscape of software supply chain security threats. Loose development practices and inattention to software supply chain risks persist, ReversingLabs found.

The State of Software Supply Chain Security 2024 is ReversingLabs’ second annual assessment of software supply chain security. The report gives an overview of the 2023 threat landscape, analyzes what has changed since 2022, and anticipates what the industry can expect in 2024.

In assembling the report, the ReversingLabs research team surveyed the software supply chain threat landscape. They not only observed an increase in the number of malicious incidents, but also saw that the bar for carrying out successful supply chain attacks is lowering, as more and different types of malicious cyber-actors incorporate aspects of supply chain attacks into their playbooks and tooling.

Equally concerning: Stakeholders in the software supply chain, such as software developers, application security (AppSec) teams, open-source maintainers, and third-party risk managers are struggling to address the gaps in their software supply chain security, making it less likely that they will successfully mitigate threats.

Here are the important takeaways from the State of Software Supply Chain Security 2024 report.

[ Get the new report: The State of Software Supply Chain Security 2024 | See the Webinar: State of Software Supply Chain 2024 ]

Software producers and consumers have a blind spot

In 2023, examples continued to pop up of threat actors going beyond the exploitation of vulnerabilities to carry out software supply chain attacks. In March 2023, for example, voice over IP (VoIP) vendor 3CX disclosed that a version of the company’s 3CX Desktop App software was distributed with malicious code to thousands of customers.

ReversingLabs’ analysis of the incident found that attackers managed to compromise 3CX’s software build pipeline, making modifications to 3CX’s copies of standard open-source files to insert malicious code into the finished 3CX Desktop App package. While there were signs of tampering, 3CX unfortunately failed to detect the evidence of it before it released the software to its customers — and long afterwards as well.

The case of 3CX Desktop App showcases the blind spot that software producers have in the security measures they use to ensure that software releases are secure post-deployment. It also demonstrates how consumers are subject to such third-party malicious threats if they don’t use proper tooling to vet their third-party software providers. Software-producing and -consuming organizations need to choose tools that go beyond detecting vulnerabilities to avoid this security blind spot.

That’s why, in addition to using legacy AppSec tools such as software composition analysis (SCA) and static and dynamic application security testing (SAST and DAST), stakeholders of software supply chains should also opt in to tooling that analyzes raw code and tracks the evolution of compiled software binaries. This technology will help organizations identify unwanted or unknown changes made to a software package, such as malicious tampering.

A lower bar for software supply chain attacks

Software supply chain attacks used to be an exclusive realm for sophisticated, nation state-backed hacking crews. This is changing. Based on data compiled from ReversingLabs, the bar for software supply chain attacks dropped steadily in 2023, and ReversingLabs experts believe that it will continue to decline in 2024.

By scouring common open-source repositories, ReversingLabs researchers discovered a number of open-source software supply chain attacks in 2023 that were delivering malware such as infostealers, backdoors, protestware, and more.

There are a number of reasons for this. First, open-source software repositories, such as npm, Python Package Index (PyPI), and NuGet are growing as attack surfaces. In 2023, ReversingLabs saw a 28% increase from the year before in the total number of malicious packages uploaded to open-source repositories. Those malicious packages are easy to place and open the door to techniques such as typosquatting, repojacking, and other tricks that play on the goodwill (or haste) of developers who rely on open source code and package managers.

The other reason that the barrier to carrying out a software supply chain attack is dropping is that cyber-criminals are embracing supply chain attacks to enhance common, low-level campaigns such as phishing attacks. For example, Operation Brainleeches, discovered by ReversingLabs researchers in July 2023, displayed what may be the first “dual-use” campaign via npm, in which over a dozen malicious packages uploaded to the widely used repository were used to fuel phishing campaigns that targeted Microsoft 365 end users in addition to npm developers — the more typical target of malicious campaigns on these platforms.

The case of Operation Brainleeches targeting two different kinds of victims, as well as the increase in open-source software supply chain attacks this year, showcases how these incidents are becoming easier to pull off and more difficult for security teams to manage.

Big changes, but more of the same, too

While there have been substantial changes in the threat landscape this past year, the goals and tactics of threat actors stayed fairly consistent compared to what was seen in the past.

As noted before, ReversingLabs' new report cites a 28% increase in the number of malicious packages across open-source repositories. That increase is on track with earlier years. However, when breaking down the numbers by each repository, ReversingLabs researchers noted some interesting changes. For instance, there was a 400% increase in the number of packages residing on the PyPI open-source repository in comparison to 2022, yet 2023 saw a 43% decrease in the number of malicious packages on npm, despite it being the primary repository used for the dissemination of malicious packages the previous year.

The significance of these changes between npm and PyPI is not clear. It may be due to the growing popularity of PyPI among the developer community. With the increased use of the Python programming language and the PyPI platform, threat actors are seeing it as the more worthy target for malicious packages. Or it may be a momentary fluctuation in malicious supply chain activity that will not be sustained.

Despite the variability of threat trends, one trend line that continued its journey upward was the amount of software secrets lurking on open-source platforms. ReversingLabs found more than 40,000 secrets spread across four major open-source repositories: npm, PyPI, RubyGems, and NuGet. The total amount found is unsurprising, given how secrets leaks have emerged in recent years as a consistent software supply chain weakness — one rooted in loose application design and modern-day development practices.

Typically, secrets are attributable to a number of sources, such as API keys, security tokens, credentials, and more that provide access to resources such as Google, GitHub, and AWS. That was the case again this year, with one notable addition to the list of top sources of leaked secrets: OpenAI, the artificial intelligence start-up behind ChatGPT. OpenAI alone accounted for 19% of all leaked secrets on the PyPI platform in 2023, as well as 18% on the RubyGEMS platform, ReversingLabs researchers discovered. Leaked OpenAI API tokens accounted for almost all of that, reflecting the growing use and popularity of OpenAI’s ChatGPT AI chatbot. As with the discovery of more than 1,500 leaked API tokens on the Hugging Face machine-learning platform, the leaks of OpenAI’s API tokens could expose sensitive files, images, and AI models for organizations with leaked tokens, according to ReversingLabs.

These changes and consistencies in the threat landscape underscore the need to continue taking software supply chain security seriously — in particular, open-source threats and secrets leaks. And while the number of threats changed this past year, the fundamentals of what needs to be protected has largely stayed the same since 2022.

Read the full report to learn more

Many of the trends identified in 2023 are likely to continue or deepen in 2024 as policymakers wrestle with the fallout of attacks such as the Clop gang’s campaign against users of Progressive Software’s MOVEIt secure file transfer application and contemplate ways to hold private-sector software producers accountable. That, along with growing scrutiny by both governments and industry regulators, means that software publishers are under growing pressure to devote resources and time to shoring up the security of their development organizations.

ReversingLabs' new report explores that trend for 2024, as well as others, including:

Changes in the cyber-underground
A higher regulatory bar for incident disclosure and software supply chain security efforts
The evolution of federal government guidance on software supply chain security

A (partial) history of software supply chain attacks

paul.roberts@reversinglabs.com (Paul Roberts) — Tue, 16 Jan 2024 15:30:00 GMT

The widespread campaign of software supply chain hacks that were behind the attack on SolarWinds began in 2020, and unofficially elevated software supply chain security to the top echelon of cyber risks to both government and the private sector. Subsequent events, like the emergence of the Log4Shell vulnerability in the Log4j2 open source library, underscored that software supply chain risk is for real.

However, if you are thinking that supply chain threats and attacks as a new problem plaguing software producers and their customers, you are wrong. In fact, software supply chain attacks have been with us for years — decades even — though they haven’t always demanded the kind of attention and response they now receive.

Below is a list of known software supply chain attacks, compiled from public records and reporting. This list is — of course — incomplete. First: it is likely that there have been supply chain attacks in which the details have not been made public. Second, these attacks are happening all the time, making any accounting of software supply chain attacks incomplete. Finally, opinions on what constitutes a software supply chain attack can differ from expert to expert.

[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]

A chronology of software supply chain attacks

Below is a list of known (documented, reported) attacks involving compromises of software supply chains (from latest to oldest).

The evolution of AppSec: 4 key changes required for a new era

ericka@chickowski.com (Ericka Chickowski) — Thu, 11 Jan 2024 19:09:39 GMT

Software development continues to swiftly advance and also to entail more complex dependencies, with continuous integration/continuous development (CI/CD) bringing faster code releases. Meanwhile, application security (AppSec) is struggling to keep up with its practices and tooling.

Ahead of both development and AppSec, however, are attackers, who have adjusted to the changes in development patterns. Both the scale of attacks afforded attackers by cloud-native development and the interconnected reusability of components in the modern software supply chain have been a boon for them.

Attacks such as Sunburst, which was behind the SolarWinds compromise, and last year's MOVEIt attest to how easy it has become for attackers to cut through tens of thousands of targets at once with a precise blow against a weak link in the software supply chain.

Even though AppSec has evolved in recent years, it's not changing fast enough. Today's software development practices and tool chain remain woefully unprotected from attacks, and legacy AppSec tools and practices are failing the teams charged with securing their releases or managing risk in their organizations.

In 2024, AppSec must make a giant leap forward to modern practices and tooling in order to tackle the new era of software supply chain attacks. Here are the four essential changes needed.

[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]

A brief history of AppSec

For the better part of 20 years, the world of AppSec has been locked into an evolutionary game of innovation leapfrog. Every time a new iteration of application scanning or testing comes along, the development world changes. Waterfall shifted to agile, agile morphed into DevOps, and DevOps refined itself with cloud-native principles and rampant reuse of components through microservices. And throughout it all, new programming languages kept growing in popularity, further adding complexity to the task of examining code, configurations, and overall security of applications.

Attackers adjusted quickly, picking apart new weaknesses and coming up with stealthier attack methods against the software ecosystem, while keeping most of their old attack methods in play for as long as they could.

That means AppSec pros must leap into new tooling while carrying all the old tooling and practices. The industry started with generic web application scanners such as those from SPI Dynamics, and those later bifurcated into the staple duo of static application security testing (SAST) and dynamic application security testing (DAST). From there interactive application security testing (IAST) came to fill in the gaps left by SAST/DAST, and layered on top came software composition analysis (SCA).

In short, AppSec has to manage a mashup of legacy tools. "This has created so much tool sprawl in the industry," said Matt Rose, field CISO for ReversingLabs.

"In the AppSec testing market, all the solutions that are out there are always chasing the changes in the way software is being developed. And if you're in the industry long enough, you see that one of the biggest things that drives any AppSec tooling — whether SAST, DAST, or IAST — is, 'What languages can it scan?'"
—Matt Rose

A call to action on AppSec tooling and practices

This overload for AppSec teams has led many involved in the industry to call for systemic changes. On the government side, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) last year introduced Secure by Design and the Cybersecurity Framework 2.0, with a focus on software supply chain security. The analyst firm Gartner is also on board, with its latest guidance pushing for software supply chain security and third-party risk management to be better merged within the greater cybersecurity strategic framework.

In order to support these changes, organizations need new tooling. Companies require comprehensive software supply chain security, including complex binary analysis. However, Rose said that while tools that provide comprehensive software supply chain security are essential, companies cannot get rid of their legacy tools overnight.

"People are struggling with just reams of data, and they're releasing software faster and faster and faster. So it's like every time you do a scan, if you integrate it into your build, you just have more information than you can process. So now you know your house is on fire, but you don't know which room it is. It's like all the rooms are on fire at once. There are alarms going off everywhere."
—Matt Rose

With companies facing increasing risk for software supply chain attacks, you need to evolve your AppSec approach so that it can keep up with software engineering — and attacker adaptations. Here are four things that experts say need to happen.

1. Software supply chain security demands transparency

As organizations move to building and using software bills of materials (SBOM) more thoroughly, the industry is going to have to decide how to make SBOMs truly comprehensive. Currently, gaining transparency into the open-source dependency chain has received hyperfocus, at the expense of the bigger problem: the composition and dependencies within commercial software. This was one of the big points made in the Gartner report, said Saša Zdjelar, chief trust officer at ReversingLabs and a former chief information security officer at ExxonMobil.

"As an industry, we're struggling with the definition of 'comprehensive.' In my world, comprehensive means 'everything, with no excuses.' But a lot of companies who say, 'We do SBOM,' define 'comprehensive' as, 'As long as it's only open source, and as long as it's only one of these seven file types, and as long as it's less than 65 megs size, then we're comprehensive.'"
—Saša Zdjelar

Zdjelar said that comprehensive transparency of dependencies is essential if organizations are going to truly address their AppSec risk across the supply chain and use SBOMs to remediate or at least mitigate risk preemptively and to effectively respond to incidents.

2. AppSec pros must conduct practices like a symphony

The evolution of AppSec tooling thus far means that practitioners are going to have to become a lot better at integration, tools orchestration, and delegation, said Rose.

"Successful AppSec people think of their roles as like being the conductor of a symphony. I think the most effective way to do it is doing identification at the CI orchestration layer and then remediation based on the expertise layer."
—Matt Rose

3. Prioritized action and automation are key

All of that delegation and orchestration of identification and remediation can't be done manually, and it can't be done all at once — in fact, some of it may be of a low enough priority to not be done at all. And prioritization will be key in 2024, with an emphasis on elevating how tooling can signal prioritized action and on improving automation so that priorities are met. The goal is making AppSec more efficient without losing the insights from the tools it has added over the years.

John Funge, managing director of the security venture capital firm DataTribe, said that in the age of supply chain attacks, AppSec must go beyond "shift left."

"There is a growing movement behind the idea that digital products need to be built more securely in the first place, that is, Secure by Design. It’s more than 'shifting left.' Rather, it’s a realization that the entire software development lifecycle needs to be reoriented to elevate security to the same level as user experience, performance, and reliability in the minds of product development teams."
—John Funge

Funge said that the company founders he's been working with are seeing opportunities to build up capabilities that make things easier for security teams and the developers they work with.

"We are seeing an increased emphasis on helping teams to identify not just vulnerabilities in libraries they use, but also how impactful each particular vulnerability will be depending on the context of how that specific system uses the library. There is a movement afoot to fuse static and dynamic application testing principles to deliver better results and greater efficiency."
—John Funge

Rose said integration and automation will be crucial to dealing with AppSec, given the speed of DevOps pipelines today.

"People are releasing sometimes thousands of times a day with microservices architecture. It has to be automated. If it's manual and it takes a day to do something, ... you're already behind."
—Matt Rose

4. Software packages need a final exam

AppSec threat mitigation is no longer primarily about finding and fixing vulnerabilities. It's more about catching malware that has sneaked its way into the software supply chain. Henrik Plate, security researcher for Endor Labs, said to expect to see a whole lot more of that in 2024.

"In the past few years, registries like PyPI, npm, or Rubygems.org were the primary focus of attackers, but the deployment of malicious packages using techniques like typosquatting has already extended to other component registries or marketplaces, and this trend will continue. Attackers will refine obfuscation and evasion techniques and continue to conduct bigger malware campaigns, with hundreds or thousands of malicious software packages deployed in short time frames, because running such campaigns is relatively cheap."
—Henrik Plate

One of the reasons attackers are finding it easy to slip malicious packages into software is that organizations have been so focused on shifting left — doing their testing early in the release cycle — that they're forgetting that checks need to happen before software releases, Rose said.

"We have to be diligent and shift security everywhere. We especially need a 'final exam' to check for potential risk or compromise before each release."
—Matt Rose

These last checks need to be built into the development workflow to look for malware injections, tampering and other problems like secrets leaks or other identity problems.

Comprehensive supply chain security is now a requirement

When it comes to managing risk across the software development lifecycle (SDLC), Rose said modern tooling that can deliver such a final exam is key, citing the Enduring Security Framework group's call to for binary analysis and reproducible builds to manage risk.

2023 Updates in Review: Malware Analysis and Threat Hunting

contact@reversinglabs.com (ReversingLabs) — Wed, 10 Jan 2024 12:30:00 GMT

Throughout ReversingLabs’ 14-year history, our products have constantly excelled and improved to tailor the needs of our customers and match the changing cybersecurity threat landscape. 2023 was no exception to this growth in product quality. This past year, we have delivered key improvements to ReversingLabs Threat Intelligence, Elastic Threat Infrastructure, and Threat Analysis & Hunting solutions, providing more efficient and cutting-edge platforms fit for the busy security practitioner.

Here are the major improvements to ReversingLabs malware analysis and threat hunting solutions in various areas that are helpful to our customers.

Dynamic Analysis

To mitigate modern-day threats and potential attacks, a complete understanding of malware behavior is a must. ReversingLabs continues to increase file analysis depth and coverage by combining our high-speed static analysis with new dynamic analysis capabilities.

In 2023, ReversingLabs further enhanced our RL Cloud Sandbox dynamic analysis capabilities for the A1000 and TitaniumCloud.

Figure 1: Display of RL Cloud Sandbox Analysis Summary.

File classification has been improved by additionally using RL Cloud Sandbox dynamic analysis results with ReversingLabs proprietary static analysis, simplifying the process of deciding if a sample is malicious. For the A1000 platform, improvements include the ability to automatically download dropped files from RL Cloud Sandbox and analyze these files using RL’s TitaniumCore static analysis, eliminating the need to download artifacts locally. For TitaniumCloud, the solution’s dynamic analysis capabilities have been expanded to support MacOS, Linux, and Windows 11 profiles, all in a single interface.

Network Threat Intelligence

ReversingLabs has the largest private repository of goodware and malware files in the world, which continues to grow each day. We know the importance of having validated, up-to-date file and network threat intelligence and the necessity to constantly improve on our solutions’ capabilities so that customers can trust and best utilize this data corpus. 2023’s improvements in this area consisted of updates to RL’s TitaniumCloud and TitaniumScale platforms.

Figure 2: A view of a domain search involved in malicious activity.

For TitaniumCloud, users can now get up-to-date domain and IP reputations for blocking pertinent threats, based on a list of top threats, reputation data from various sources, statistics for downloaded malicious files, and a list of related URLs. Additionally, TitaniumCloud now delivers more lightweight, fast and simple lookups for domains, IPs, and URLs, which better automates network reputation workflows. Regarding TitaniumScale, users now can configure the retrieval of TitaniumCloud reputation for all network IOCs (Indicators of Compromise) found during file analysis, which enables valuable insights into potential threats and vulnerabilities.

Data Visualization

ReversingLabs understands how important it is for SOC teams to analyze data efficiently and meaningfully, which is why continual enhancements and improvements to data visualization are a must. This year, the A1000 platform had several data visualization improvements. These include a more intuitive navigation design for users when previewing samples, eliminating the need for a user to open an individual sample summary screen just to assess it. Also, antivirus detections are now displayed on the Cloud Sample Summary page and an expanded row from the Search interface improves the efficiency of triage processes for A1000 users.

Figure 3: Display of expanded row sample preview in the A1000 platform.

Threat Hunting

Easing the job of threat hunters is what we do best, which is why ReversingLabs prioritizes improving such capabilities within our solutions. For the A1000 platform, improvements in 2023 included a new and intuitive Relationships Graph, which offers a simplified, node-based graphical overview of opened samples and all metadata connected to them. This gives enterprise SOCs a straightforward visual understanding of a sample and its related network data and files.

Figure 4: Display of the A1000 platform’s Relationships Graph.

YARA Rules

YARA is another area ReversingLabs continues to make improvements and enhancements to help threat hunting teams. In 2023, this included improving YARA import workflows by making it easier to upload rulesets from 3rd party repositories, as well as allowing users to select individual rules during the import of larger YARA rulesets. Another key YARA improvement is a ‘test run’ option so users can quickly validate newly created rulesets against a subset of samples, saving significant development time when it comes to writing and refining YARA rules.

File Analysis

For improved file analysis, ReversingLabs made several updates to the TitaniumScale platform in 2023. Users now have more control over TitaniumCore performance through the ability to choose between two processing modes: high-speed or rich report metadata. Additionally, new options for file analysis outputs reduce report sizes and process faster than before, creating a more efficient workflow.

Automations and Integrations

Making our solutions more intuitive and compatible with other services is a high priority for our team, which is why several notable improvements have been made to the TitaniumScale platform in 2023. This includes an updated global navigation bar for better visibility into supported integrations, connector configuration, and statuses, as well as ease of administration for the user. An additional improvement to the platform is a centralized interface for automated deployment, configuration and updating of all appliances managed by C1000, improving workflow efficiency, and ensuring consistency.

Figure 5: Improved centralized interface for appliance management

User Experience

ReversingLabs takes the user experience (UX) seriously for all of our solutions, which is why the TitaniumScale platform underwent new UX improvements in 2023. One of these updates is that files can now be examined on C1000’s Analytics Dashboard, delivering live insights into detected threats. This provides greater visibility into an organization’s security posture and improves the efficiency of hunting and triage workflows for the SOC. In addition, SOC analysts can now perform further analysis of files via one-click pivoting to the A1000 Sample Summary from the C1000 Analytics Dashboard, which enhances investigation and hunting workflow efficiency for security teams.

Figure 6: C1000 Analytics Dashboard with one-click pivoting to A1000 sample summary

The Work Doesn’t Stop Here

The improvements ReversingLabs made to its solutions in 2023 empower our customers to more efficiently manage their enterprise SOCs and mitigate any modern-day cyber threats coming their way. RL is constantly staying up to speed with today’s threat landscape to ensure that our solutions properly serve our customers' needs. Change is constant in cybersecurity, so our customers can expect more improvements to ReversingLabs Threat Intelligence, Elastic Threat Infrastructure, and Threat Analysis & Hunting solutions in 2024.

Zoom joins the vulnerability fray: Will VISS move the needle on AppSec?

jpmellojr@gmail.com (John P. Mello Jr.) — Tue, 09 Jan 2024 16:03:54 GMT

Zoom, best known for its online videoconferencing and collaboration platform, is getting into vulnerability management. The company has announced its Vulnerability Impact Scoring System (VISS), a free-to-use framework for evaluating the impact of security vulnerabilities on computer systems infrastructure, technology stacks, and protected data.

VISS is designed to "objectively" capture the principal impact characteristics of software, hardware, and firmware vulnerabilities, Zoom said. While the industry-standard Common Vulnerability Scoring System (CVSS) is used to subjectively evaluate vulnerability reports primarily from an attacker’s perspective and assumes the reasonable worst-case impact, Zoom explained, VISS focuses on measuring the responsibly demonstrated impact of a vulnerability from the defender’s perspective.

The theoretical possibility of exploitation is not considered with VISS, but rather only the actual exploitation that has been demonstrated, Zoom said. The numerical scores generated indicate the relative impact severity within the given environment. It is important to understand that VISS is not meant as a replacement for CVSS, but as a complementary system of evaluation, the company stressed.

Zoom's VISS is not the first effort to move the ball forward on vulnerabilities with scoring. The Exploit Prediction Scoring System (EPSS), first launched in April 2020, advanced to version 3.0 late last year as a complementary tool to CVSS, by adding more value to software risk scoring, combining descriptive information about vulnerabilities — and evidence of actual exploitation in the wild.

Here's what you need to know about Zoom's VISS, how it compares to EPSS — and how it can advance your application security (AppSec).

[ See ReversingGlass: EPSS 3.0 + CVSS: Why Prioritizing Software Risk is Key | Learn more: Why AppSec teams should go beyond legacy vulnerabilities ]

How VISS measures vulnerability impacts

VISS aims to provide greater efficiency, taking into account more infrastructure and environmental factors, and ideally providing focus on the highest-impact vulnerabilities, said John Gallagher, vice president of the IoT security firm Viakoo Labs.

"Organizations need efficiency in cybersecurity operations, both because of limited security resources and because the longer it takes to react to a vulnerability, the more possibility there is for exploitation."
—John Gallagher

VISS metrics, which produce scores from 0 to 100, take into account 13 aspects of impact for each vulnerability:

Platform type, which allows the user to specify the type of computing platform impacted by the security vulnerability, not necessarily where the security vulnerability was found.
Platform confidentiality, which allows the user to specify the impact on the confidentiality of the platform by the successful exploitation of the security vulnerability found.
Platform integrity, which allows the user to specify the impact on the integrity of the platform by the successful exploitation of the security vulnerability found.
Platform availability, which allows the user to specify the impact on the availability of the platform by the successful exploitation of the security vulnerability found.
Infrastructure tenancy, which allows the user to specify the tenancy of the infrastructure on which the security vulnerability was found, but only when there is some level of platform impact present.
Software tenancy, which allows the user to specify the tenancy of the software on which the security vulnerability was found.
Data tenancy, which allows the user to specify the tenancy of the data on which the security vulnerability was found.
Tenants impacted, which allows the user to specify a summary range of tenants impacted by the successful exploitation of the security vulnerability found.
Data confidentiality, which allows the user to specify the impact on the confidentiality of the data involved by the successful exploitation of the security vulnerability found.
Data integrity, which allows the user to specify the impact on the integrity of the data involved by the successful exploitation of the security vulnerability found.
Data availability, which allows the user to specify the impact on the availability of the data involved by the successful exploitation of the security vulnerability found.
Data classification, which allows the user to specify the internal classification of the data involved in the successful exploitation of the security vulnerability found.
Upstream compensating controls, which allows the user to specify the existence of any compensating security controls within the impacted software or infrastructure that have a positive defensive impact against the successful exploitation of the security vulnerability found.

How VISS fills gaps in the CVSS

New scoring frameworks such as VISS are emerging to address specific needs or perspectives that CVSS might not fully cover, said James McQuiggan, an advocate at the security awareness training company KnowBe4.

“While CVSS is often criticized, using EPSS or VISS has the potential to provide more tailored or comprehensive assessments for particular environments or threats. The EPSS is also open source and can be updated or openly discussed, whereas the CVSS is controlled, with very few adjustments without significant changes or implementations.”
—James McQuiggan

Zoom said that while it owns all rights and interests in VISS, it licenses it to the public free for use, subject to certain conditions. Zoom also requires that any individual or entity using VISS give proper attribution, where applicable, that VISS is owned by Zoom and is used with permission. In addition, Zoom requires as a condition of use that any individual or entity that publishes VISS scores provide both the score and the scoring vector so others can understand how the score was derived.

Zoom also noted that unlike CVSS, VISS metric options and the weights assigned to those options are customizable by the user as needed to meet the needs of the overall environment, software, and data involved. This flexibility allows each organization to use VISS in a manner specific to it industry, requirements, and risk profile, it added.

Daniel Kennedy, research director for information security and networking at 451 Research, which is part of S&P Global Market Intelligence, said the CVSS has been criticized, sometimes unfairly, for not considering different contexts that may affect vulnerability severity. But he said VISS could end up “yet another standard."

"Folks tend to create these things in pursuit of solving some problem, whether it be the current models not addressing their specific use case, or existing models having more general gaps.”
—Daniel Kennedy

Going beyond vulnerability management alone is key

Vulnerability management has become the battle cry of the cybersecurity world, with organizations drowning in a sea of vulnerabilities and struggling to prioritize remediation efforts, said Sarah Jones, a cyberthreat intelligence research analyst at the cybersecurity services firm Critical Start.

“This is where vulnerability scoring systems like VISS and EPSS step in, offering guidance through the storm."
—Sarah Jones

Although both systems aim to address deficiencies in CVSS, they approach their mission in different ways, Jones said. "It analyzes 13 factors and assigns 0 to 100 severity scores based on actual damage from past exploits,” she said.

“Think of VISS as a data-driven post-mortem."
—Sarah Jones

VISS aligns vulnerability patching with demonstrably impactful threats, supporting incident response and mitigating ongoing attacks, Jones said.

“However, it doesn't predict future assaults, leaving them lurking in the shadows.”
—Sarah Jones

VISS vs EPSS: How they compare

EPSS takes a forward-looking approach using threat intelligence and vulnerability characteristics to estimate the chance of exploitation within 30 days.

“Like a security weather forecast, it identifies storm clouds most likely to unleash fury, enabling proactive risk mitigation. However, its reliance on complex algorithms and limited historical data introduces uncertainties, requiring cautious interpretation.”
—Sarah Jones

VISS and EPSS are complementary tools, not rivals, Jones said. “Choose based on your priorities — address past damage with VISS or predict future threats with EPSS. Combine their strengths with CVSS to navigate the cybersecurity landscape.”

Proactive vulnerability management is a strategic investment in your organization's future, Jones said. “By understanding these systems and taking a holistic approach, you can stay ahead of the curve and keep those vulnerability monsters at bay.”

However, McQuiggan cautioned about obsessing over vulnerabilities in general.

“Focusing on vulnerabilities is a proactive approach to cybersecurity, aiming to prevent exploits before they occur. However, it should be part of a broader security strategy that includes protection against malware, zero-day exploits, and social engineering, since addressing vulnerabilities is not a silver bullet and does not guarantee defense and risk reduction against all cyber threats.”
—James McQuiggan

Matt Rose, field CISO for ReversingLabs, said security teams are facing alert fatigue "across the board," so new vulnerability scoring systems are a step in the right direction.

"There's just not enough time, resources, and budget to address everything."
—Matt Rose

Rose said the increase in sophisticated supply chain attacks means its time to go beyond vulnerabilities when it comes to managing risk across the software development lifecycle (SDLC). He advocates for focusing on active malware instead, citing the Enduring Security Framework group's call to for binary analysis and reproducible builds.

"It is the final examination of a package for software supply chain risk, which allows for trust in that piece of software that you are either developing for your customers or that you are buying to help operate your business."
—Matt Rose

A definitive guide: Federal software supply chain security initiatives

carolynn.vanarsdale@reversinglabs.com (Carolynn van Arsdale) — Thu, 04 Jan 2024 17:10:00 GMT

Software supply chain security is now top-of-mind for software producers and enterprise consumers alike, given the dramatic increase in threats (as noted in ReversingLabs' State of Software Supply Chain Security 2024 report) — and the steady growth in software supply chain attacks. But the private sector isn’t alone in taking notice of the epidemic.

The U.S. federal government has turned its attention to software supply chain security in recent years, and more recently it has stepped up its guidance with more comprehensive initiatives such as Secure by Design and specific guidance on tooling with the Enduring Security Framework's call for comprehensive binary analysis and reproducible builds.

What started with the White House’s Executive Order on Improving the Nation’s Cybersecurity (EO 14028) has grown into a comprehensive trove of compliance and guidance initiatives that has shaped the federal government’s policies on software supply chain security. Three years after EO 14028’s initial release, these efforts have begun to take effect, forcing software producers — particularly those that do business with the federal government — to take notice.

However, it's not just software organizations working with the government that need to get up to speed on guidance. Analyst firm Gartner notes in its “Mitigate Enterprise Software Supply Chain Security Risks” report that open-source communities and enterprises alike should increase their scrutiny of supply chain risks and take action to prioritize software supply chain security protections.

Here are 2023’s major federal initiatives for improving software supply chain security, including a breakout of guidelines versus mandates. Combined with our definitive timeline for software supply chain security guidance, teams can better assess what changes they need to make with their software security approaches in 2024.

[ Definitive timeline: Federal guidance on software supply chain security | Key takeaways: The State of Software Supply Chain Security 2024 ]

National Cybersecurity Strategy

March 2023 | Guidance

The National Cybersecurity Strategy (PDF) outlines the federal government’s continued efforts to improve the nation’s cybersecurity. The strategy comprises five pillars that address the federal government’s goals and is framed by two fundamental shifts: rebalancing the responsibility to defend cyberspace, and realigning incentives in favor of long-term investments.

Secure by Design

April 2023 | Guidance

Secure by Design, released by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) along with 17 other U.S. and international partners, is an initiative that aims to rebalance the burdens caused by cybersecurity risk from the end user to technology manufacturers and providers. The initiative asks software producers to take ownership at the executive level to ensure that their products are intentionally made with security in mind and that security is also enabled after the product is manufactured and released. One key aim of Secure by Design is to shift liability from the consumers of software to the producers.

Cybersecurity Information Sheet on Defending CI/CD Environments

June 2023 | Guidance

The Cybersecurity Information Sheet (CSI) on Defending Continuous Integration/Continuous Delivery (CI/CD) Environments (PDF), released by CISA and the National Security Agency, outlines recommendations and best practices for improving defenses in the software development, security, and operations (DevSecOps) process. It explains how to properly integrate security into CI/CD environments to ensure that security is not an afterthought for software products being developed. It also outlines what steps software publishers should take to continue actively hardening their software’s defenses post-build.

SEC Rules for Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure

July 2023 | Mandate

The SEC released a set of rules on “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure.” Since August 2023, SEC registrants have had to disclose material cybersecurity incidents and annually disclose “basic material information” about the company’s cybersecurity risk management, strategy, and governance practices. Information that needs to be disclosed could include updates on the state of software supply chain security at an organization or details regarding a software supply chain attack that a company has suffered from.

Cybersecurity in Medical Devices

September 2023 | Mandate

The FDA released “Cybersecurity in Medical Devices: Quality System Consideration and Content of Premarket Submissions” as a reference document for device manufacturers that must now report on their medical devices’ cybersecurity, in accordance with part (f) of Sec. 524B in H.R.2617, which includes the use of software bills of materials (SBOMs). In addition to providing an SBOM that includes the medical device’s use of commercial, open-source and off-the-shelf software components, manufacturers will also need to disclose how they deal with cybersecurity vulnerability management.

Software Identification Ecosystem Option Analysis

October 2023 | Guidance

CISA put forward new guidelines for a “Software Identification Ecosystem,” with the goal of it being both a precise and generic resource that supports software “grouping.” A successful software identifier scheme should also include properties such as software names and versions that are used in both SBOM creation and vulnerability management — two important use cases.

Recommended Practices for SBOM Consumption

November 2023 | Guidance

As part of its second phase of the “Securing the Software Supply Chain” guide, the Enduring Security Framework Software Supply Chain Working Panel (ESF) released “Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption” (PDF). The document serves as an SBOM-specific follow-up to the first three parts of the “Securing the Software Supply Chain” guide, which are aimed at software developers, suppliers, and customers. All of these stakeholders should use the guidance as a basis for describing, assessing, and measuring security practices relative to the software lifecycle, as well as the acquisition, deployment, and operational phases of the software supply chain, respective to their unique responsibilities.

Looking ahead

In 2024 and beyond, the federal government has indicated, it will continue to shape cybersecurity policy, including software supply chain security, in several ways.

The CISA Strategic Plan for 2024-2026, released in August 2023, outlines the government’s efforts regarding active threats, future threats and improving the security of the software ecosystem.

Among other things, CISA said that it aims to:

Increase the number of technology providers that have published detailed threat models that document both areas in need of increased security and potential threats/adversaries
Increase the number of technology providers that have implemented the NIST Secure Software Development Framework (SSDF) and the various security controls it entails
Increase the number of software producers that publish secure-by-design road maps for their product that lay out changes the producer is making to their software development processes, the measurement of software defect rates, as well as goals for improvement such as the transition to memory-safe programming languages
Increase the number of technology providers that regularly publish security-relevant statistics such as multifactor authentication (MFA) adoption, use of unsafe legacy protocols, and the prevalence of customers using unsupported product versions

These efforts aim to increase engagement by software producers are sure to be accompanied by additional guidelines and mandates from federal agencies or regulatory bodies.

Focus on AI

CISA has also indicated that it will focus on security risks related to the adoption of artificial intelligence (AI) in the coming years, with initiatives designed to help organizations safely use AI to advance cybersecurity while also protecting them from AI-driven threats, or efforts by adversaries to manipulate or abuse AI systems. As with secure software development, CISA’s work to secure AI will build on NIST’s AI Risk Management Framework.

The state of container security: 5 key steps to locking down your releases

jaikumar.vijayan@gmail.com (Jaikumar Vijayan) — Wed, 03 Jan 2024 20:15:00 GMT

Container technologies are rapidly transforming application development and deployment practices at many organizations. But they also present a minefield of security risks for the growing number of organizations using the technology to package and deploy modern, microservices-based applications.

Containers are highly portable because they include everything that an application needs to run, such as dependences and configuration files. So, for development teams, containers offer a way to build an application once and deploy it across on-premises, multicloud, and virtualized environments. Container orchestration software such as Docker Swarm or Kubernetes has made it relatively easy for development teams to centrally deploy and manage containerized apps.

In development environments, containers have made it easier for developers to automate the pipeline and more efficiently move applications from testing to production. Many organizations are taking advantage of container technologies to migrate internally developed applications to the cloud or to build cloud-native applications from scratch. Server consolidation and multicloud adoption have also contributed to container adoption.

Primary risks include those related to vulnerable container images, poor access controls, overly permissive privileges, exposed attack surfaces, and misconfigured runtimes. Over the last couple of years, the rise in software supply chain attacks has increased container security risks — and heightened the need for organizations to deploy controls for managing and mitigating those risks.

As containers have become fundamental to modern software development and deployment, it is vital to secure them, said Patrick Tiquet, vice president for security and architecture at Keeper Security.

"Securing containers involves implementing a combination of best practices, tools, and processes to protect containerized applications and their environments."
—Patrick Tiquet

Here are five essential best practices — and recommendations for modern application security tooling — to lock down your organization's containers and ensure secure software releases.

[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]

1. Add controls for containers accessing sensitive data

Users, applications, and devices should be allowed to communicate with and access only those resources that are required within their role. The best way to ensure that is to follow the principles of zero trust at the user, application, and network layers, said Anthony Tam, manager of security engineering at Tigera. In addition, ensure that all sensitive data is encrypted at rest and in transit, regardless of whether the destination is internal or external. Ensure that you use the latest industry-standard crypto algorithms, Tam said.

Kong Yew Chan, director of product management, container security at Qualys, said key encryption should be secured with external key management, so that only authorized individuals can retrieve the encryption key to encrypt or decrypt the sensitive data.

"Data encryption is a mandatory requirement for customer PII data to meet compliance requirements such as GDPR. Use network segmentation to limit only authorized containers to access sensitive data volumes, and use the principle of least privilege to limit the number of authorized users who have access to sensitive data."
—Kong Yew Chan

KC Berg, chief architect at the API security testing firm StackHawk, said administrators should treat all containers as if they contain personally identifiable information (PII). For containers that need extra security controls, implement a separate namespace with role-based access control (RBAC) and even more limited access.

Berg said to leverage the Init Containers feature in Kubernetes to unmount/unset configuration files and/or secrets once the primary process has loaded them.

"Run a sidecar or use a service such as a reverse proxy in front of the container's exposed network service port that monitors for PII data patterns and generates alerts if unexpected access is detected."
—KC Berg

2. Use runtime security to detect anomalous behaviors

Continuously monitor and analyze application behavior during runtime to identify and respond to threats in real time. Runtime tools can help reduce false positives by helping security teams detect attacks, risks, and anomalous behaviors that are specific to an organization's infrastructure, said Tam.

"They can also help security teams respond to incidents in real time through actions like blocking network traffic to the affected container, quarantining the container, or other methods of preventing the spread of an attack."
—Anthony Tam

Runtime security products also leverage automation for rapid investigation and response, and many can take containment actions such as killing processes or isolating workloads with a single click, Tam said.

Qualys' Chan said organizations should use technology based on extended Berkeley Packet Filter (eBPF) to monitor and protect containers during runtime. With eBPF-based technology, runtime behaviors, including file, process, and networking events, can be monitored and protected.

"For example, any unintended or unauthorized file access to specific system files such as 'etc/hosts' can be considered malicious. Users want to prevent malicious file access with container runtime so they can prevent potential threat risks and meet compliance requirements such as PCI-DSS."
—Kong Yew Chan

Create eBPF-based rules to protect against known threats. For example, treat any processes that are created from in-memory data as fileless malware. Alternatively, administrators can create whitelist rules that allow specific known behaviors while blocking unknown ones.

"This approach ensures that all other events besides the well-known behaviors will not trigger potential attacks."
—Kong Yew Chan

3. Mitigate dependency-related security risks

Maintaining visibility into dependencies for container environments can be challenging, but organizations can take certain measures to mitigate risk from open-source and other third-party code dependencies.

Chan said organizations should use minimal base images or distroless images to build their container images. "The minimal base images will have limited dependencies, reducing the number of potential vulnerabilities," Chan says.

"This approach will simplify base image dependency management and reduce the complexity of managing vulnerabilities of the base image."
—Kong Yew Chan

It's also a good idea to create a software bill of materials (SBOM) for container images. Open-source tools such as Dependency Tracker allow admins to maintain visibility into the software package dependencies within container images, Chan said.

In addition, use Kubernetes inventories to maintain visibility for container images in use. Running containers have specific images with specific dependencies. "Therefore, users can identify vulnerabilities within those running containers and prioritize fixes related to exploitable vulnerabilities with critical severity," Chan said.

StackHawk's Berg said other measures organizations can take to maintain visibility into dependencies in container environments include enabling container scanning in the Docker registry, running a container registry as a cache and then scanning third-party containers, scanning containers for vulnerable packages on every pull request, and using vulnerability-testing tools.

"Engineering teams should review vulnerabilities as part of a regular cadence. Once a good state has been reached, switch this to be pull request check-driven and treat vulnerable packages like any other software defect."
—KC Berg

4. Control supply chain risks in container ecosystems

Vulnerabilities in the software supply chain pose a major security risk in container environments. But there are several measures organizations can take to mitigate these risks, said Qualys' Chan. These include using base images only from trusted sources so images can be reproduced and verified and scanning images with tools such as software composition analysis to identify known vulnerabilities and potential license issues and such as binary analysis to identify malware. Chan said organizations should also scan images with for secrets, to prevent any from being leaked within the container images.

"Sign container images to ensure the authenticity of the image source. Signed container images will prevent tampering with the immutable images, preventing malicious packages from being injected into the image."
—Kong Yew Chan

It's also a good idea to deploy container runtime security tools such as binary analysis to detect configuration drifts and malicious threats in the runtime environments, Chan said.

"Deploy container runtime security tools to detect configuration drifts, malicious threats in the runtime environments. This approach can detect and prevent threats in the runtime environment, thereby maintaining software supply chain integrity."
—Kong Yew Chan

Chris Romeo, co-founder and CEO of the threat modeling firm Devici, said that, ultimately, containers are nothing more than a stack of operating system and application packages bundled together that are vulnerable to security issues just as in any software environment.

"The attacker's focus on the software supply chain is the cause of the bulk of threats against container security in recent years."
—Chris Romeo

5. Use controls to protect against lateral movement

Tam pointed to a recent survey that Tigera conducted of more than 1,200 users who are actively using Calico open-source networking and security tools in their container and Kubernetes environments. The survey found that 61% of Calico users were using workload access policies to limit pod-to-pod communication, 41% were using secure egress policies, and 24% were using microsegmentation to limit pod-to-pod communication.

"An overwhelming 85% of users said they needed to achieve network segmentation and protect east-west traffic. IT leaders need enhanced security controls at the workload level to reduce the risk of lateral movement of threats."
—Anthony Tam

Berg outlined four measures organizations can take to ensure isolation, prevent lateral movement, and detect anomalous behavior in container environments. First, ensure that containers run with the least privileges and that file and network access is secure. For instance, run the primary process as a non-root user with limited access to container assets and mount all configurations as read only.

Second, ensure that containers run one primary process as far as possible, and make sure a container's network access is limited to required resources.

"Use your cloud providers IAM and SDN capabilities in combination with Kubernetes' RBAC to run containers with least privilege access to assets like databases and other services. Use service mesh and networking tools like istio or traefik to control K8s service-to-service connections."
—KC Berg

Third, monitor containers via node/host services that can expose telemetry. Organizations need to understand that just because an application runs in a container does not necessarily mean it is automatically secure, said Keeper Security's Tiquet.

"The same discipline and best practices for scanning and managing vulnerabilities in on-prem and cloud server instances can and should be applied to containers."
—Patrick Tiquet

Rethinking container security requires the right tools

Build pipeline attacks are on the rise, and software supply chain security is front and center. With the potential for attackers to inject malware, tamper, or compromise signing, the focus for security teams needs to shift beyond vulnerabilities. To ensure container security, you need to know if someone has changed or introduced malware in your container images — just like your code.

Choosing the right tool to run within the container to monitor for compromise and evaluate the current security posture is critical. So too is education and awareness for developers about the inherent risks in using containers, orchestration, and images for application development and deployment, Romeo said.

Romeo recommended that development and security teams take the time to learn about tools that are currently available to help organizations secure container environments. They need to understand the capabilities of these tools and recognize the differences in the risks that container environments pose compared to typical app development and deployment pipelines.

"Answer the questions: Are we scanning our containers for vulnerabilities? Are we monitoring running containers for compromise? Scope the depth of the problem, understand it, and then implement solutions."
—Chris Romeo

Lisa Azevedo, CEO of container security firm Containn, said one big limitation with many current container security products and services is that they are reactive, designed to detect after-the-fact security vulnerabilities. Many container security products allow organizations to scan for and detect known security issues but do little to prevent them from happening in the first place. Most tools, at best, allow organizations to get a point-in-time assessment of security vulnerabilities in the container environment, she said.

Currently available container security tools generally are good at detecting existing vulnerabilities, providing a remediation report, and pushing the work of fixing the issues back to the development team. A growing number use machine learning to predict vulnerabilities in software under development. But they don’t give security teams an opportunity to stay ahead of the curve, because by the time organizations have a chance to remediate the detected issues, new ones likely have surfaced, Azevedo said.

The key is to ensure container security by pushing it further left during the build process, Azevedo said. Organizations should be thinking about how to implement container security at scale from the beginning and finding ways to maintain control of container deployments and state. The focus should be on shrinking the attack surface while maintaining control of deployments and container state.

Such capabilities are critical because many organizations are on the cusp of moving away from manual tools to intelligent tools for container development and deployment, Azevedo noted. The goal is to be able to spin up containers that are standardized for specific environments and integrate security and compliance features such as those required under various industry regulations and national data security and privacy mandates.

Matt Rose, field CISO at ReversingLabs, said new tools are needed to take on the rise of software supply chain attacks, and containers are an essential component. He said binary analysis, which was recently recommended by the Enduring Security Framework (ESF) working group, is key. Binary code analysis can help organizations evaluate and verify the security of both internally developed software and third-party commercial software before it is released into their environment, Rose said.

"It is the final examination of a package for software supply chain risk, which allows for trust in that piece of software that you are either developing for your customers or that you are buying to help operate your business."
—Matt Rose

Key reasons third-party risk management programs fail

jpmellojr@gmail.com (John P. Mello Jr.) — Tue, 02 Jan 2024 14:36:12 GMT

More than 80% of organizations in the last two years have experienced business interruptions caused by third parties, despite their investments in trying to tamp down risks created by their vendors and partners, a new report by the analyst firm Gartner says.

The report, based on a survey of 376 senior executives involved in third-party cybersecurity risk management (TPCRM), arrives at a time when security professionals are increasingly concerned about the dangers associated with third-party risk and are struggling to get a handle on it.

Zachary Smith, senior principal for research at Gartner, said in a statement that third-party risk management is often resource-intensive, overly process-oriented, and short on results.

“Cybersecurity teams struggle to build resilience against third party–related disruptions and to influence third party–related business decisions.”
—Zachary Smith

Matt Rose, field CISO for ReversingLabs, said organizations aren't getting the bang for the bucks they're putting into TPCRM. The proof? The triple-digit rise in software supply chain attacks, which have affected thousands of companies over the past few years.

"If organizations’ TPCRM programs were effective, then even if a third-party application or software package were compromised, it wouldn't cause much harm to the organization because the proper protections and resolution programs would be in place."
—Matt Rose

Demi Ben-Ari, CTO and co-founder of the TPCRM firm Panorays, said one key reason risk management programs disappoint may be how they're implemented.

"Most third-party risk management efforts predominantly focus on compliance and governance and ticking boxes, which may not be sufficient to fully protect organizations."
—Demi Ben-Ari

Here are the top reasons TPCRM programs fail — and key considerations for developing an effective risk management program.

[ Get related Gartner Report: Mitigate Enterprise Software Supply Chain Security Risks | Join Webinar: Learn key takeaways from the Gartner report ]

Checklists just don't cut it anymore

Charles Jones, software supply chain security evangelist at ReversingLabs, said traditional methods of assessing third-party risk, such as questionnaires, are slow and resource-intensive. Additionally, the assurance that can be derived from them is weak, because they are mainly based on self-attestation from the third party itself.

As a result, organizations often spend a significant level of effort chasing their third parties, with little to show for it in terms of the amount of risk reduction they are able to demonstrate.”
—Charles Jones

ReversingLabs' Rose added that the biggest challenge to managing third-party risk is that, in the end, third parties are not responsible for the security of the software and applications they produce, despite the Secure by Design initiative of the Cybersecurity and Infrastructure Security Agency.

“Someone else is responsible, and in a lot of cases you have to take their word for it and trust that the third party is doing the right things.”
—Matt Rose

Even if the information in the questionnaires is reliable, the manual processes of producing them and intervening during risk assessments can be overwhelming for organizations to manage as the volume of third parties increases.

"Today, large enterprises may rely on tens of thousands of third parties to operate their business. As a result, the ability to manage all of them using manual processes becomes unwieldy.”
—Charles Jones

Unwieldy processes bog organizations down

In addition, questionnaire-based TPCRM programs can be overly process-oriented, Rose said.

“Typically, questions come up, which leads to a lot of back and forth between many different stakeholders, which can result in a many-step process.”
—Matt Rose

James McQuiggan, a security awareness advocate at KnowBe4, said the need for consistency and accountability, especially for internal and external reporting, drives companies' emphasis on formalized procedures. Integrating risk management with other organizational processes, such as procurement and IT security, adds complexity. Even in a traditional security operations center (SOC), the evolving nature of best practices and standards in risk management demands a systematic approach. With the move to automation in the SOC, complexity grows.

“This is further compounded by the technological complexities of implementing automated risk assessment and monitoring tools, which require specific processes for effective deployment and interpretation. These combined factors contribute to the process-heavy nature of TPCRM, as organizations strive to manage risks consistently, efficiently, and with accountability.”
—James McQuiggan

Four key components of effective risk management

Gartner noted that successful TPCRM depends on a security organization’s ability to influence overall business decision making and to deliver on three outcomes: resource efficiency, risk management, and resilience. However, the report says that enterprises struggle to be effective in two out of those three outcomes and that only 6% of organizations are effective in all three.

Gartner recommends four actions that security and risk management leaders should take to increase the effectiveness of their TPCRM programs, adding that organizations that have implemented any of these actions saw a 40% to 50% increase in TPCRM effectiveness:

Regularly review how effectively third-party risks are communicated to the business owner of the third-party relationship. Chief information security officers (CISOs) need to regularly review how well the business understands their messaging around third-party risks to ensure they are providing actionable insights around those risks.
Track third-party contract decisions to help manage risk acceptance by business owners. Business owners will often choose to engage with a third party even if they are well-informed about associated cybersecurity risks. Tracking decisions helps security teams align compensating controls for risk acceptances and alerts security teams to particularly risky business owners that may require greater cybersecurity oversight.
Conduct third-party incident response planning, such as playbooks and tabletop exercises. Effective TPCRM goes beyond identifying and reporting cybersecurity risks. CISOs must ensure that the organization has strong contingency plans in place to prepare for unexpected scenarios and to be able to recover well in the wake of an incident.
Work with critical third parties to mature their security risk management practices as necessary. In a hyperconnected environment, a critical third party’s risk is also an organization’s risk. Partnering with critical third parties to improve their security risk management practices helps promote transparency and collaboration.

Avoid one-size-fits-all analysis

ReversingLabs' Jones said that, far too often, organizations make the mistake of building a one-size-fits-all all program to monitor third-party security risk.

“Although this may make it easy to compare the security posture of one-third party to another — an apples-to-apples comparison — it overlooks the uniqueness of the relationship, product, or service that is provided that contributes to its risk profile.”
—Charles Jones

Jones said one-size-fits-all programs could be detrimental to the comparison of the security maturity of two third parties that are inherently different because "it may negatively influence procurement decisions if the comparison is built off a correlation with no significance."

Gopi Ramamoorthy, senior director of security and of governance, risk, and compliance (GRC) at Symmetry Systems, said one way to avoid the one-size-fits-all trap is to implement a tiered system for assessing risk.

“The tier levels should depend on multiple metrics, including business dependency, impact, failure risk factors, recovery tests, technical support, and contractual obligations."
—Gopi Ramamoorthy

Once a matured tier-level system is implemented and each third party has been assigned to an appropriate tier, the organization should align the processes and use appropriate system tools to monitor them, Ramamoorthy said. “This will lead to better assessment and visibility of third-party risks and eventually will have improved results in TPCRM,” he added.

Visibility of risk is essential

Visibility is a top-of-mind concern among GRC, IT, and security pros, according to survey results recently released by Drata, a TPCRM company. In its Risk Trends Report, Drata found that 80% of businesses are concerned that they don’t have full visibility into the security posture of their third-party partners. Even among businesses that have the resources for thorough third-party screening, 47% acknowledged that they don’t have complete visibility into their third-party ecosystem.

AI to the rescue?

Organizations looking for a better return on their investment may find it as artificial intelligence begins to be integrated into third-party cybersecurity risk management solutions, said Piyush Pandey, CEO of Pathlock.

“AI can dramatically enhance the ROI in third-party risk management by automating risk assessments, enabling the rapid analysis of vast datasets to identify risks efficiently."
—Piyush Pandey

Organizations should look to solutions that provide continuous, real-time monitoring of third-party activities, providing immediate alerts, as well as dynamic access controls, to mitigate potential issues, Pandey said.

“AI should be harnessed to provide predictive analytics capabilities that allow organizations to mitigate potential risks proactively, rather than merely reacting to them, thus optimizing resource allocation and risk mitigation strategies.”
—Piyush Pandey

Panorays' Ben-Ari said AI-powered natural language processing (NLP) can help organizations quickly identify relevant terms related to security, compliance, and responsibilities during due diligence.

“By automating routine tasks, customizing risk scoring, and continuously learning from data, AI optimizes resource allocation, enhances incident response capabilities, and ultimately improves the long-term effectiveness of third-party risk management efforts. This advanced approach ensures that TPCRM efforts are not only compliant but also aligned with business objectives, delivering a more significant return on investment.”
—Demi Ben-Ari

Getting a handle on risk is essential to the business

As third parties become increasingly integral to business operations, reducing their risks grows ever more critical. Organizations still have work to do in improving visibility, planning mitigations, and collaborating with partners.

By complementing those efforts with AI, companies may finally gain an upper hand on third-party cybersecurity risk and maximize their ROI. The path forward lies in augmenting human intelligence with AI to create more resilient, cyber-aware partnerships.

Software supply chain security risks addressed in new Gartner® report

carolynn.vanarsdale@reversinglabs.com (Carolynn van Arsdale) — Mon, 01 Jan 2024 18:30:00 GMT

Concern about protecting software supply chains has grown significantly over the past few years. Costly software supply chain attacks, including SolarWinds, 3CX, and Log4Shell, garnered headlines internationally and focused the attention of governments and the private sector on software supply chain risk.

And for good reason. According to the research firm Gartner, almost two-thirds (61%) of all U.S. businesses were directly impacted by software supply chain attacks between April 2022 and April 2023. In the United States, software supply chain security takes center stage in federal efforts to strengthen cybersecurity. Since issuing its initial Executive Order 14028 in May, 2021, the Biden administration followed up with policy directives and guidance — many focused on improving software supply chain transparency and security.

More recently, Gartner released the report “Mitigate Enterprise Software Supply Chain Security Risks” in October, which provides guidance to private-sector companies on how to manage their software supply chain risk. Based on the findings of research conducted by the firm, Gartner makes recommendations for both software publishers and for those who manage vendor application security, so that their organizations can stay ahead of software supply chain risks.

Here are three key takeaways from Gartner’s report.

[ Get Gartner report: Mitigate Enterprise Software Supply Chain Security Risks | Join the related Webinar: Discuss Key Takeaways from the Gartner report ]

Supply chain security is a third-party risk priority

Most organizations today are using third parties to fulfill their IT needs – and that includes companies that are in the business of making software. Digital transformation and the embrace of cloud computing and SaaS (software as a service) make third-party risk management (TPRM) critical to maintaining operational integrity across industries. But what counts as TPRM is changing.

“TPRM vendors … do not provide adequate information to form a complete opinion of the risk that a vendor might pose. A superior approach to managing risk is to directly request and evaluate attestations — or other evidence — of appropriate secure software development practices."
–Gartner

For organizations to have robust TPRM that accounts for software supply chain security, Gartner recommends that they request and evaluate attestations of secure software development practices from any third-party vendor. Vendors that cannot — or will not — provide this attestation should be approached with caution and even disqualified from consideration.

Frameworks such as the National Institute of Standards and Technology’s secure software development framework (SSDF) provide guidance on how organizations should prioritize software supply chain security. That includes protecting software from malicious actions, developing software securely, and responding to vulnerabilities.

Transparency is a must-have

Modern software products consist of proprietary, commercial, and open-source code. Risks to software supply chain security, such as the exploitation of software vulnerabilities or tampering with an organization’s build and release processes, can exist in any type of application, no matter the mix of first-, second-, or third-party code.

That complex mixture prompted calls from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) for greater supply chain transparency, so that development organizations can identify risks in the software they are creating, ranging from software vulnerabilities to legal risks to technical debt. The best way to provide this transparency is with a high-quality software bill of materials (SBOM), which serves as a comprehensive ingredients list for software components.

“The inability or unwillingness of a vendor to provide an SBOM should be viewed as a significant risk and potentially disqualifying.”
—Gartner

Consider new tooling to detect malware in code

As incidents such as SolarWinds and 3CX show us, both software producers and consumers need to be able to identify malware and malicious code hiding within software products.

Malicious code can make its way into software in several ways. Developers may fall prey to typosquatting attacks and will accidentally employ a malicious package from an open-source repository as a part of their non-malicious application. In more extreme cases, sophisticated malicious actors infiltrate developer accounts and development organizations, using that access to compromise development and build pipelines in order to tamper with internal code to add malicious features. That tampered code is then compiled, signed, and pushed to customers as sanctioned software updates.

“It is increasingly common for software (both open source and commercial) to be exploited by attackers as an attack vector.”
—Gartner

Existing application security testing and code analysis tools such as vulnerability scanning, static analysis, and software composition analysis are necessary but insufficient to handle software dependency risks or compromises of development and build pipelines. Gartner’s report highlights this: “Traditional application security testing tools do not typically attempt to detect malicious code.”

In addition to pinpointing this gap in traditional AppSec tooling, the Gartner report states, “There are a limited number of vendors who can support automated analysis of code to detect malware.”

Gartner mentions ReversingLabs as one of those vendors. We agree that in order to detect these kinds of threats, organizations need automated analysis tools that address first-, second-, and third-party code to identify malware and other signs of tampering in source code or compiled binaries.

Enterprises need to stay ahead of threat actors

Gartner’s recommendations listed in its “Mitigate Enterprise Software Supply Chain Security Risks” report are reflective of the growing need to secure software supply chains from modern-day attacks. As recent incidents show, both cybercriminal and nation-state threat actors are becoming more skilled in how they carry out software supply chain attacks. As such attacks proliferate, it raises the bar on the federal government, open-source communities, and enterprises to increase their scrutiny of supply chain risks and take action to prioritize software supply chain security protections.

Read the complete Gartner® report, “Mitigate Enterprise Software Supply Chain Security Risks”.

Gartner, Mitigate Enterprise Software Supply Chain Security Risks By Dale Gardner, 31 October 2023

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation.

Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, express or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

The JetBrains TeamCity software supply chain attack: Lessons learned

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 21 Dec 2023 16:13:12 GMT

The group that perpetrated the notorious SunBurst attack on SolarWinds in 2020 is actively exploiting a vulnerability in JetBrains TeamCity's continuous integration/continuous delivery (CI/CD) software, which is used by development teams to manage and automate compilation, building, testing, and releasing software.

The Cybersecurity and Infrastructure Security Agency (CISA) warned in an alert released on Dec. 13:

"If compromised, access to a TeamCity server would provide malicious actors with access to that software developer’s source code, signing certificates, and the ability to subvert software compilation and deployment processes — access a malicious actor could further use to conduct supply chain operations."

A patch for the vulnerability — CVE-2023-42793 — has been available since September, but as of December, only 2% of TeamCity instances have installed it. It's estimated that more than 30,000 JetBrains customers use TeamCity servers, of which more than 3,000 on-premises servers were exposed to the Internet when the vulnerability was discovered.

Some have said the incident has echoes of the SunBurst attack, which involved Russian Foreign Intelligence Service (SVR) cyber-actors using stealthy access to SolarWinds to compromise the company and its customers. That doesn't seem to be the case with the TeamCity compromise, CISA noted.

Here are the key lessons for your development and application security (AppSec) teams.

[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]

The same old tools are used for old tricks

The backdoor installed by the Kremlin crew is called GraphicalProton. Andrew Barratt, managing principal for solutions and investigations at Coalfire, said it's a piece of malware with a fairly interesting command-and-control method, using typically known and trusted services such as OneDrive.

“It can establish outbound exfiltration channels that are then polled by the threat actor to retrieve data, or for them to send instructions. As they're using known, good services, they typically get through even a well-configured firewall.”
—Andrew Barratt

Balasz Greksza, threat response lead at Ontinue, said that in some of the TeamCity breaches, a vulnerability was exploited in Zabbix, a popular open-source tool for monitoring the status and performance of various IT components and networks, much like SolarWinds’ Orion software.

“The vulnerability in Zabbix allowed GraphicalProton to be distributed via DLL hijacking of a legitimate Zabbix DLL. The malware distribution method is similar to the SolarWinds style of attack.”
—Balasz Greksza

Roger Grimes, a defense evangelist with KnowBe4, said another trademark tool of the SVR is being used in the JetBrains TeamCity attacks: Mimikatz, a free tool created over a decade ago by a single person to demonstrate how easy it is to enumerate Windows passwords and Windows password hashes if the hacker can get on a Windows computer with elevated privileges.

“During the heady ‘pass-the-hash’ days, when those attacks were what people were worrying about instead of ransomware, Mimikatz became the go-to hacking tool for any hacker hacking Windows computers and networks. It is still very popular, often being integrated into other popular hacking tools.”
—Roger Grimes

Microsoft has many defenses that significantly diminish what Mimikatz can do on a Windows computer or network, but those defenses can cause operational issues in some environments and for that reason aren't enabled by default, Grimes said.

“And unfortunately, when you don't make a security setting a default, most users won't do it.”
—Roger Grimes

Lessons learned in the new era of supply chain security

The JetBrains TeamCity attacks can teach security teams some important lessons, said Ashlee Benge, director of threat intelligence at ReversingLabs. She said it's time for a new generation of tools that can go beyond legacy application security testing, as recommended by the Enduring Security Framework (ESF) working group most recently in its newest supply chain security guidance.

“For both developers and consumers of software, it's extremely important to thoroughly scan the final compiled binary prior to deployment. If a developer's build system has been compromised, scanning source code prior to build is not enough. There are many AppSec tools out there, but very few that analyze compiled binaries."
—Ashlee Benge

Benge said complex binary analysis, a new security tool category referred to broadly as software supply chain security, is one that both developers and consumers should be looking into.

Barratt said that AppSec practices must be built into your team's day-to-day security operations.

“Automate the routine security validation with SAST and DAST products and make the most of your offensive security partner to look for weaknesses in your applications that could be exploited for monetary gain. An attacker might not always target your data, but they almost certainly will target the applications you've given access to that data."
—Andrew Barratt

Best practices on patching should be followed

The JetBrains TeamCity incident also attests to the value of timely patching. “The TeamCity software vulnerability should have been patched very quickly, to prevent an entry point for intrusion,” Greksza noted. Subsequently, organizations that experienced a breach should have followed up with a rapid and full-scope investigation to prevent a large-scale compromise, he said.

“Exposing key resources to the public Internet such as TeamCity servers without additional segregations or limitations in place increases the attack surface and likelihood of a successful compromise.”
—Balasz Greksza

Developers are also in the hot seat

Developers can never be too careful about validating their code, Grimes said. Hackers have long broken into coding development environments and inserted malicious code or instructions. "It happens all the time,” he said.

“All development environments must mitigate this risk by having secure coding repositories, super secure coding workstations, code signing, and frequent code review to make sure nothing untoward has been inserted in the code.”
—Roger Grimes

Take action on software supply chain security now

CISA's advisory noted that the attacks have so far been limited in number, with access used to escalate privileges, move laterally, deploy backdoors, and take other steps to ensure persistent and long-term access to the compromised network environments. "The authoring agencies are not currently aware of any other initial access vector to JetBrains TeamCity currently being exploited by the SVR," CISA noted.

But that should not lead to complacency, ReversingLabs' Benge stressed.

“TeamCity is not the first CI/CD tool that's been breached. We've seen this with the CircleCI breach and a similar compromise of 3CX, both earlier this year. And it won't be the last.”
—Ashlee Benge

ESF steps up supply chain security guidance with call for binary analysis

jaikumar.vijayan@gmail.com (Jaikumar Vijayan) — Wed, 20 Dec 2023 16:12:00 GMT

One of the more significant aspects of a new document on software supply chain security from the Enduring Security Framework (ESF) is the recommendation of binary analysis and reproducible builds as best practices.

The document, titled "Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bill of Materials," builds on previous efforts by the U.S. federal government to foster formal standards for bolstering software security against current and emergent threats, including the most recent push for Secure by Design, which seeks to shift liability for software compromises to software teams.

Developed by the ESF, a public-private working group led by the National Security Agency and the Cybersecurity and Infrastructure Security Agency, the new guidelines focus heavily on practices for ensuring the security of open-source components in enterprise software. But within the document, the ESF goes a step further, calling for application security tools that go beyond legacy testing by using complex binary analysis, as well as employing reproducible builds.

Here's what software producers and consumers need to know about the recommendations in the new guidelines.

[ See ReversingGlass: Why binary analysis matters | Learn more: The Power of Complex Binary Analysis ]

A significant call to action on supply chain security

The ESF document recommends that developers and third-party software suppliers perform binary analysis as a final package verification step:

"Before shipping the software package to customers, the developer or supplier should perform binary composition analysis to verify the contents of the package and reproducible build validation when possible."

Such binary analysis tools can determine what is included in the final deliverables "and identify potential issues in the final packages, [including] a range of activities from the detection of potential vulnerabilities and threats to including Software of Unknown Provenance (SOUP) and secrets inadvertently included in the final packages."

Significantly, the ESF document recommended that binary code analysis practices be applied not just to software vendors, but also to the phases of software acquisition, deployment, and operations.

In addition, the ESF recommends that software developers use reproducible builds, when possible, to ensure that code in a package has not been tampered with or modified.

To mitigate risk, go beyond legacy AppSec

Security experts consider both binary analysis and reproducible builds crucial components of supply chain security. The goal with binary code analysis is to inspect the binaries in a finished software package for potential security issues to validate configuration and code provenance and look for hidden functionality and undocumented features such as backdoors.

Binary analysis enables visibility into code that runs in production and can be especially useful when an organization does not have access to a particular software package's source code, as is almost aways the case when purchasing commercial products.

Meanwhile, a reproducible build is an additional step to ensure the software that an organization develops or acquires from a developer or commercial supplier behaves the same when run in parallel, which can expose things such as tampering or malware that has entered the package through the software supply chain.

Binary analysis bolsters SBOMs

John Gallagher, vice president at enterprise security platform Viako, said the inclusion of these practices is a significant step forward in software supply chain security. Binary analysis and reproducible builds can enable more trust in using software bills of materials (SBOMs), he said.

Binary analysis adds to current source code analysis methods by providing detailed information on dependencies and security risks, both of which are critically important.

"Generating an SBOM based on binary code analysis can catch transitive dependencies that can lead to security and privacy issues compared to generating an SBOM through source code analysis. The implicit 'trust' for an SBOM is the ability to use it for catching vulnerabilities, and a combination of source code analysis and binary code analysis will provide a more 'trusted' SBOM."
—John Gallagher

Recommending binary analysis will also likely advance the use of the Vulnerability Exploitability eXchange (VEX) for managing and tracking application and firmware vulnerabilities, Gallagher said. VEX is an intermediate representation of binary code that is architecture-agnostic, and when used with platforms such as angr, can make program analysis easier, he said. "In other words, VEX offers a level of abstraction for easier binary analysis."

Enter the new era of software supply chain security

Matt Rose, field CISO at ReversingLabs, said the inclusion of binary code analysis as a recommended best practice reflects a broader and ongoing formalization of the definition of software supply chain security that's been happening over the last couple of years.

Following the Biden administration's May 2021 Executive Order on Improving the Nation’s Cybersecurity, which specifically called out the need to enhance security of software supply chains, there has been an evolving understanding of what exactly that entails, Rose said.

Increasingly, there is recognition of the need for organizations to have mechanisms to assess the security of commercial third-party software they consume that go beyond SBOMs, which are little more than a list of ingredients in software. SBOMs don't give organizations visibility into the security posture of the package itself, Rose said.

Binary code analysis can help organizations evaluate and verify the security of not just internally developed software, but also third-party commercial software in their environment, before it is released.

"It is the final examination of a package for software supply chain risk, which allows for trust in that piece of software that you are either developing for your customers or that you are buying to help operate your business."
—Matt Rose

Saša Zdjelar, Chief Trust Officer at ReversingLabs, said the recommended use of binary analysis and reproducible builds marked a significant step forward in ensuring better software supply chain security. AppSec practices such as SAST and DAST typically only apply to a small subset of internally developed systems and applications at many organizations, he said.

Legacy application security testing is out of sync with modern software development because it does not cover software developed by commercial providers and other third parties.

"Our ability to analyze binaries is key to understanding risk in third party software."
—Saša Zdjelar

Modern supply chain security needs accountability

A lot of the success of software supply chain security programs depends on where the accountability for implementing the recommended practices rests, Zdjelar said.

Putting the onus on software suppliers alone to do such testing, for example, is unlikely to bolster trust, Zdjelar said. The ESF document recommends that the developer or supplier should perform binary analysis before releasing the package. But it's unclear how much confidence consumers will have in the results of vendor-performed analysis.

Until the software industry gets to that space, binary analysis needs to be part of the software acquisition process as well. And companies seeking to manage software risk need tools that can verify all software being developed or run across their organizations.

"When you buy your car, do you feel the need to do your own crash testing, or do you believe the crashworthiness, the seatbelts, and airbags and crumple zones all work as intended? Generally, we all believe they work as intended because the automobile industry has over time earned our trust in that space."
—Saša Zdjelar

Malware leveraging public infrastructure like GitHub on the rise

karlo.zanki@reversinglabs.com (Karlo Zanki) — Tue, 19 Dec 2023 12:30:00 GMT

The use of public services as command-and-control (C2) infrastructure isn’t a revolutionary technique for malicious actors. ReversingLabs has observed such behavior in several malware campaigns throughout the last few years.

Malware authors occasionally place their samples in services like Dropbox, Google Drive, OneDrive and Discord to host second stage malware and sidestep detection tools. However, the ReversingLabs threat research team has recently observed the increasing use of the GitHub open source development platform for hosting malware.

Here are two novel techniques deployed on GitHub that were discovered by ReversingLabs. The first abuses GitHub Gists, and the second issues commands through git commit messages.

Public services as C2 infrastructure

In one of our previous research team posts, we described a malicious npm package masquerading as the Material Tailwind CSS tool. The malware used Google Drive, Microsoft OneDrive and GitHub to fetch the address of the real C2 server. This is historically the most common use case of public services being used for malicious purposes: fetching of the real C2 address.

However, several families of infostealers published to open source package repositories have also been seen using Dropbox and Discord services to host two stage malware instead of just the location of the real C2 server. Versions of W4SP and similar token stealers, which are typically used as the second stage for downloader PyPI packages, were hosted on GitHub and (more commonly) as Discord attachments. The same approach has been observed in the fake Roblox NPM packages we observed delivering the LunaGrabber malware. With the recent IAmReboot campaign the ReversingLabs threat research team documented, the distributed malicious NuGet downloaders also hosts a second stage, obfuscating a version of the SeroXen RAT on a GitHub repository.

There are several reasons why malware authors decide to use public services as C2 infrastructure. The first is that network communication of the infected host with such services is less likely to raise suspicion than communication to an obscure domain or IP address. This is especially true, because developers are becoming a primary target for software supply chain attacks. In a perfect world, there’s nothing suspicious about a developer’s computer communicating with a GitHub repository. However, in light of these attacks, organizations can’t assume that such traffic is benign.

Also, standing up and running C2 infrastructure on platforms like GitHub is simpler than cybercriminals operating their own server. By using public services, the attacker needs only to create an account to access the service, and then publish the desired content to their repository. It falls to the service itself to manage communications and ensure uptime and so on. This eliminates the time and money malware authors need to spend on the maintenance of their attack infrastructure.

Malware (ab)using GitHub Gists

Two interesting malware types using GitHub features have recently been detected during our threat research activities, which the team performs using the ReversingLabs Software Supply Chain Security platform. The first one used GitHub Gists for hosting two-stage malicious payloads.

Gists are a GitHub feature that provides a simple way to share code snippets with other developers, and can be public or secret. As described in Gists documentation: “Secret gists don't show up in Discover and are not searchable unless you are logged in and are the author of the secret gist. Secret gists aren't private. If you send the URL of a secret gist to a friend, they'll be able to see it.” Another nice characteristic of secret Gists is that they don’t end up being visible in the GitHub profile page of the author. From an attacker's perspective, this makes them usable as a kind of a pastebin service which doesn’t raise much suspicion.

In this incident, several PyPI packages presented themselves as libraries for handling network proxying, and contained a Base64 encoded string, allegedly related to telemetry data, but actually containing a URL, pointing to a secret Gist. Malware authors used Base64 encoding to obfuscate the true purpose of this string and make it harder for security tools to detect it as suspicious. Base64 encoding is often used to encode some binary data before it gets transferred over the network. Nevertheless, an experienced eye will quickly recognize that the first few characters of this concrete string get decoded to “http” — almost surely the beginning of an URL, and therefore a red flag for a threat analyst.

Figure 1: Fetching and executing commands from a Base64 encoded URL

The malicious code was hidden in the setup.py file. It was implemented by extending setuptools commands, specifically the egg_info command. The code inside PostEggInfoCommand visible in Figure 1 decodes a Base64 encoded URL from which it also fetches Base64 encoded Python commands that are executed in a new process.

Figure 2: Extending setuptools commands in setup.py

The interesting part about this malware sample is the decoded URL, which points to a secret Gist belonging to the user yeremyvalidslov2342 — a throwaway account without any public projects, created the same day as the malicious PyPI package. Using Gists for delivery of malicious commands to infected machines isn’t a frequently seen technique. Google search on this topic doesn’t give many results. Our threat research team was able to find only one mention of such a technique being actively used by malware, in a Trend Micro report on SLUB Backdoor from March 2019.

Figure 3: Secret Gist containing Base64 encoded commands

Malware fetching commands from git commit messages

The second interesting malware type the ReversingLabs threat research team discovered is a sample that abuses version control system features and was detected in the easyhttprequest PyPI package. The malicious code was once again hidden in the setup.py file and implemented by extending the same egg_info setuptools command.

This malicious package is using an original technique for command delivery. After installation on the victim's machine, the malicious code from this package clones a specific git repository from GitHub and checks if the “head” commit of this repository contains a commit message that starts with a specific string. If it does, it strips that magic string and decodes the rest of the Base64 encoded commit message, executing it as a Python command in a new process.

However, the code in this form isn’t executing malicious functionality since the name of the variable used for condition validation doesn’t match the name of the variable containing Base64 encoded commit message. It is unclear if the malware author did this on purpose or by mistake. The referenced GitHub repository that is cloned is a fork of a legitimate looking PySocks project. At time of publication of this research, it didn’t yet contain the commit with a malicious commit message.

Figure 4: Fetching and executing commands from a Base64 encoded commit message

Conclusion

Using GitHub as C2 infrastructure isn't new on its own, but abuse of features like Git Gists and commit messages for command delivery are novel approaches used by malicious actors. We have not previously observed malware using such methods of command delivery, nor are we aware of third-party reports documenting such activity. Also, based on an identical execution technique, similar abuse of uncommon GitHub features, and the impersonation of similar networking utilities — ReversingLabs researchers believe that the same malware author is likely behind both of these campaigns.

Despite these malicious packages being taken down from PyPI, the threat research team expects that more GitHub tricks like these will be seen soon. This is because the malware author behind these incidents is still publishing new malware samples, despite the previous version of malware getting removed from PyPI shortly after.

Our discoveries of these novel attack methods serve as yet another reminder hat developers must remain wary of the threats that lie within the open source ecosystem. As attackers are becoming more skilled in their deployment of malware, it is essential that developers and application security teams are able to differentiate between malicious and legitimate packages on these platforms. This is why software producers should utilize modern tooling that employs complex binary analysis, which provides comprehensive software software supply chain security.

Indicators of Compromise (IOCs)

PyPI packages:

package_name	version	SHA1
httprequesthub	2.31.0	fa64041676f22ac3ea55170c6594b5142d3e45ac
httprequesthub	2.31.1	abd752e9603f9714f4e8b6860ad148d4003151a2
httprequesthub	2.31.3	b8e878bb3a47c6ca66e5f962a3e7f92f0a47324f
httprequesthub	2.31.4	b39f20452100f2fc3dc27088876ef4c07ede5f36
pyhttpproxifier	0.9.2	eb18768cbe6b74394c46162008a289e0b5e191f0
pyhttpproxifier	0.9.3	04f0ffd63368d84ec320cfae5b059eb7431b758f
easyhttprequest	2.31.4	8b5de82c0a51bd0e5be225a1ae968c8fad2467bb
easyhttprequest	2.31.5	0058dffe115f5d631a5f0a93a69ef88dc29d2c2d
libsock	1.1.3	fd727a37938e9d94d3bc6159bee398a915e74465
libproxy	1.1.4	38e431bfc8496e80e59077efa4a5889763a812fc
libproxy	1.1.5	c1fe2550edd3815f7a72a98dabd4a450419e0592
libsocks5	1.1.1	fa761695087db89316cac5accf6eae332bda4803
libsocks5	1.7.0	e9a42bdeb8da3a460dde3b2c162ed1fd65d07bb0
libsocks5	1.7.1	687abd0a47c26c112309bb16238c7cf8238239d9
libsocks5	1.7.3	b5e0e89d7d675b6804bdb3a86e1c4609be5d7689
libsocks5	1.7.4	7f27520be02c490b7b12ad4001bd63fb98245c63

The Hugging Face API token breach: 5 lessons learned

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 14 Dec 2023 16:00:46 GMT

Researchers from Lasso Security rattled the AI development world early in December when they discovered that more than 1,500 Hugging Face API tokens were exposed, leaving millions of users vulnerable.

Hugging Face is the GitHub for AI developers. Its open-source library hosts more than 500,000 AI models and 250,000 datasets, including pre-trained models from Meta-Llama, Bloom, and Pythia.

One of the most used features of the website is its API, which allows developers and organizations to integrate models and read, create, modify, and delete repositories or files within them. A compromise of its API could be catastrophic.

Bar Lanyado, a security researcher at Lasso Security, said in his team's analysis of the compromise that the Hugging Face API tokens are significant for organizations and that exploiting them could lead to major negative outcomes, including data breaches and the spread of malicious models that "could affect millions of users who rely on these foundational models for their applications."

"The gravity of the situation cannot be overstated. With control over an organization boasting millions of downloads, we now possess the capability to manipulate existing models, potentially turning them into malicious entities."
—Bar Lanyado

After the disclosure, the repository and its affected users rushed to mitigate the problem, narrowly evading a debacle. Here are five lessons learned from the breach — and some best practices for reality-checking API security in your development environment.

[ Learn more: Secure AI development guidance: What software teams need to know | MFA and software supply chain security: It's no magic bullet ]

1. Don't store login information in public repositories

Roger Grimes, a defense evangelist for KnowBe4, said shared logins are a huge ongoing problem. "After years of telling developers not to store logon information on public repositories, they continue to do so in large numbers," he said.

Grimes said the big takeaway was that technical defenses are now a requirement.

"Studies have shown that when logon information is stored in deposited code, it's only minutes before potential adversaries start to take advantage of it. While I'm a huge believer in the power of education to combat most cybersecurity problems, this is one that needs more technical defenses."
—Roger Grimes

Public repositories, in an attempt to mitigate the problem, should do proactive scanning when a developer uploads code and block the storing of logon information within stored code — or at least warn the developer of the severe consequences, he said.

With the severity of a potential breach, repositories such as GitHub have been rushing to two-factor and multifactor authentication (2FA and MFA) to protect accounts. However, 2FA and MFA are not panaceas, experts warn.

2. Use multiple API keys — and rotate them

Nick Rago, a field CTO with the API security firm Salt Security, said that it's good security practice to use not just one API key with third-party providers, but many, each focused on certain integration services to minimize impact of an exposed token. It is also a best practice to frequently rotate keys.

If a third-party provider only allows public API access with static tokens, it's good to use an API gateway as an intermediary between a developer and the third-party API, Rago said.

"That way, the organizations can enforce more robust API posture and authentication methods in their code, such as OAuth or MTLS."
—Nick Rago

3. Be aware of third-party API usage

Rago explained that API security is not just about securing APIs that are internally developed; ensuring safe consumption and usage of leveraged third-party APIs is also critical.

"Key business process today consists of API supply chain calls that consist of consumption of both internal and third-party APIs. Therefore, it is important that organizations have a good understanding of what third-party APIs are in use, their function, and the data associated with them to assess risk."
—Nick Rago

Education is also important, because developers need to understand the ramifications of mishandling privileged API keys. And technologies should be in place to ensure that secrets such as static API tokens don't find their way into code and then into exposed repositories, Rago said.

4. Your AI tools need to take data handling seriously

Teresa Rothaar, a governance, risk, and compliance analyst at Keeper Security, said AI development demands the highest security protocols given the amount of sensitive data AI models need to be fed for training to generate accurate and appropriate results. That means AI data sets alone are valuable.

"In addition to the danger of data poisoning — a scenario where threat actors feed AI models inaccurate or inappropriate data — threat actors may seek to steal fully trained AI models that organizations have invested thousands of work hours and millions of dollars into. Why invest your own money and time into building an AI model if you can steal another organization’s work?"
—Teresa Rothaar

5. AI providers need to foster trust in APIs and beyond

Karl Mattson, CISO of API security firm Noname Security, said that as large language models grow in use, they will become embedded into applications using APIs. Organizations are already using generative AI from a variety of vendors and various channels. This utilization is taking different forms, including integrating generative AI into in-house application development, incorporating it into third-party applications, or accessing it directly via API from providers such as OpenAI or Google's Bard, Mattson said.

"As API attacks continue to increase on AI, organizations integrating with generative AI technologies may face the same risks and consequences. The AI industry will need to work to maintain trust by building secure API implementations and protecting third-party transactions with good security hygiene.”
—Karl Mattson

Best practices for securing your APIs

Tushar Kulkarni, a graduate student at Indiana University who was part of a recent an RSA Conference webcast on API security, shared six measures organizations can take to secure their API implementations.

Don't use GUIDs/UUIDs that can be guessed by a threat actor in an intuitive way. GUIDs (globally unique identifiers) and UUIDs (universally unique identifiers) are used as identifiers for various resources or objects in APIs. During the web session, Kulkarni demonstrated how weak identifiers can be used to compromise an API.
Never rely on a client to filter sensitive data. It's always a good practice to allow a client to fetch only the data that is needed and nothing more.
Enforce a limit on how often a client can call the API endpoint. Without limits, a threat actor can carry out attacks, such as credential stuffing.
Lock down endpoints. Make sure all administrative endpoints validate a user's role and privileges before performing an action.
Avoid functions binding client-side data into code variables and later into objects in databases. Binding client-side data directly into code variables can expose the API to injection attacks, such as SQL injection or NoSQL injection. It can also expose the API to unintentional code injection vulnerabilities.
Enforce a strong CORS policy with custom, unguessable authorization headers. Enforcing a strong CORS policy ensures that only trusted domains are allowed to make requests to the API. That helps mitigate the risk of cross-site request forgery and other cross-origin attacks. "Enforcing a strong CORS policy is very important," Kulkarni said.

Developers should treat all API inputs as dangerous, Kulkarni said.

"You should never assume end users won't fool around with the API on their own. You should always assume that every end user is an attacker."
—Tushar Kulkarni

Secure AI development guidance: What software teams need to know

jpmellojr@gmail.com (John P. Mello Jr.) — Wed, 13 Dec 2023 12:30:00 GMT

The use of generative AI systems has been spreading like wildfire, and if systems are not developed securely, the blaze could end up burning your organization. To help organizations tackle the problem, the United Kingdom's National Cyber Security Centre (NCSC) and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) recently released "Guidelines for Secure AI System Development." In it, they note:

"AI systems have the potential to bring many benefits to society. However, for the opportunities of AI to be fully realized, it must be developed, deployed, and operated in a secure and responsible way."

The agencies' guidelines are significant not only because they represent an effort to get ahead of security problems with AI, but also because they've garnered the support of cyber-watchdogs from 16 other nations, including France, Germany, Italy, Japan, Australia, and New Zealand. The guidelines also represent input from 19 AI-centered organizations, including Amazon, Anthropic, Google, IBM, Microsoft, OpenAI, and RAND.

Michael Leach, legal compliance manager at Forcepoint, said the guidelines take aim at addressing the primary concern at the heart of AI adoption and use: security. And the timing was critical, with teams now recognizing that security is paramount in all phases of the software development lifecycle (SDLC) to ensure that AI is used effectively and safely.

"Responsible government cooperation on the secure development, deployment, and operation of AI between countries like the U.S. and U.K. is what I believe most of us have been waiting for before we adopt and readily use current and future AI capabilities as a pioneering technology to move society forward in the right direction."
—Michael Leach

With AI now infiltrating almost every organization, it's time to get a handle on AI system security. Here's what your software team needs to know about the new NCSA and CISA guidance.

[ Learn more: How legacy AppSec is holding back Secure by Design | See Webinar: Secure by Design: Why Trust Matters for Risk Management ]

Secure by Design is the first step

Hitesh Sheth, president and CEO of security firm Vectra AI, said the new guidelines represent a genuine effort to deliver a much-needed global standard on secure AI design, and the CISA's Secure by Design is a critical building block.

“With AI evolving at an unprecedented rate and businesses increasingly keen to adopt it, it’s vital that developers fully consider the importance of cybersecurity when creating AI systems at the earliest opportunity. Therefore, this Secure by Design approach should be welcomed."
—Hitesh Sheth

The Secure by Design guidelines should be used in conjunction with established cybersecurity, risk management, and incident response best practices. Those principles prioritize:

Taking ownership of security outcomes for customers
Embracing radical transparency and accountability
Building organizational structure and leadership so that Secure by Design is a top business priority

The new AI guidelines acknowledge that following Secure by Design principles requires significant resources throughout a development system’s lifecycle, investment in prioritizing features and mechanisms, and the implementation of tools that protect customers at each layer of the system design and across all stages of the SDLC.

But by following the new AI guidelines and Secure by Design, organizations can prevent costly redesigns later — and safeguard customers and their data in the process.

The importance of transparency

Sheth said that cooperation will empower developers across the globe to make more informed cybersecurity decisions about AI. “It’s encouraging to see the U.K. and U.S. work hand in hand, and with agencies from 16 other countries confirming they will endorse and co-seal the guidelines,” he said.

“Transparency is vital when it comes to AI development, so these guidelines should act as a springboard for the delivery of reliable and secure innovation that can transform how we live and work.”
—Hitesh Sheth

A key contributor to the transparency will be documentation. The production of comprehensive documentation supports transparency and accountability, the AI guidelines noted.

The guidelines urge AI system developers to document the creation, operation, and lifecycle management of any models, datasets, and meta or system prompts. That documentation should include security-relevant information such as the sources of training data (including fine-tuning data and human or other operational feedback), intended scope and limitations, guardrails, cryptographic hashes or signatures, retention time, suggested review frequency, and potential failure modes.

To facilitate the documentation, the guidance suggest model cards, data cards, meta or system prompts, and software bills of materials (SBOMs).

Four pillars of AI system security

The guidelines, which are closely aligned with the software lifecycle practices defined by the NTSC and CISA, are organized around four key areas:

Secure by Design: This encompasses raising staff awareness of AI security threats and mitigations, designing systems for security and functionality, assessing risks to the system through threat modeling, and considering security trade-offs when selecting AI models.
Secure development: This entails tracking assets and securing the supply chain; documenting data, models, and prompts; and managing technical debt throughout the system lifecycle.
Secure deployment: This includes securing infrastructure, developing incident response procedures, and releasing AI systems responsibly after security evaluations.
Secure operations: This includes monitoring system behaviors and inputs, updating security procedures, and sharing learned security lessons.

The how and why of AI is essential

Chaitanya Belwal, a senior director at the security firm Tanium, said that while the guidelines touch on the transparency of AI models, more should have been included on interpretability, providing some insight or explanation into how and why a model makes the predictions or decisions that it does. “While the document is intended for use at a high level, and it is not supposed to give specifics, one thing it should address is the interpretability of the models.”

“Right now, there are special notes on building machine-learning models, and it also discusses some extra procedures to handle adversarial machine learning (AML), including prompt injection attacks and handling data corruption. But if a model is not interpretable, the developers cannot address several of the challenges mentioned in the document.”
—Chaitanya Belwal

Deep neural networks are notorious for being black box–like, and the reasons for assigning particular weights to specific inputs can be decided only after tracing all the steps in developing the system, Belwal explained.

“Guidance on interpretability of a model will help align the industry and force it to innovate new techniques and come up with an interpretability score for each model."
—Chaitanya Belwal

Software producers are on the hook

Securing AI development is going to be critical, especially since the consequences of not doing so could be very painful for providers.

The complexity of modern software supply chains makes it harder for end users to understand where responsibility for secure AI lies, the guidelines explained. The agencies added that users — whether end users or providers incorporating an external AI component — do not typically have sufficient visibility or expertise to fully understand, evaluate, or address risks associated with the AI systems they are using.

For that reason, the guidelines' authors reasoned, providers of AI components should bear the security burden for their products.

Software teams should implement security controls and mitigations where possible within their models, pipelines, and systems, the guidelines recommend, and, where settings are used, implement the most secure option as the default. Where risks cannot be mitigated, the provider should be responsible for informing users further down the supply chain of the risks that they and their own users are accepting and advising them on how to use the component securely.

Paul Brucciani, a cybersecurity advisor with WithSecure (formerly F-Secure), said that puts a lot of responsibility on software teams.

“It is interesting to note that the responsibility to develop secure AI lies with the provider, who is not only responsible for data curation, algorithmic development, design, deployment, and maintenance, but also for the security outcomes of users further down the supply chain."
—Paul Brucciani

With a system compromise potentially leading to tangible or widespread physical or reputational damage, significant loss of business operations, leakage of sensitive or confidential information, and legal implications, AI cybersecurity risks should be treated as critical, the AI guidance stresses.

MFA and software supply chain security: It's no magic bullet

jaikumar.vijayan@gmail.com (Jaikumar Vijayan) — Tue, 12 Dec 2023 12:00:00 GMT

With attackers increasingly targeting developer accounts and using them to poison software builds, manipulate code, and access secrets and data, development teams are under pressure to lock down their development environments.

Attackers are targeting the extensive access that a typical developer has to source code, code reviews, code commits, code modification, and other privileged tasks. The attacks on SolarWinds, Codecov, and Kaseya in recent years all demonstrate the havoc that an adversary with access to a development environment can wreak on both the victim organization and its downstream customers.

Several high-profile organizations have begun requiring developers to use some kind of two-factor or multifactor authentication (2FA and MFA) to protect their accounts. However, while authentication can help secure your software development life cycle (SDLC), it's not a comprehensive approach to managing risk in your supply chain.

[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]

Is it time to mandate MFA?

In response to the rise in attacks on the SDLC, GitHub, which constitutes a central component of the software supply chain for many organizations, has begun mandating 2FA for all the 100 million users that submit code to the repository.

In the months since then, the Microsoft-owned organization has been moving users over to MFA in large numbers. Users have the option of using SMS text messages or time-based, single-use passwords as their second authentication factor. Eventually, developers who choose to not use MFA will be locked out of their accounts.

Many other code repositories and organizations have begun requiring the same or have implemented MFA for a while. Examples include Apple and Google, which require MFA for all accounts in a developer program. Earlier this year, Valve, the company behind the popular Steam video game platform, announced plans to require MFA for developers after an attacker compromised a developer's credentials and distributed malware to Steam's users.

Alex Ilgayev, head of security research at Cycode, said organizations need to make 2FA a mandatory requirement for every system in the development process, including code, build, package managers, and cloud.

"In many recent breaches, attackers have managed to grasp developer-privileged access to the system through simple techniques like phishing or compromising developer workstations containing a lot of sensitive information such as tokens and passwords. Requiring developers to use a second authentication factor, in addition to their password, can mitigate most of these risks while also forcing potential adversaries to develop more sophisticated attacks."
—Alex Ilgayev

The use case for MFA in the SDLC

Kyle Hankins, managing principal of application security at Coalfire, said MFA increases the likelihood that a developer accessing data or taking an action is who they say they are.

"Historically, passwords are abysmal at doing so consistently and safely, in part because they tend to be stolen/guessed fairly easily or are hard to remember, which poses its own problems. 2FA can mitigate risk caused by stolen credentials and is useful in any situation where the impact of credentials being used by an attacker would have a significant impact."
—Kyle Hankins

Potential use cases for MFA in the software development lifecycle include making it harder for attackers to use a developer's credentials to make unauthorized code changes, merges, and commits; stealing credentials and secrets; accessing data; pushing unauthorized infrastructure changes; and releasing software into the production environment. Organizations can also use MFA to secure CI/CD consoles, log dashboards, and pipeline definition files, and they can require accounts with privileges to make major pipeline changes.

MFA is not an 'end-all solution'

Scott Gerlach, co-founder and CSO of StackHawk, said it's important to put MFA into perspective. "All software development teams and, frankly, every team within an organization, should be using [MFA] to access the systems they need to do their job."

However, Gerlach said that while implementing MFA helps reduce authentication risk, it is "not an end-all solution."

"You still have to design authorization processes to match the job roles needed. Just because someone can authenticate does not mean they should be automatically authorized to perform actions like approve pull requests or push code to production. Sane processes should be in place to ensure testing, code review, and third-party approvals exist in CI/CD processes."
—Scott Gerlach

Coalfire's Hankins said it's key for development teams to understand that MFA is not solving any core security issue. MFA bolsters the efficacy of existing password and other single-factor authentication mechanisms, but it does not address insider risks.

"If an insider can log in with a password, adding [MFA] doesn’t make it harder for that malicious insider to log in. Where it does help is instances where a user might have their password stolen. In that case, the second factor —unless it is also acquired — would prevent the unauthorized access."
—Kyle Hankins

Tokens to the rescue?

The wide use of security tokens in CI/CD processes is another way to expand authentication, said Cycode's Ilgayev. Organizations use security tokens — such as OpenID Connect (OIDC) tokens and access tokens — as keys for granting developers access to the CI/CD pipelines, infrastructure, and secrets needed to build, test, and deploy applications. The tokens contain information such as the user's permissions and scope of access in the pipeline.

Most security tokens can perform a range of privileged actions and can bypass MFA configured for that system because they are run through automation, Ilgayev said. "For example, I may have 2FA configured for my AWS account, but once I generate service account tokens, I can invoke them anytime and everywhere without the need for additional approval."

In the modern SDLC, CI/CD processes are usually included in the code repositories. This makes it harder to segregate duties and manage authorization for sensitive build processes, Ilgayev said. This gives intruders a potential vector for accessing an organization's production environment via the build system.

"As an example, if I'm using GitHub Actions, the CI is managed in GitHub and can be altered by any developer."
—Alex Ilgayev

A call to action on a comprehensive approach

MFA is also a limited approach because it introduces a certain amount of friction into every login or activity that requires it, Hankins said.

For some tasks, such as commits to production, especially on publicly accessible sites such as GitHub, MFA is a valuable safeguard. But it can be cumbersome in other instances and does not provide a comprehensive approach to manage the associated risk.

"While [MFA] can be effective for denying malicious access to code repositories and build services, it doesn't cover the entire SDLC."
—Alex Ilgayev

Given the privileged access in question and the potential downstream risk exposed by recent attacks, organizations need a separate set of processes to mitigate risk.

Matt Rose, Field CISO at ReversingLabs, said MFA is valuable in helping to ensure that developers are authenticated properly. But adding an additional step to the process of developing code is at odds with the speed and scale in modern DevSecOps environments.

"In order for it to be effective it has to work with the way developers write and commit code and not a new or different process. The last thing anyone wants is another excuse to push back on security teams."
—Matt Rose

Developers behaving badly: Why holistic AppSec is key

ericka@chickowski.com (Ericka Chickowski) — Thu, 07 Dec 2023 12:30:00 GMT

A recent survey shows that untested software releases, rampant pushing of unvetted and uncontrolled AI-derived code, and bad developer security are all combining to seriously expand security risks across software development. Add in the explosion of low-code/no-code development and economic pressures that are forcing developers to deliver features with less support, and you have an AppSec world that’s facing a tumultuous 2024.

While the buzz around shifting security to the left, or earlier in the development lifecycle, is still pushed by many DevSecOps advocates — and for good reason — the mantra of "test early and test often" can only get an application security or product security team so far in moving the needle on software risk.

Comprehensive application security (AppSec) is much more than squashing bugs early in the development lifecycle. Mature organizations recognize that they need to mature their AppSec approach to keep pace with modern development and release practices. Here's why a more holistic AppSec approach is key.

[ See related: How legacy AppSec is holding back Secure by Design | See Webinar: Secure by Design: Why Trust Matters for Software Risk Management ]

Curbing bad developer security behavior

A recent survey conducted among 500 developers worldwide by SauceLabs illuminated lot about "Developers Behaving Badly," as the survey was dubbed. One of the key themes to bubble up from the report had absolutely nothing to do with when or how testing is conducted. It had to do with the security hygiene practiced by developers daily.

The fact is, it's not so great. About three-quarters of developers admit to circumventing security measures by doing things such as disabling multifactor authentication (MFA) or going around the VPN to speed up their work. Similarly, 70% admit they've shared credentials — with 40% saying they do so regularly.

This report points to a huge need for security support in creating developer guardrails that are embedded in the CI/CD pipeline, so that developers can still move quickly but do so safely. That means putting in place well-architected identity and access management (IAM) functionality, as well as thoughtful permissions throughout the entire development workflow — but especially when it comes to touching the highest-value assets.

Nir Valtman, founder of the software security firm Arnica, said that minimizing the attack surface by reducing the permissions to source code, the place where the problem starts, is key.

"If the company culture is to provide access to push code for all developers, then apply branch protection policies to require pull request-reviews by the right owners and review the CI/CD permissions and triggers."
—Nir Valtman

A big part of this holistic approach to curbing bad operational security is visibility. Valtman said organizations should also be monitoring for abnormal behavior in development tooling and code repositories. Ideally, security should get buy-in with their approach.

"An abnormal behavior can be the result of an insider threat, account takeover, or a malicious third-party library. Use an anomaly-detection mechanism across your development ecosystem, but make sure the developers like the selected approach. Empower developers to own security in a simple and scalable way — let them pick the right security solution for them.
—Nir Valtman

Shift everywhere with your testing

Security testing — and the remediation and refactoring that follows — is obviously a core part of every application security program. Unfortunately, in spite of the best efforts of DevSecOps pundits and AppSec advocates today, a lot of the security tests mandated of developers today still remain out of phase with their CI/CD pipeline and manually conducted. When the "Developers Behaving Badly" survey asked developers, 67% said they could and did push code to production without conducting security testing, and nearly a third of them reported that they do it often or very often.

When the "Developers Behaving Badly" survey asked developers, 67% said they could and did push code to production without conducting security testing, and nearly a third of them reported that they do it often or very often.

The goal of the shift-left movement is to build security gates into the pipeline as early in the development process as possible, and to automate testing. But early tests at the code and component levels won't catch every AppSec risk. Shifting right — or shifting everywhere — allows AppSec teams to identify risk in the context of how software will be deployed, said Saša Zdjelar, Chief Trust Officer at ReversingLabs.

"As you shift right, you lose componentry, or unit-level control, but you gain context, as people add more and more code. As first-party code gets combined with third-party commercial and open-source imports and includes, that container size grows and it becomes something closer and closer to a full-built product."
—Saša Zdjelar

As an organization consumes or produces software, introducing testing at the very end before pushing to production makes it possible to check for malware that may have infiltrated the software supply chain, tampering, problems with digital signatures, and the inclusion of sensitive information or development secrets.

"Those are the characteristics of software that we believe should be checked at the very end."
—Saša Zdjelar

Account for development risks from generative AI

Further complicating the testing issue is the addition of generative AI to the development cycle. Tools such as GitHub Copilot and ChatGPT stand to greatly accelerate developer productivity, but utilizing code produced through GenAI adds more to the risk equation.

In a recent Security Table Podcast, longtime AppSec veteran Jim Manico, founder of Manicode Security, explained the scenario succinctly.

"To be a developer and not to use AI is going to put you behind the eight ball real fast. To use AI as a developer is necessary because if you don't your productivity is going to be one-third to one-fourth of your peers. But if you're using AI without security review, you're screwed in a bad way."
—Jim Manico

The "Developers Behaving Badly" report found that most developers are failing to do that review. Approximately 61% of respondents said they've used untested code generated by ChatGPT, and more than a quarter do it regularly.

Holistic AppSec programs are going to need the policies, developer education, tooling, and security guardrails necessary to meet these AI risks head on, as it is inevitable that generative AI is embedded into developer processes given tools like GitHub Copilot.

Low-code/no-code: A call to action on guardrails

Speaking of inevitability, another huge one is the looming risks that are coming for organizations with regard to low-code/no-code development environments — for both professional developers and citizen developers. This is a looming issue that didn't make it into the "Developers Behaving Badly" survey but that, when combined with generative AI, is poised to cause the number of applications needing security scrutiny to mushroom.

Michael Bargury, founder of low-code/no-code security firm Zenity and author of the OWASP Top 10 for Low-Code, said the situation was already getting out of control.

"How does application security look when you are taking all your business users under your umbrella and allowing them to push code? And we are seeing [generative AI] make this even more of an issue — we're seeing thousands of applications being developed by AI in low-code/no-code environments and being directly deployed to production."
—Michael Bargury

Bargury said Zenity is working with many Fortune 100 companies that are grappling with how to create a holistic AppSec problem that includes the enormous body of apps produced in this way. He explained one engagement with a security team that's been looking at applications built by generative AI across their entire organization — 500 AI-derived applications, "and that was before they realized they hadn't accounted for low-code apps."

Once the company was able to get a software bill of materials (SBOM) on the low-code environment, it found that it had about 7,000 applications that were built by low-code with generative AI.

"The magnitude is enormous."
—Michael Bargury

At the same time, there's no stopping the tide of low-code/no-code. Just like with the rest of development environments, the modern AppSec team will need to start building automated guardrails and testing into low-code/no-code development in order to attain holistic AppSec.

6 ways AI can help security teams punch back

jpmellojr@gmail.com (John P. Mello Jr.) — Wed, 06 Dec 2023 12:30:00 GMT

From the moment OpenAI let ChatGPT out of the box, the potential for generative AI and large language models (LLMs) to cause harm has dominated conversations about the emerging technology.

Less talked about has been how AI can be a formidable weapon in the hands of the good guys. AI decision makers believe that among departments in the enterprise, IT operations will be affected the most by generative AI — more than security — according to data gathered by Forrester Research.

Forrester principal analyst Allie Mellen said in a new report on the use of generative AI in security tools that, while the tools are not yet widely available, they are coming.

"Security leaders need to be prepared for this new technology to affect how their teams operate."
—Allie Mellen

Here are six ways AI can be used by security teams to punch back at adversaries.

1. AI can be used to develop more secure code

Using AI for securing code is still in its infancy and has attracted skepticism from some security practitioners, but its potential can't be denied. In a presentation at InfoSec World 24, Mark Sherman, technical director of the Cyber Security Foundations group in the CERT Division at Carnegie Mellon University's Software Engineering Institute, said early experiments show promise but also have limitations. (See his slides from the talk in PDF form).

When using AI to secure code, Sherman cautioned, output must be reviewed by knowledgeable users. Unfortunately, most of the time that doesn't include programmers because they're not very good at reading and evaluating code.

2. AI can help address security staffing issues

Forrester's Mellen said that many implementations of generative AI in security tools today rely on chatbot-style features built into a separate view in an application. "As unique as this is right now, it ultimately does not naturally fit into the analyst workflow and is little more than a novelty,” she said.

The real value in generative AI is in addressing tasks automatically that were previously part of the analyst workflow. One example: writing draft incident-response reports. Mellen advised security leaders to look for generative AI implementations that fit into the analyst experience, to help analysts make decisions faster — not just force them to use another view or tab.

Generative AI can also improve the performance of less experienced security team members. At the recent Ignite conference, Vasu Jakkal, Microsoft corporate vice president for security, compliance, identity, and management, cited a Microsoft study that found that “new in career” analysts using AI-enabled tools produced responses to security events that were 44% more accurate and responded 26% faster across all tasks.

In addition, a large majority of the analysts said the tools helped improve the quality of their work (86%), reduced the effort needed to complete a task (83%), and made them more productive (86%).

3. AI can aid security teams in report creation

With tasks such as summarizing incidents for reporting purposes and creating human-readable case descriptions, generative AI can be used effectively. It can also convey information in a human-friendly way, which can be valuable in responding to customer service requests and in producing better product documentation.

4. AI can assist security teams in analyzing pattern behavior

With its predictive abilities, generative AI can help identify privacy risks, attacker activity, and risk scenarios, and it can suggest remediation actions.

5. AI can improve threat hunting

Generative AI can add speed and scale for scenarios such as security-posture management, incident investigation and response, and security reporting.

6. AI can be used to unify numerous security solutions

The number of security tools organizations have in use can be overwhelming for teams. Generative AI, for one, can bring together all the security signals and threat intelligence siloed in disconnected tools. That allows security teams to streamline, triage, and obtain a complete end-to-end view of threats across the digital estate, making response easier and quicker for analysts of every level.

The potential is there; it's time to put AI to work

Generative AI tech has the potential to greatly enhance our ability to detect and respond to cyber threats,” said Joseph Thacker, a security researcher with AppOmni.

“There are already so many companies building AI security analyst agents. It’s going to be vital to use AI for securing digital assets in the future.”
—Joseph Thacker

However, Forrester’s Mellen said patience is in order, because despite vendor promises, "this technology is currently available only to a select set of customers, if at all.”

“Every vendor we mentioned in the report (and have spoken with) has at least a press release related to the generative AI offering that it’s building, but none are generally available, or likely to be generally available, before the first half of 2024."
—Allie Mellon

10 tips for building an enterprise threat modeling program

chris@kerr.ventures (Chris Romeo) — Tue, 05 Dec 2023 12:30:00 GMT

Threat modeling has been taken up by many cybersecurity programs over the past few years. Now, with the release of the Threat Modeling Manifesto and an industrywide movement toward Secure by Design, threat modeling has the attention of enterprise management.

Security teams must now map out an actionable threat modeling program. Here are 10 key tips for how to build a proper foundation for a threat modeling program in the enterprise.

1. Choose a solid process

The first tip is to choose a process that will do the job of threat modeling well. For example, you might consider Adam Shostack’s excellent four-question framework for threat modeling, but that isn’t a threat modeling process. In the enterprise, you need more depth, since you will magnify the process across tens, hundreds, or thousands of engineers, depending on your organization's size.

A simple process with more detail considers five key aspects of a threat modeling process: scope, draw, analyze, mitigate, and document. With scope and draw, you answer Shostack’s question, “What are we building?” The scope step helps engineers understand the level of effort involved in a threat model up front so that they don't try to bite off too much at once. Draw leads engineers into the data flow diagram representation, which is based on polling of threat modeling communities worldwide and appears to be the most prevalent representation is use.

Analyze answers the question, “What can go wrong?” It's the step where engineers consider the potential threats by iterating through a diagram using a methodology such as STRIDE (a mnemonic name derived from "spoofing, tampering, repudiation, information disclosure, and elevation of privilege").

Mitigate answers the question, “What are we going to do about it?” In this step, engineers focus on applying mitigations to the identified threats.

The process concludes with document, so that the organization maintains a copy of the threat modeling output. Storing the work ensures that there is a starting point for consideration when revisiting a model in the future.

2. Embrace STRIDE

STRIDE is a simple but powerful methodology that is easy to understand and internalize. Use it as a starting point to teach your teams how to threat model, and then graduate to more complex methodologies.

3: Embed threat modeling in the SDL

Threat modeling in the enterprise is about repeatability. Embed it as a defined activity within your secure development lifecycle (SDL). First, document the process at a high level and mandate the placement of the threat modeling artifacts inside existing deliverables (if they exist). Then, integrate threat modeling into the systems your teams use daily, such as the Jira and Asana tracking tools.

4. Focus on the mitigations

Getting caught up in the thrill of the hunt regarding threats can be easy. Focus your enterprise program and your teams on mitigations. A threat model is only as good as its ability to mitigate threats.

Measure the mitigations created within all the threat models across the organization. Mitigations are the key to measuring the ROI of threat modeling.

5. Threat modeling quality checks and governance

Institute a quality-control check for each threat model. The security team can perform only some of the quality checks, so it's good to have security champions in the enterprise to lower the amount of work for security.

Ask these questions for each threat model: Did the team that created the model follow the defined threat modeling process? Were interesting threats discovered? Did the team properly apply mitigations to those threats? Was the model documented correctly? If the answer to most of these questions is yes, the model is giving value to the organization. The answers are not a statement of model quality, though. Instead, they are an acknowledgment that all models offer value. Don’t be judgmental or harsh; build a strong security culture with your feedback.

After threat modeling reaches a level of maturity inside the enterprise, extend the SDL to have a governance angle to threat modeling. Mandate the production of threat models at a predetermined scoping level. Enforce threat modeling at the user-story level for all new features and refresh threat models every three months when changes exist to the component.

6. Build a diverse collection of threat modeling champions

The Threat Modeling Manifesto says that building a diverse group of threat modeling champions will cause the quality of your threat modeling output to soar. Each role within a team has a different perspective and set of experiences. Product managers see a feature differently than developers or testers do.

7. Workshop the teaching of threat modeling

To deploy threat modeling across the enterprise, tens to thousands of future threat modelers must prepare. Because threat modeling is better caught than taught, one of the best approaches to teaching threat modeling is the workshop method, where the concepts can be introduced at a high level before diving into performing exercises that put threat modeling into action.

8. Embrace threat modeling coaches

Threat modeling coaches are security team members or security champions working with groups for a limited time to teach the threat modeling process alongside the team. Coaches are a powerful construct because they magnify the threat modeling process across a long organization, one unit at a time.

9. Broaden your threat sources

After internalizing STRIDE across the organization, look for other sources of threat to consider. Additional sources provide more context and fodder for the teams as they consider how to go deeper into the threat modeling discipline. Two good choices are the Application Security Verification Standard (ASVS) from OWASP and Common Weakness Enumeration (CWE) from Mitre.

10. It's not just tools — it's a mindset

Tools are essential, but they do not replace the internalization of threat modeling's essence. Threat modeling is a state of mind that the program must teach. After threat modelers grasp why they threat model and how the process works manually, they are ready to embrace threat modeling tools.

Get started with a good foundation

Threat modeling in the enterprise can seem like an impossible task. With these 10 tips, you can build or adapt your program to transform every team member into a successful threat modeler.

Chris Romeo is CEO of the threat modeling company Devici. This post originally appeared on Threat Modeling Connect.

The AI executive order: What AppSec teams need to know

jaikumar.vijayan@gmail.com (Jaikumar Vijayan) — Thu, 30 Nov 2023 15:39:44 GMT

The White House's sweeping executive order (EO) on artificial intelligence has put the onus on software vendors to implement proactive measures for assessing and mitigating potential security risks and biases in products that use AI.

The full implications of the EO will likely vary depending on the extent to which an organization's products and services might incorporate AI mechanisms or on whether they are dependent on them.

But at a high level, the EO puts pressure on organizations that produce AI-enabled, AI-generated, or AI-dependent products to adopt new application security (AppSec) practices for assessing these systems for safety, security, and privacy. They will need to account for risks, such as those from cyberattacks, adversarial manipulation of AI models, and potential theft or replication of proprietary algorithms and other sensitive data. Required security measures include penetration testing and red-team procedures to identify potential vulnerabilities and other security defects in finished products.

The EO also imposes other requirements, including the need for developers of AI systems to guard against the potential for bias to creep into their models, as well the need to maintain data that allows regulators and other stakeholders to audit their development techniques.

Some of the requirements in the new EO on AI are likely to be more relevant for builders of foundational AI systems — as the EO describes them — rather than others. But security teams reviewing AI initiatives are still in the hot seat. Here's what teams responsible for AppSec need to know.

A push toward AI security standards

Darren Guccione, co-founder and CEO at Keeper Security, said developers will be required to show that their public-facing AI systems are safe, secure, and trustworthy. And all of this will need to be done before an AI or AI-enabled system becomes available to the public.

"This EO provides clarity to the subject of accountability in how AI is developed and deployed across organizations."
—Darren Guccione

Standardized tools and tests will be developed and implemented to provide governance over new and existing AI systems, Guccione said. With the widespread adoption of AI systems, this means every organization will need to consider the EO.

"Given the range of recommendations and actions included, organizations will likely feel the effects of this EO across all sectors, regardless of where they are in their AI journey or what type of AI system is being used."
—Darren Guccione

Implementing the EO remains a work in progress

Many of the details describing how software developers will implement the EO's requirements remains unclear. However, the National Institute of Standards and Technology (NIST) will now develop standards and best practices for developing safe and trustworthy AI systems. This will include standards for red-team testing of AI systems before they are publicly released. The Department of Homeland Security will ensure that organizations in critical-infrastructure sectors apply these standards when using internally developed or externally sourced AI systems.

Ashlee Benge, director of threat intelligence at ReversingLabs, said software development organizations and publishers will need to follow NIST's AI standards and guidelines in order to secure government contracts.

"By laying out clear use guidelines and requiring transparency when it comes to security testing, this EO will likely force a deeper consideration of safety measures than may have originally been taken."
—Ashlee Benge

Benge said that for consumers of AI systems, data privacy — with regard to the use of personally identifiable information (PII) used to train AI models — is a serious concern.

"This is a potentially major issue for any developer of software with AI capabilities."
—Ashlee Benge

Marcus Fowler, CEO of Darktrace Federal, said the EO is a reminder that it is not possible to achieve AI safety without cybersecurity. The edict highlights the need for action on data security, control, and trust on the part of those developing AI systems.

"It’s promising to see some specific actions in the executive order that start to address these challenges."
—Marcus Fowler

Organizations will need to implement systems and safeguards to ensure that red teaming exercises are useful, he said. They will need to implement a continuous process for testing AI security and safety through a product's life cycle. Fowler said the EO's emphasis on red teaming and penetration testing is relevant to any discussion about AI and security.

"Red teaming exercises aim to test all the layers of an organization’s security posture. In the case of AI systems, that means testing for security problems, user failures, and other unintended questions."
—Marcus Fowler

The EO also pushes developers of AI systems to implement Secure by Design, introduced this year by the Cybersecurity and Infrastructure Security Agency (CISA) to shift ownership of security of software from consumers to producers, for every step of an AI system’s creation and deployment. "Security is a challenge for the here and now, as well as a necessity for tackling longer term risks," Fowler said.

A road map and guidelines for AI security

Resources are now available for organizations looking to develop their own road map to meeting the EO's objectives. The U.K.'s National Cyber Security Center (NCSC) and the U.S. CISA have released guidelines for secure AI system development. The document provides guidelines that organizations can use to implement Secure by Design principles, as well as the secure development, deployment, operation, and maintenance of AI systems. Each of the four sections in the road map drills down into specific measures that developers of AI systems can take.

The section on Secure by Design highlights the importance of threat modeling and staff awareness, while the one on secure development focuses on the need to secure the software supply chain, perform asset identification, and track and maintain detailed documentation. The document notes:

"Implementing these guidelines will help providers build AI systems that function as intended, are available when needed, and work without revealing sensitive data to unauthorized parties."

CISA has separately released its own road map for AI, which could serve as a model for developers looking for hints on how U.S. agencies plan to implement the requirements of the new EO on AI.

An SBOM for AI?

Matt Rose, field CISO at ReversingLabs, said the effective requirements of the EO are similar to that for a software bill of materials (SBOM), given that the EO requires developers to document everything that goes into an AI system, including whether it was created by an AI or a large language model (LLM).

"If the data that an AI system is pulling from is tainted in any way, it can basically create problems and potentially major security breaches."
—Matt Rose

The EO requires being "diligent and granular" about AI safety and security requirements, to ensure that users of AI systems and all other stakeholders have clear visibility into the technology that will house things like government and military secrets, as well as other information of critical national importance.

"It goes hand in hand with being fully transparent and self-attesting with an SBOM."
—Matt Rose

Legacy AST is not up to the job of securing AI development

However, the EO goes beyond attestation, Rose said. Developers will need to consider the security and safety of the AI tools on which their products are built, as well as the potential for hackers and other malicious actors to poison or attack these systems using that AI technology.

One challenge will be to understand where a generative AI system is getting its information. "They say the Internet is full of fake news. If your AI system is using data scraped from the Internet to come up with directed actions, then the information is only as good as the data it was sourced from," Rose said.

Addressing AI-related security challenges is ultimately about the ability to look for and understand the behavior and the source of AI-generated code in applications, Rose said. That requires more than the code scanning in traditional application security testing (AST). Rose said software composition analysis (SCA), SBOMs, and complex binary analysis of software packages are essential to securing AI systems.

The EO on AI is an important first step

The EO is important step in getting industry to pay attention to security and safety issues as they roll out AI systems, said Darktrace's Fowler. But additional guidance will be needed to help organizations get ahead of risk.

"But as the government moves forward with regulations for AI safety, it's also important to ensure that it is enabling organizations to build and use AI to remain innovative and competitive globally and stay ahead of the bad actors."
—Marcus Fowler

See ReversingLabs Field CISO Matt Rose's explainer covering the EO on AI:

Don't let CVEs distract you: Shift your AppSec team's focus to malware

jpmellojr@gmail.com (John P. Mello Jr.) — Wed, 22 Nov 2023 14:45:00 GMT

Chasing vulnerabilities can be a time-consuming and time-wasting pursuit for application security (AppSec) teams. A big part of the problem has been the sheer volume of vulnerabilities being reported in recent years, which increases the chances of invalid reports slipping through the system.

As ReversingLabs noted in its report in 2022, flaws in open-source software are contributing to a sharp rise in reports to the National Vulnerability Database (NVD), but emerging software supply chain attacks warrant a rethink of the NVD — and of the approach of software security teams — to go beyond common software vulnerabilities.

Adding to the challenge: a Common Vulnerabilities and Exposures (CVE) process that can be slow and bureaucratic. Not only does that mean that the machinery can't keep up with the rapidly changing security landscape, but it also encourages researchers to automate their endeavors, leading to an increase in low-quality reports.

Two recent cases highlight the problem with the CVE process: CVE-2020-21469 and CVE-2020-19909 — both marked with 9.8 CVSS scores — were deemed not to be vulnerabilities by the maintainers of the projects targeted by those CVEs.

No one is saying you should abandon CVEs and the NVD — plus, updates and enhancements to vulnerability reporting and scoring will improve the system. However, to properly manage AppSec risk, your team needs to shift its focus to malware and tampering, for example. Top subject matter experts explain why.

[ Get reports: The Monsters in Your Software Supply Chain | NVD Analysis: A Call to Action on Supply Chain Security ]

The shifting focus of threat actors

Dan Lorenc, founder and CEO of Chainguard, wrote on LinkedIn about the two problematic CVEs, emphasizing that they were only a small representation of a bigger problem with the CVE process. "[These] are part of a larger group — 138 new CVEs all entered the same day, backdated against things found earlier," he wrote.

"Someone is clearly scraping old issues and commits to file these in an automated fashion, without ever getting maintainers involved. Yes, CVSS is broken and needs to change. Yes, the NVD data quality is bad and could be improved. But the overall incentives need to change rapidly and we need a higher bar for entries placed against critical projects that will cause the most time to be wasted."
—Dan Lorenc

The ReversingLabs NVD report noted that in the context of rising software supply chain attacks, the growth in reports to the NVD suggests that the focus of malicious actors is shifting. And yet the NVD is still dominated by flaws in a handful of legacy platforms by firms such as Microsoft, Red Hat, Google, Apple, and Oracle.

Roger Neal, head of product at AppSec company Apona Security, said the CVE reporting process is fundamental to cybersecurity, offering a standardized method for identifying and cataloging vulnerabilities, but it is failing to keep up with the volume of reports and the pace of software development today.

“[It] does have its flaws, mainly due to the sheer volume of vulnerabilities being reported to the NVD database. Additionally, the static nature of the CVSS, which does not account for the actual exploitability of the vulnerability in relation to specific software, can be a limitation.”
—Roger Neal

Why prioritize malware over vulnerabilities?

Rather than wasting cycles hunting for obscure, non-exploitable or remediated security holes — and checking that box — AppSec teams should focus efforts on exploitability and look for evidence of compromise such as malware and tampering. Here are six reasons for prioritizing searching for malicious software over chasing vulnerabilities:

Malware is a real threat, while a CVE may or may not pose a threat to a particular organization. Malware actively targeting systems indicates that actual compromise or exploitation has occurred, compared to theoretical vulnerabilities that may never be leveraged.
Actively looking for malware such as Trojans, viruses, and other malicious software allows for faster incident response to mitigate damage and prevent spreading.
Malware detection gives actionable intelligence to security teams on what they should specifically look for and defend against on their networks.
Focusing on malware leverages defenses better because technologies such as antivirus, network monitoring, and host-based defenses are well suited for detecting known malware signatures and behaviors.
Finding malware shows teams how attackers are operating and the specific techniques they use. It allows security teams to track attackers and align their defenses to real activity.
Malware hunting can uncover unknown threats and may detect new variants or families not tied to known vulnerabilities.

CVSS 4.0 and EPSS to the rescue?

While acknowledging the importance of ferreting out malicious code, Apona Security’s Neal advocates for a balanced approach to defending organizations from threats, and he highlights new approaches, including the Exploit Prediction Scoring System (EPSS).

“Although the CVSS has its limitations, it shouldn't be completely abandoned. Instead, integrating CVSS with a suitable scoring metric like EPSS can provide a more comprehensive understanding of which vulnerabilities are most likely to be exploited.”
—Roger Neal

A dual approach allows teams to not only address impactful vulnerabilities, but also place equal emphasis on preventing malicious code, thereby enhancing an organization's overall security posture, Neal said. And some of the criticisms of the CVSS have been addressed in the latest version of the standard, version 4.0.

“The latest iteration of the CVSS has made significant strides in addressing the challenges associated with the CVE reporting process. This version enhances the granularity and specificity of vulnerability scoring, providing a more accurate depiction of the real-world risk posed by various vulnerabilities.”
—Roger Neal

Mayuresh Dani, a threat research manager at Qualys, said CVSS v4.0 adds additional sources such as threat intelligence and alleviates environmental metrics for better scoring a vulnerability. It also adds fields such as attack requirements and user interaction metrics under the exploitability metrics, he said.

“Using these new and granular metrics, consumers can ascertain the real impact of a vulnerability in their environment.”
—Mayuresh Dani

[ See ReversingGlass: EPSS 3.0 + CVSS: Why Prioritizing Software Risk is Key ]

Can more nuanced scoring make CVSS more relevant?

Callie Guenther, a cyberthreat research senior manager at cybersecurity company Critical Start, said the changes in the latest version of CVSS, which focus on ensuring a comprehensive vulnerability assessment and creating a more nuanced scoring methodology, are causes for hope — but will probably require further refinement.

Guenther said CVSS 4.0 was a "significant leap forward," but she noted that continuous feedback from the cybersecurity community would be critical to its success.

“The modular approach in CVSS 4.0, particularly the emphasis on threat intelligence and the introduction of the Supplemental Metric Group, is noteworthy. It might benefit from more extensive testing in real-world scenarios to ascertain its robustness."
—Callie Guenther

Bud Broomhead, CEO of IoT cyber-hygiene firm Viakoo, said the new CVSS version adds a new focus on resiliency, which is often overlooked during the initial stages of an exploit, and also is starting to address the Internet of Things (IoT), operational technology (OT) and industrial control systems (ICS) spaces.

“This new version of CVSS is — as many standards are — a look in the rearview mirror, catching up to the reality of how IoT/OT/ICS exploits have become one of the fastest-growing attack surfaces. Organizations concerned about their IoT/OT/ICS attack surface need to use CVSS as a base to build on. For example, the impact on the business from IoT/OT/ICS malicious hacks needs to be assessed in addition to CVSS.”
—Bud Broomhead

How legacy AppSec is holding back Secure by Design

ericka@chickowski.com (Ericka Chickowski) — Wed, 22 Nov 2023 14:00:00 GMT

After years of headline-popping software supply chain–related breaches — think SolarWinds, Log4j, 3CX, and MOVEit — software security advocates agree that organizations have to change the way they tackle application security (AppSec).

The overriding consensus from the experts is that software producers need better software development practices, such as following Secure by Design, which was proposed in April by the federal Cybersecurity and Infrastructure Security Agency (CISA). The idea of Secure by Design is relatively simple in principle, if difficult in practice to achieve. Security should be baked in at the conception of software, and security functions and parameters should be designed, architected, and coded into the software at every stage of its lifecycle. It advocates security education for developers, varied and thorough testing and detection of vulnerabilities during every step of the lifecycle, and security guardrails that make it easier for developers to code securely.

Secure by Design also ideally takes AppSec far beyond trying to code software without security bugs. Most longtime AppSec advocates explain it means hardening application infrastructure, architecting secure data flows, designing solid permissions and identity management into software, and establishing guidelines for secure configurations and deploying them by default.

These Secure by Design principles are the first step in transferring the responsibility of keeping software secure from the consumers of that software — who are constantly called to patch or remediate faulty software from their suppliers — and back onto the shoulders of software producers.

But Secure by Design is easier said than done. Open-source project leads, commercial software development companies, and internal enterprise software engineering teams all must battle against AppSec inertia. Developers and AppSec pros alike still contend with ingrained software development patterns and legacy tool sets built for a more reactive approach to AppSec.

The reality: Software security practices are mired in after-the-fact application security testing (AST) and scan-and-fix cycles, fixations on legacy vulnerability management programs, and endless patch cycles. Additionally, some security pundits believe that CISA's Secure by Design guidelines don't yet address the complexity of the modern software supply chain.

Here's what's holding back Secure by Design's potential, and how software security can move forward.

[ See related Webinar: Secure by Design: Why Trust Matters ]

Holistic AST is key

Saša Zdjelar, Chief Trust Officer at ReversingLabs and a longtime security practitioner, said the work by CISA to publish its seminal paper on Secure by Design helped mature industry conversation about software security. But there's still a lot of work needed before these principles, and the practices around them, can address the complexity of securing software today.

"That paper and the months of work put into it was good, but I'd argue that it still predominantly focuses on a very narrow set of problems that can come out of software. And, unfortunately, it's not the type of stuff we've seen in the largest breaches, recently. These breaches are caused by software supply chain ripples. 3CX and SolarWinds have more to do with malware implants and integrity issues than traditional vulnerabilities."
—Saša Zdjelar

Those types of supply chain weaknesses can't be found through traditional AST tools or software composition analysis (SCA), Zdjelar said, "because that's just not what they’re designed for." He said Secure by Design is still too wedded to traditional AST and SCA without encouraging better context of how software is compiled and deployed.

For Secure by Design to deliver on it's promise, organizations need more holistic tools that work for producers and consumers of software, Zdjelar said. He explains what he means by holistic AST by describing what crash tests did for ensuring the safety of cars.

"You crash-test it, and then you provide the insights into how it did from various angles at various speeds, airbags, crumple zones, all those sorts of things that we have agreed are the characteristics of a secure vehicle or a safe vehicle. But you wouldn't crash-test a radio volume knob and a windows up-down button and a seatbelt separately and a rear car seat separately and a visor separately. You crash-test the vehicle when it's been fully assembled so that you know how the system as a whole operates or will perform in that type of environment."
—Saša Zdjelar

One of the big problems with the shift-left movement of recent years, Zdjelar said, is that it focuses too intently on component views to the detriment of understanding the context of how it all operates in the completed software package. When Secure by Design is fully realized, the benefit will be early analysis while also doing integrity checks that ensure the crash-worthiness of software before it is shipped.

Incentivizing developers is essential

Another big impediment today is that, no matter how comprehensive or well-thought-out a Secure by Design framework may be, it won't count for a whole lot if developers aren't properly incentivized to act on it.

Hughes said there's no real incentive for developers to slow down or integrate more security, which they often view as friction.

"While security is the center of the universe for us security people, it is not for engineers and developers. One of the big reasons is that they're incentivized and graded in terms of performance based on other factors like the number of features that they push out or how effectively they bring down the backlog or their sprint velocity and all those kinds of performance metrics. They're focused on just getting things out as quickly as they can, and they align with the incentives of how they're graded."
—Chris Hughes

This is not the fault of the developers; it's a management problem. That is why Secure by Design demands that security leadership team up with business leadership to properly incentivize engineering.

Until development team incentives align with an organization's performance metrics, no behaviors are going to change, Hughes said.

"If security matters, we should evaluate people's performance on how they integrate security into the product development lifecycle or add security metrics as part of key performance indicators. It starts at the top, and it has to be institutionalized. Otherwise, nothing is really going to change."
—Chris Hughes

Sound AST methodology matters

On a more tactical note, Hughes cautioned that organizations that already have this kind of institutional buy-in still need sound methodology and planning to effectively execute Secure by Design. He recommended that organizations choose something such as the NIST Secure Software Development Framework (SSDF), which is mapped against the OWASP Software Assurance Maturity Model (SAMM).

Organizations that are still relying on legacy AppSec practices should switch to SSDF and SAMM for starters, Hughes said. "Ask, Are we using a secure development framework or methodology? And if we aren't, can we rally around one to start to integrate some of these security practices and techniques into our product development?"

However, Zdjelar said the guidance provided by CISA is "not even close to enough,” noting that the most infamous software supply chain attacks — 3CX, SolarWinds, and Kaseya — would have been missed.

“Not a single component of any of the AppSec programs currently listed in CISA’s guidance would have prevented any one of those.”
—Saša Zdjelar

Legacy AppSec tools find certain categories of vulnerabilities, "which are absolutely a concern, and should be worried about, but a holistic final exam for software is critical.

“What’s missing is the crash test for the system as a whole.”
—Saša Zdjelar

When product security met accountability

Effective product security leadership is another thing that is lacking in most organizations and that many experts view as crucial to Secure by Design. David Lindner, CISO at Contrast Security, said product security professionals need to be embedded in product teams.

"Product security plays a fundamental and significant role in making sure the core principle of Security by Design is followed. Secure by Design emphasizes integrating security considerations into every phase of a product's lifecycle, from its initial design and development to deployment, maintenance, and eventual retirement. Product security ensures that security is not an afterthought but an integral part of the entire process."
—David Lindner

Jamie Boote, an associate principal security consultant at Synopsys Integrity Group, said product security also can play a role in enablement. When product security is done right, the embedded security professionals can help bridge the gaps between security, engineering, and the business by reducing what Boote calls "cognitive friction," the mental effort it takes to understand and solve security problems.

"ProdSec can reduce cognitive friction that developers, architects, engineers, and other stakeholders experience by providing training, clear requirements, reusable solutions, and Secure by Design components that teams can adapt and use with minimal effort."
—Jamie Boote

The developer experience matters

The idea of easing the security burden for engineers stands at the heart of what Kymberlee Price, a longtime AppSec and security practitioner who recently started a security firm called Zatik, thinks is most direly needed to meaningfully enact Secure by Design.

"I'm honestly excited for Secure by Design as a concept being championed across the industry because that's the only way we are going to make a difference and improve security. I think we've well proven bolting it on after the fact isn't working right."
—Kymberlee Price

However, to help evolve the culture and mindset of engineers, she said, the security team needs to think about improving the secure developer experience.

"For security teams to actually execute on secure by design, we need to shift our mindset of how we create good security UX for developers. It can't just be, 'Do it because I said so.' We have to reach across the gap and say, 'I want to make this easy for you to do the right thing. Help me understand your business.'"
—Kymberlee Price

Open source isn't the whole AppSec picture

ReversingLabs' Zdjelar pointed out another weakness: The current iteration of Secure by Design planning is "hyperfocusing" on open-source software flaws.

"If we're talking here about how to secure enterprises, enterprises don't run on open-source software. They obviously have a lot of open source in use, but when you buy a product from SAP or you buy a corporate password manager or CyberVault, like a CyberArk or even LastPass, that is not open source. When you install Zoom in your environment, when you run Teams on your endpoint, that is not open-source software, and neither was SolarWinds Orion. So what runs enterprises is very, very large, complex commercial packages which may have some open source in them."
—Saša Zdjelar

Zdjelar said that for Secure by Design to be useful for an enterprise software portfolio, it needs to bring better visibility and vetting of commercial, off-the-shelf software into the mix.

Get your bearings on software supply chain security

Aquia's Hughes said organizations pursuing Secure by Design need to understand where they exist within the software supply chain, because that affects how they run components and how they ship their code.

"Everyone to some extent is a consumer of external software and products but also likely a producer of software and products that are being used either internally or externally by customers and consumers. And just understanding what your role in the ecosystem is and how you can strengthen those relationships and also be prepared if one of them has an incident so that it doesn't impact you or your stakeholders too much is part of the equation."
—Chris Hughes

ReversingLabs Launches Software Supply Chain Security Availability in AWS Marketplace

Ben Rice — Wed, 22 Nov 2023 10:00:00 GMT

We are thrilled to introduce another powerful way to add software supply chain security to your security strategy. Beginning November 20, ReversingLabs software supply chain security will be available directly through AWS Marketplace, improving how your team can fortify your application security.

AWS Marketplace is a curated catalog for security teams to discover, purchase, deploy, and manage third-party software, data, and services. The platform offers an array of cybersecurity solutions, among others. AWS Marketplace enables customers to compare options, read reviews, and quickly find their desired software. Then, they can deploy it to their Amazon Elastic Compute Cloud instance using 1-Click or the AWS Marketplace Management Portal. This approach empowers organizations to bolster their security posture with efficiency and agility.

Security teams often grapple with many vendors and security priorities as the threat landscape expands. Recent trends indicate that many security leaders seek to consolidate their vendors and processes. AWS has emerged as a popular solution to achieve this goal. It enables this transformation through:

Simplify procurement: AWS Marketplace makes it easy for customers to acquire, manage, and oversee third-party data from a single platform. Customers can consolidate their billing of AWS Marketplace purchases with their other AWS services, leading to enhanced financial management. This unified view of costs streamlines billing processes, reducing administrative overhead.
Optimize costs: Customized pricing, payment schedules, and contract terms help organizations ensure the scope of work and payment schedule align with organizational requirements. AWS Marketplace further empowers security teams to save resources by monitoring all IT spending with AWS cost management tools and centralizing software license entitlement management.
Better control and governance: Customers can have better control and governance over software spend by leveraging Private Marketplace, a customizable digital catalog of authorized software and data products, as well as Vendor Insights to simplify third-party software risk assessments by compiling security and compliance information into a unified dashboard

According to a 2022 Forrester Total Economic Impact study, AWS Marketplace customers experienced significant advantages, including

75% reduction in onboarding efforts for new vendors
66% time savings due to procurement efficiencies and a
10% reduction in licensing costs.

David Hoffman, Senior Business Manager for Sony Corporation of America shares that AWS:

“Let us connect our AWS and Trend Micro bills to understand how the two are related. It helped us reduce procurement time on approved software from 60 days to a few minutes and made our billing and chargeback process much easier. We are now able to provide straightforward access to software in the cloud for our employees, streamlining the procurement process while still maintaining control…. [W]e have improved our overall security stance as well as established an improved process for quickly and securely getting products into the cloud”

Do you work with a cybersecurity reseller, consulting firm, or advisory group? No problem. Many of ReversingLabs’ premier partners, such as Guidepoint and Optiv, provide their expertise in addition to the benefits of AWS Marketplace.

Are you ready to explore software supply chain security in AWS Marketplace? Contact our partnership team to learn more. Embrace a new level of security, efficiency, and control in your security strategy today.

Visit ReversingLabs’ AWS Marketplace listing.

Protestware taps npm to call out wars in Ukraine, Gaza

paul.roberts@reversinglabs.com (Paul Roberts) — Thu, 16 Nov 2023 12:30:00 GMT

Newly discovered open source software packages on the npm platform contain scripts that broadcast peace messages related to ongoing conflicts in Ukraine and on the Gaza Strip when they are deployed, according to research conducted by ReversingLabs.

The packages are just the latest examples of so-called “protestware,” a recurrent issue in the open source software ecosystem in which application developers conceal political messages inside open source code, often designing it to display to the user after an application is installed or when it is executed.

Although the latest packages are not malicious, they underscore a persistent risk in open source software, in which unintended and malicious features can lurk undetected — even in widely used applications.

Protest package for Palestine

The npm package e2eakarev, version: 7.1.0, published in late October, describes itself as a “free Palestine protest package” and was posted by the npm user ~updater.downloader. It has a total of 8 downloads. ReversingLabs researcher Lucija Valentić found that installing the package launches a postinstall script, index.js, which checks to see if the package is being launched in Israel. If it is, an English language message calling for peace is displayed in the terminal.

“The world has witnessed too much suffering in Palestine, and it is time for us to take a stand,” the message reads in part. It calls on those reading the message to raise awareness of the “Palestinian struggle,” donate to humanitarian aid and back the “Boycott, Divest, Sanction" (BDS) movement, which seeks to encourage individuals and businesses to divest from Israel.

The message is signed “The Anonymous Protester.” And that… is about it. The package was not observed to perform any other actions — malicious or not, Valentić said.

Protestware: Sneaky!

Another npm package that was found recently to contain protestware is @snyk/sweater-comb, version 2.1.1, which was first published in August, 2023 by the firm Snyk. Sweater-comb is described as a “tool which provides guardrails with automation” of Snyk APIs by applying custom Optic CI rules to Snyk's OpenAPI specifications. Version 2.1.1 includes the module es5-ext, ECMAScript 5 extensions, a common module with more than 7.3 million weekly downloads. This is the last version of the Snyk package that includes the es5-ext module, with protestware functionality. All package versions since have opted out from using it as a dependency.

What does this protestware do? After installation, es5-ext launches a postinstall script, _postinstall.js, which attempts to determine the geographic location of the host. If the host machine is located in Russia, it shows a message, in Russian, that is critical of Russia's invasion of neighboring Ukraine, and in Russian when the package is installed in Russia.

“The whole world condemned the unjustified invasion and decided to impose unprecedented sanctions against Russia,” it reads. “With each new day they will be felt stronger and stronger among civilians.” Russian speakers reading the message are encouraged to download the Tor browser, and visit a web page on how to circumvent censorship in the country.

As it turns out, es5-ext is a package with a long history. The firm Checkmarx reported on it in March 2022, noting that the protestware feature was added to the es5-ext package in early March of that year, shortly after Russia invaded Ukraine. The same report also highlighted another module, styled-components, that was likewise updated to include a post-install script that offered pro-Ukraine protest messages.

ReversingLabs researchers have subsequently found the es5-ext used in other popular applications, including the installation executable for Signal Messenger for Windows. With about 10 million weekly downloads, the reach of the es5-ext package is broad. Within developer forums, the issue of the protestware features frequently crops up, as developers utilizing the es5-ext module contend with antivirus programs flagging their wares as infected with a virus.

Since July 2023, ReversingLabs detected 179 npm packages using the es5-ext package (a count that includes every version of each npm package). That isn’t a huge number. However, that list includes many legitimate packages like sweater-comb, Signal and version 6.4.0 of the shut framework with substantial distributions and user bases.

Figure 1: ReversingLabs’ report for Signal Messenger Windows installation executable showing the presence of protestware

That is concerning, because even though the postinstall script displaying the pro-Ukraine message isn’t malicious, it is unneeded.

“The problem is that this package is doing more than it advertises. It not only extends es5 with extra methods and shims, it also implements a "Call for peace" message. I think it's an unacceptable practice that slows done [sic] installation process,” a developer with the handle Rush commented on GitHub.

And that’s a problem. The ability of sketchy and unnecessary code like the latest protestware in es5-ext to work its way into widely used and legitimate applications and platforms like Signal, the shut framework and sweater-comb suggests that the cyber risks lurking in software supply chains are real.

Righteous? Yes. Malicious? Maybe.

Both of the examples of protestware cited above were just that: software that is used to convey a message of protest. ReversingLabs did not observe malicious functionality designed to disrupt the systems running the protestware, steal sensitive information or engage in lateral movement in either case.

However, not all protestware is benign. In the immediate aftermath of Russia’s invasion of Ukraine in February 2022, for example, an update to the vue-cli open source module was updated to include functionality that identified systems running in Russia and then wiped them of sensitive files and information.

As violent conflicts crop up around the globe, expect more instances of protestware that takes up the cause of both innocent victims and warring parties. In some cases, that protestware may come in the form of updates to benign and even well-established modules. A certain percentage of it will cross the line from benign display messages to actually inflicting damage on targeted systems.

Dig deep on package security

The lesson for organizations is that the days of whistling past the graveyard when it comes to software supply chain threats is over. Developers inclined to make hasty conclusions about the security or integrity of any piece of software based on its past performance, age or popularity are setting themselves up to be disappointed, said Tomislav Peričin, the co-founder and Chief Software Architect for ReversingLabs.

“We have seen an increase in the number of software supply chain attacks, impactful vulnerabilities, and other incidents. The risks that developers and software consumers face have never been higher, and that includes political messages. Having software perform random acts of political activism does little for the specific cause. But it does decrease the private sector’s already shaky trust in software."
—Tomislav Peričin

If you’re lucky, that disappointment may come in the form of a postinstall script throwing up an unexpected appeal for peace. At the worst, the protest may take the form of a wiped system, stolen data or a fast-spreading worm.

The presence of political protest messages in open source code is just one more indicator of the need for development organizations to dig deeper into the function and integrity of the open source, as well as third-party and proprietary code they rely on. Postinstall scripts like the ones found in e2eakarev and es5-ext may not cause damage, but they are often an indication of the willingness of the package developers to use their code as a platform for their own words, actions and ideas. When that happens without adequate disclosure to the users of the module (as was the case with es5-ext), it is cause for concern and additional scrutiny for any development organization.

ReversingLabs is constantly hunting for suspicious package behaviors. Our Software Supply Chain Security platform uses behavior indicators that can track if packages have postinstall scripts, allowing us to spot protest packages like e2eakarev and es5-ext and determine whether they are benign, malicious or somewhere in between. That kind of scrutiny of software dependencies is increasingly important as both malicious and political actors look to software supply chains to make their presence felt.

Next steps

As the discovery of these latest examples of protestware indicate, development and application security teams need the ability to peer deeper inside software packages and distinguish malicious functions from legitimate ones.

This can be challenging with legacy application security testing tools, and demands specialized skills and knowledge that many organizations lack. Modern tools like ReversingLabs Software Supply Chain Security can bridge the gaps, and help development and application security teams protect their supply chain from compromise.

Indicators of Compromise (IoC)

The following IoCs were collected as part of ReversingLabs researchers' investigation of the e2eakarev and sweater-comb/es5-ex protestware packages.

package_name	version	SHA1
e2eakarev	7.1.0	a509f299c5a76ac0c91f9bfdd333cc367ce17dfa
sweater-comb	2.1.1	b76ec90d7e1ae59b108b62ee8f8979a98b99da28

Zero trust and threat modeling: Is it time for AppSec to get on board?

jpmellojr@gmail.com (John P. Mello Jr.) — Wed, 15 Nov 2023 16:48:24 GMT

As the use of zero-trust architecture grows, it's becoming apparent to threat modelers that if they want to reap benefits, they will need to modify their existing practices to do it.

With classic threat modeling, born from the fortified-perimeter school of cybersecurity, the trusted boundary divides protected assets and trusted users from threats and adversaries. Zero trust scraps that idea. And it can also be used to bolster application security, or AppSec.

Chris Romeo, CEO of the threat modeling startup Devici, wrote in a recent blog post that zero trust–based security assumes attackers are in the environment and that data sources and flows can no longer be hidden, which is essential to hardening AppSec.

"[Zero trust] has vast implications for application security and threat modeling. Zero-trust threat modeling means the death of the trust boundary. This uncovers threats never dreamed of in classic threat modeling."
—Chris Romeo

Here's what your team needs to know about zero trust and thread modeling — including key benefits and challenges when extending it to harden your AppSec.

[ Learn more: Threat modeling and the supply chain: An essential tool for managing risk | Webinar: Supply chain security meets threat modeling: Why it's needed ]

Expanding the zero-trust concept to AppSec

Patrick Tiquet, vice president for security and architecture at Keeper Security, said that instead of relying on traditional perimeter-based security measures, zero trust assumes no implicit trust, so verification is required from anyone or anything trying to access resources — including software, which represents a growing attack surface.

"With a growing majority of ransomware attacks, supply chain vulnerabilities, and insider threats originating from what is traditionally thought to be inside the security boundary, zero-trust threat modeling has become critical."
—Patrick Tiquet

Tiquet said threat modelers must accept the reality that there is no trusted safe zone and adjust their models to recognize threats that may be anywhere — including inside the traditional boundaries. That's essential when considering the nature of today's software supply chain attacks.

Flexible boundaries are key to zero trust

Dhaval Parekh, senior director for information security at the cloud security company Zscaler, said that rather than disappearing entirely, trust boundaries in zero trust become more fluid and dynamic. “Each component, user, or device is evaluated individually based on their authentication, authorization, and behavior,” he said.

“The trust boundary in a zero-trust environment shifts from being a fixed perimeter to a more granular and context-dependent boundary. It is defined by the access controls, authentication mechanisms, and continuous monitoring in place for each component. The trustworthiness of a component is established through ongoing verification of its identity, behavior, and compliance with security policies.”
—Dhaval Parekh

Parekh offered four recommendations for zero trust in general threat models — which can also be applied to AppSec.

Identify and validate assumptions. Challenge traditional assumptions about trust within the network and consider that no user or device should be inherently trusted. Threat modelers should question assumptions about network boundaries and trust relationships between different components.
Define trust boundaries. Clearly define trust boundaries and enforce strict access controls at each boundary. Threat modelers should consider implementing microsegmentation to create smaller trust zones within the network, allowing for more granular access control and limiting lateral movement in case of a breach.
Assess and mitigate risks. Analyze potential attack vectors and vulnerabilities within the system. Identify potential threats, such as insider threats, compromised devices, or malicious actors, and evaluate their impact on the system. Implement appropriate security measures to mitigate these risks.
Consider zero-trust architecture. Threat modelers should recommend evaluation and the adoption of a zero-trust architecture, such as the use of software-defined perimeters (SDP) or secure access service edge (SASE) solutions. These architectures provide comprehensive security controls and help enforce zero-trust principles effectively.

How zero trust benefits all threat modelers

Zero trust can be beneficial to threat modelers because it weans them off the “outside-in” mindset, said Andrew Barratt, managing principal for solutions and investigations at Coalfire. “You’re essentially deeply considering how an assumed bad actor, from any resource, may try to compromise any other resources."

Barratt said zero trust means that all resources should have zero access by default and explicitly look for approved, authorized, and authenticated access. And that applies to locking down your entire software supply chain, including all CI/CD tools, for example.

"From a threat modeling perspective, we now have to consider the threats that might have compromised credentials and are living off the land. Those new threats are actors that look like approved users or activities, and, as such, we need to consider behavioral analysis to determine how likely the actor is to be rogue.”
—Andrew Barratt

One of the challenges this new way of thinking imposes on threat modelers is that they must have a very high depth of understanding of the systems being protected.

“The collaboration when modeling these threats will require multiple sets of expertise, as well as the ability to consider that a threat actor may already have found access or has compromised an authorized user, perhaps even physically with threats of violence."
—Andrew Barratt

Zscaler's Parekh said that by challenging traditional trust assumptions — and considering all components as potentially untrusted — threat modeling can identify a wider range of attack vectors and vulnerabilities that may have been overlooked in traditional models.

However, Anthony Tam, manager of security engineering at Tigera, said there is some downstream risk with zero trust and AppSec because, as zero trust increases the focus of the security model around application and infrastructure, it can open the door to adversaries elsewhere. Teams need to be aware and account for this risk.

“Vulnerabilities in the application or software dependencies can be attack vectors that bypass the security controls that were designed in a system’s zero-trust model."
—Anthony Tam

Parekh said zero trust’s emphasis on the principle of least privilege can help manage such risks, because it allows potential attack surfaces to be identified and reduced by implementing appropriate access controls, microsegmentation, and network segmentation techniques.

Zero trust also promotes the implementation of granular access controls at every level of a system, so threat modelers can identify and evaluate the specific access requirements for each component and user, enabling more precise threat analysis and risk mitigation strategies, Parekh said.

With continuous monitoring and detection of anomalous activities, threat modelers can leverage zero trust to identify the necessary monitoring capabilities and detection mechanisms to detect potential threats and security incidents.

“By incorporating continuous monitoring into the threat model, organizations can proactively identify and respond to security events in a zero-trust environment."
—Dhaval Parekh

Key challenges for threat modeling and AppSec

Working with zero trust can be trying for AppSec threat modelers, said Devici's Romeo.

“Zero trust is vast and complex, and securing something complex versus simple is more challenging."
—Chris Romeo

Romeo said that everyone's zero-trust deployment is different.

"Yes, they use the same principles and architecture patterns, but they are not the same. We cannot review and secure the reference architecture once and expect that we will be good to go in perpetuity. [No] reference architectures exist in the real world."
—Chris Romeo

Parekh said implementing a zero-trust architecture can introduce complexity, given the need for granular access controls, micro-segmentation, and continuous monitoring.

And there are always the difficulties that come with any initiative that introducing change to the status quo in security organizations, especially spanning security operations (SecOps) and AppSec.

“Implementing zero trust requires a shift in mindset and culture throughout the organization. Threat modelers may face resistance or challenges in gaining buy-in from stakeholders and ensuring consistent adoption of zero-trust principles across all teams and departments.”
—Dhaval Parekh

Matt Rose, Field CISO at ReversingLabs, said the concept of zero trust is evolving, "just like the way modern software and applications are being developed is evolving."

"The concept of zero trust needs to be a mindset above and beyond vulnerabilities, but take into account all aspects of the software and applications you develop internally and use from external sources."
—Matt Rose

8 CI/CD security best practices: Protect your software pipeline

ericka@chickowski.com (Ericka Chickowski) — Tue, 14 Nov 2023 14:00:00 GMT

With CI/CD approaches to software development spreading ever more widely, the benefits are stacking up for many organizations. A recent study by the Continuous Delivery Foundation (CDF) shows that developers who use continuous integration/continuous delivery (CI/CD) tools are more than twice as likely to be top performers in restoring service and also have the edge in both deployment frequency and lead time for code change.

But the automation and complexity of CI/CD pipelines and processes can introduce significant security risks to the development process if organizations don't plan carefully. Not only do organizations need to ensure that security checks are built into the fast-paced workflow of CI/CD processes, but the tools and integrations of the CI/CD pipeline itself must also be protected.

Here are eight best practices for hardening CI/CD build environments and baking security into the software pipeline.

[ Learn why legacy AppSec tools put your organization at risk: The Software Supply Chain Security Risk Report ]

1. Reminder: CI/CD tooling is part of the supply chain

A critical flaw in the CI/CD tool JetBrains Team City came to light this September was being actively exploited by October. This highlights the importance of securing the CI/CD pipeline.

A key fundamental to CI/CD security is remembering that CI/CD tooling is as much a part of the software supply chain as any open-source component that goes into the code.

The JetBrains flaw, a remote code execution (RCE) vulnerability accessible to nonauthenticated users, garnered a 9.8 CVSS rating. It was actively exploited by multiple North Korean threat actors within weeks of disclosure.

Henrik Plate, security researcher for Endor Labs, said that exploiting the JetBrains vulnerability could provide attackers with access to secrets, source code, and other assets consumed or produced on the respective CI/CD system.

"As such, it gives rise to supply chain attacks that have far-reaching consequences, not only for the organization running a vulnerable version of TeamCity, but for all users that download and execute software built on such a system."
—Henrik Plate

As Plate noted, the latter is the worst-case scenario, where attackers quietly manipulate software created by flawed tooling such as TeamCity to create legitimate-looking but malware-infected software.

"This underlines to what extent the security of today’s software depends on the security of upstream dependencies of all kinds, not only embedded components — those that become part of the actual software product — but also all the other components used throughout the software development lifecycle, from code to cloud."
—Henrik Plate

Harman Singh, director at cybersecurity firm Cyphere, said that means you must keep track of updates, vulnerabilities, and dependency problems within CI/CD tooling just as you would for any other software.

"By keeping dependencies up to date, organizations can mitigate the risk of exploiting known vulnerabilities. By keeping dependencies up to date, organizations can mitigate the risk of attackers exploiting known vulnerabilities."
—Harman Singh

Liav Caspi, CTO of Legit Security, said that organizations should also be verifying the security and integrity of the components, plug-ins, the GitHub Actions, and all of the other code that comprises the pipeline.

"Verify the build components you're using. Make sure you use verified components and not something shady that you don't know what's running in it."
—Liav Caspi

2. Tighten up access control and secrets management

One of the biggest mistakes that organizations make in securing their CI/CD pipeline is neglecting to implement strong access controls, said Singh.

"By failing to restrict access to sensitive resources, they expose themselves to potential breaches and unauthorized modifications. To avoid this, organizations should enforce the principle of least privilege, granting only the necessary permissions to individuals or systems involved in the pipeline."
—Harman Singh

Not only should organizations be enforcing the rule of least privilege within CI/CD tooling, but they should also ensure that they're using multifactor authentication wherever available. "By requiring multifactor authentication for all users accessing the pipeline, organizations significantly reduce the risk of unauthorized access and potential data breaches," Singh said. "This simple step adds an extra layer of security to the pipeline."

Part and parcel with all of this is the role of strong secrets management. Viktor Gazdag, managing security consultant for NCC Group, said that some of the biggest exposures and integrity problems within the CI/CD pipeline have to do with insecure handling of secrets, including hardcoded credentials and poorly secured stores of credentials in development environments.

"The scope and storage of the secrets are also often overlooked and misconfigured, allowing everyone or a wider audience to access them."
—Viktor Gazdag

3. Build security monitoring and telemetry into the pipeline

Vladislav Bilay, DevOps engineer for Aquiva Labs, said that for organizations seeking to level up their AppSec chops and maintain the integrity of their CI/CD pipeline, visibility is crucial. Continuous monitoring and feedback mechanisms are paramount, as is establishing a robust feedback loop for security information across the entire pipeline, Bilay said. That allows teams to detect and respond to potential vulnerabilities in real time.

"However, this requires a shift in mindset from periodic security assessments to an ongoing, integrated monitoring approach, demanding commitment and adaptability from DevSecOps teams."
—Vladislav Bilay

Yash Mestry, DevOps and security associate for Perpetual, said pipeline observability is huge in the era of cloud-native development and deployment.

"To understand the dynamic and dispersed nature of cloud-native systems, powerful observability and monitoring capabilities are needed. To do this, logs, metrics, and traces from multiple application components must be gathered and examined for signs of security threats and anomalies."
—Yash Mestry

Mestry explained that to securely make the transition from traditional application development to CI/CD and cloud-native development environments, organizations have to rethink their security telemetry and tooling to bring build visibility into the pipeline.

"Tooling must be flexible, automated, and capable of interfacing with the DevOps pipeline in order to support a cloud-native approach. In order to do so, security testing tools that connect with container orchestration systems, vulnerability scanners for container images, and security-as-code frameworks for automating security policies may be used."
—Yash Mestry

4. Security as code is key

The practice of building systems and configuration controls into the CI/CD pipeline that make it easier for developers to make sound choices in how they code, deploy, and run software is a no-brainer for AppSec risk reduction — whether you call that "developer guardrails," "security as code," or "Secure by Default." Rather than just teaching developers about security best practices, the best DevOps teams also set and implement security policies through code and configuration that’s built directly into the pipeline and underlying software infrastructure.

Derek Fisher, author of the Application Security Program Handbook, said in a recent interview on the Security Champions Podcast that it is ultimately about ensuring that engineers have the ability to develop code normally but with the confidence that they're secure.

"In terms of being able to deploy, you have your infrastructure as code developed in such a way that it ensures that you don't have things like configuration drift and that it follows best practices and patterns and nobody's allowed to tamper with that. So I think there's ways that we can build that paved road, those guardrails, to ensure that developers are just focusing on making sure that their code gets out the door on time."
—Derek Fisher

And when security as code is developed, the security team should be coming up with the policies in close collaboration with the developers, and in many instances the engineers may end up being the ones who develop the code that enforces guardrails on the daily. Application security is the sidecar to development, and that means it rides along with the engineers as they're building software, Fisher said.

"What I've found is that my team and the application security individuals that I've worked with are not always the ones coming up with the best solution. To be honest, the security teams are not going to know the full technical stack that the engineers are developing their software on. They may know enough to be dangerous, but they're not going to know all of those languages and all the nuances and the exact way to solve the problem in four different languages."
—Derek Fisher

5. Security gates are critical

A part of the process of setting up guardrails is enforcing the mentality of testing early and often — and integrating those assessment processes directly within the CI/CD pipeline, Fisher added. Establishing security gates and embedding them into the integration and deployment workflow is the bedrock for CI/CD security and improved AppSec performance.

"We need paved roads in existence from a security standpoint where your pipeline has appropriate scanning tools built in at the right times and a feedback loop back to development teams. It's not going to clear a gate with either a certain number or certain level of vulnerabilities, whether critical or high. Full stop."
—Derek Fisher

It's not as if this is a new or foreign concept for developers. "This honestly isn't much different than the way that we have the different guardrails in place to make sure that there's quality built into the development," Fisher said.

"You have unit tests, you have system tests, you have integration tests, and those are all there to ensure that defects are caught as quickly as possible and that the engineer or the development team is able to fix those and get them back out the door as soon as possible."
—Derek Fisher

6. Shore up your secure code signing

As threat actors increasingly target code-signing certificates to stealthily circumvent integrity checking of software code, development teams are going to have to do more to shore up the security of their code-signing processes. Christian Simko, vice president at AppViewX, said this is the gist of the new Code Signing Baseline Requirements issued by the CA/B Forum this year, delineating secure hardware for generating and storing private keys to prevent key compromises. These guidelines should be used to update code-signing practices.

Simko is an advocate for centralizing code signing, which has traditionally been distributed across different development teams and which also has not been very DevOps- or CI/CD tooling–friendly.

"This often leads to the use of multiple code-signing tools by different developers and insecure code-signing keys. To overcome this challenge and support the needs of development teams, organizations should implement a centralized code-signing model. This approach can be used to enforce code-signing best practices, integrate code signing into the CI/CD pipeline, and keep code-signing keys secure. It also modernizes code signing for scalability, efficiency, and agility."
—Christian Simko

7. Store software artifacts sanely

As security teams bolster the security testing, monitoring, and dependency tracking of software as it works its way through the CI/CD pipeline, they're going to be generating an increasingly growing mountain of security artifacts. This can become a data management and analysis nightmare without the right systems in place to sanely store the evidence, said Steve Taylor, CTO for DeployHub and a board member of CDF, in a recent presentation.

"We can't keep track of that in our head. So we need to push this information somewhere, and that's where we need to store the evidence."
—Steve Taylor

Taylor said that publishing security artifacts coming out of the build process into aggregated registry tools such as ArtifactHub, DockerHub, Quay, Maven Central, npm, or Pypi is crucial to making sense out of it all.

"Some of these registries are being extended to store any type of artifact. That's going to allow us to have a one-stop shop for managing all of these artifacts and getting the information about them from there."
—Steve Taylor

8. Don't forget to threat-model the pipeline

Threat modeling isn't just for software that runs through the CI/CD pipeline. Build environment components and the entire pipeline as it is deployed should also be put through their paces, said NCC Group's Gazdag. He encourages organizations to adopt a continuous threat modeling approach to CI/CD environments to keep an eye out for insecurities in connection boundaries, connecting components, and data flows.

"This will allow an organization to see the big picture with gaps and blind spots, so they can put in place the correct preventive and security controls. For example, developers can see where a credential is stored, where it is used, where it came from, how it’s stored, and who can access it."
—Viktor Gazdag

The call to action

With attackers increasingly turning their eye to development environments, organizations must take measures to prevent attackers from infiltrating CI/CD infrastructure to keep them from not only breaching the organization but also introducing dangerous flaws into their applications.

This blog post is an updated version of a 2022 story on CI/CD best practices that reflects the latest insights.

How supply chain security tools can protect ML models

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 09 Nov 2023 12:00:00 GMT

Solutions designed to protect the software supply chain can also be used to protect machine-learning (ML) models from similar attacks.Two such solutions are the Supply-chain Levels for Software Artifacts (SLSA) framework and Sigstore.

SLSA (pronounced "salsa") is a security framework — a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. Sigstore is an open-source project focused on improving supply chain security by providing a framework and tooling for securely signing and verifying software artifacts, including release files, container images, binaries, and software bills of materials (SBOMs).

Mihai Maruseac, Sarah Meiklejohn, and Mark Lodato argued in a recent post on the Google Security Blog that ML model makers should extend their use of the software supply chain security tools to protect ML supply chains from attack. Using Sigstore, ML model builders can sign a model so that anyone using it can be confident it's the exact one the builder, or trainer, created. The team noted:

"Signing models discourages model hub owners from swapping models, addresses the issue of a model hub compromise, and can help prevent users from being tricked into using a bad model."

Meanwhile, SLSA — used to describe how a software artifact is built and implements controls to prevent tampering — can be used to provide information not covered in ML model signing, such as a compromised source control or training process, and vulnerability injection. The team wrote:

"Our vision is to include specific ML information in a SLSA provenance file, which would help users spot an undertrained model or one trained on bad data. Upon detecting a vulnerability in an ML framework, users can quickly identify which models need to be retrained, thus reducing costs."

While the tools are a great first step for securing AI applications, they're not a complete solution. Here's what your security team needs to know about using SLSA and Sigstore to secure ML models.

Understand the limits of digital signatures

Digital signatures, when used correctly, can ensure that software, including AI platforms, have not been tampered with, said ReversingLabs field CISO Matt Rose. But signatures are no panacea.

“The problem is that the data of the AI platform is typically not secured in the same way. You need to worry about the supply chain for the software itself and the data it uses to function.”
—Matt Rose

Steve Wilson, chief product officer for Exabeam, said that by integrating digital signatures into AI development and deployment processes, organizations can significantly enhance the security and trustworthiness of their ML models and the data they are built upon. This, in turn, contributes to the broader goal of ensuring responsible and trustworthy AI systems

“While digital signatures are a powerful tool for enhancing supply chain security, they are not a panacea and come with certain limitations and challenges, particularly in AI and machine-learning models."
—Steve Wilson

Wilson cited a number of issues associated with digital signatures and AI, including:

Complexity and overhead: Implementing digital signature systems can add complexity and overhead to the development and deployment processes. This includes the need for secure key management, signature verification mechanisms, and the computational resources required for signing and verifying signatures.
Key management: Securely managing the cryptographic keys used for digital signatures is a non-trivial task. If keys are compromised or mismanaged, the integrity and authenticity assurances of digital signatures could be undermined.
Limited scope: Digital signatures ensure integrity and authenticity but do not address other crucial aspects of supply chain security such as confidentiality, privacy, or availability.
False sense of security: There might be a tendency to over-rely on digital signatures, leading to a false sense of security. Digital signatures can verify that a model or dataset has not been altered, but they cannot verify the intrinsic quality, fairness, or safety of the model or dataset.
Limited efficacy with training and dynamic data: Digital signatures might provide a level of assurance for on-premises foundation models by verifying their integrity and authenticity. However, they are less likely to address the challenges associated with training data or dynamic data, such as the data used for retrieval-augmented generation (RAG). Training data, crucial for building and fine-tuning models, is often vast and dynamic, making it challenging to ensure its integrity and authenticity through digital signatures.

Similarly, dynamic data that is continuously changing or being updated can pose challenges for digital signature verification, since the signatures can become outdated rapidly. This limitation underscores the need for additional mechanisms and strategies to secure the training data and dynamic data that play a critical role in the performance and behavior of AI models, beyond the verification of static, foundational model artifacts.

Good — but not good enough

Sigstore and SLSA are great for what they were designed to do — which is to secure the software supply chain, Rose said. But he said the problem is that even if the AI software package itself is not compromised, the data that the AI platform uses may still be tainted.

“These approaches need to be extended beyond just securing the software itself.”
—Matt Rose

Exabeam‘s Wilson said that the nuanced nature of ML systems brings about a distinct set of challenges and considerations regarding supply chain security. He said the SLSA framework serves as a solid foundation, but adapting it to the unique landscapes of AI and large language models (LLMs) requires a deeper level of contemplation and, potentially, the evolution of the framework itself, he explained.

“While SLSA lays a strong groundwork for supply chain security, the distinctive aspects of AI systems call for a tailored approach. This might involve extending SLSA, integrating it with other standards like ML-BOM, and fostering a broader understanding and community engagement to ensure supply chain security in the rapidly evolving landscape of AI and large language models.”
—Steve Wilson

Jeremy Newberry, a cybersecurity architect and strategist with Merlin Cyber, said that SLSA and Sigstore are good starts to the overall requirements, but they don’t answer the question for growing or self-improvement.

“They feel like a legacy approach to a new problem, and I believe a more modular and adaptive approach needs to be taken."
—Jeremy Newberry

True transparency is key

Google’s approach to AI supply chain security is a good first step toward securing ML models, but it's a fundamentally flawed approach, said Merlin Cyber solutions engineer Dean Webb.

“The Foundation Model Transparency Index rated Google’s AI at only 40% transparent, so we need more from the AI vendors than their instructions on how we, the customers, can shoulder the full security load. We need their transparency and cooperation in sharing that security load.”
—Dean Webb

OWASP Top 10 for LLM update bridges gap between AppSec and AI

jpmellojr@gmail.com (John P. Mello Jr.) — Tue, 07 Nov 2023 13:57:02 GMT

The first revamp of the OWASP Top 10 for LLM Applications has been released. With only minor changes, version 1.1 of the Open Worldwide Application Security Project's list of key vulnerabilities continues to advance the project team's goal of bridging the divide between general application security principles and the challenges posed by LLMs.

To achieve that bridge, OWASP added a visual illustration of the data flow in a typical LLM application to highlight the potential areas of risk from vulnerabilities. For example, the data flow between an API and an LLM's production services could be vulnerable to a prompt injection or a denial-of-service attack, or an application's plugins might contain excessive vulnerabilities.

Generative AI is advancing at a breakneck pace. To keep it from breaking your organization's back, here's a full rundown on the changes in the OWASP Top 10 for LLMs, a starting point for your dev and AppSec teams to get a handle on generative AI.

[ See Webinar: Secure by Design: Why Trust Matters for Risk Management ]

Mapping out LLM risk: Go with the flow chart

OWASP has to work fast to keep up with the changes in LLM technology; version 1.0 of the Top 10 for LLMs was released only in August.

Chris Romeo, CEO of the threat modeling company Devici, said the inclusion of the LLM application data flow chart is the most significant change in the new version.

"The data flow provides a reference architecture to help readers understand how LLM systems are assembled. Without that context, it is more challenging to understand how the LLM Top 10 risks fit together."
—Chris Romeo

OWASP Top 10 for LLM project leader Steve Wilson, also chief product officer of Exabeam, said the language describing the risks, as well as the examples accompanying them, have been cleaned up and clarified.

"Some people were confused about the differences between some of the risks. For example, insecure output handling and excessive agency used some similar examples, although different vulnerabilities were at their core."
—Steve Wilson

Prompt injection and output handling enhanced

The new version of the Top 10 for LLMs also increases clarity around the descriptions and manifestations within LLM architectures for prompt injection and insecure output handling. Dan Hopkins, vice president of engineering at the API security testing firm StackHawk, said this move was essential.

"Those tests will prove to be very visible to a user and demand targeted fuzzing at runtime for effective assessment."
—Dan Hopkins

A step in the right direction on securing AI

Version 1.1 is "a significant step in the right direction,” said Hopkins. “It’s great to see version 1.1 placing a strong emphasis on enhancing the clarity and understanding of vulnerabilities within an LLM-based architecture.”

“The dataflow specifically does an amazing job highlighting where vulnerabilities exist in the stack, making it abundantly clear why black-box testing of a running application is essential for secure LLM usage,” he added.

The security community is still learning about the wide range of AI capabilities, and the OWASP Top 10 LLM 1.1 reflects that, observed Priyadharshini Parthasarathy, senior security consultant for application security at Coalfire.

“The new version includes a lot of detailed information on LLM-specific terms such as 'pre-training data,' the embedding process, and fine-tuning of data on how the models are being trained. This document also updated the list of scenario examples and references in the prevention and mitigation strategies."
—Priyadharshini Parthasarathy

Top 10 risks remain constant

The top 10 risks in the latest version of the list remain unchanged from v1.0:

LLM01: Prompt injection—Used to manipulate an LLM through crafty inputs, causing unintended actions.
LLM02: Insecure output handling—Occurs when an LLM output is accepted without scrutiny, exposing backend systems.
LLM03: Training data poisoning—Occurs when LLM training data is tampered with, introducing vulnerabilities or biases that compromise security, effectiveness, or ethical behavior.
LLM04: Model denial of service—Happens when attackers cause resource-heavy operations on LLMs, leading to service degradation or high costs.
LLM05: Supply chain vulnerabilities—Can manifest when an application’s lifecycle is compromised by vulnerable components or services.
LLM06: Sensitive information disclosure—Can arise when an LLM inadvertently reveals confidential data in its responses.
LLM07: Insecure plugin design—Results in plugins with insecure inputs and insufficient access control, leading to consequences such as remote code execution.
LLM08: Excessive agency—Surfaces when excessive functionality, permissions, or autonomy is granted to LLM-based systems.
LLM09: Overreliance—Crops up when systems or people become overly dependent on LLMs without oversight.
LLM10: Model theft—Involves unauthorized access, copying, or exfiltration of proprietary LLM models.

OWASP Top 10 for LLM: The next generation

Future versions of the OWASP Top 10 for LLMs will need to evolve with the gen AI field itself, security experts note. Devici's Romeo said that he, for one, wants the document to include threat language for each of the Top 10 items.

“The document contains vulnerability examples today, but threat examples would provide direct input into the threat modeling of LLM applications.”
—Chris Romeo

StackHawk's Hopkins said it would also be great to expand the Top 10 for LLMs' procedures for ensuring the absence of vulnerabilities.

“Adding detailed descriptions that highlight AppSec techniques and their suitability for mitigating and preventing various vulnerabilities within the context of a sample architecture would be incredibly beneficial.”
—Dan Hopkins

Michael Erlihson, a principal data scientist at the API security company Salt Security, suggested that the vulnerability descriptions in the list should be expanded in a future version. Including mitigation strategies for each vulnerability would also be worthwhile for developers and security teams, he said.

“More detailed descriptions and examples of each listed vulnerability could help practitioners better understand the risks involved."
—Michael Erlihson

Erlihson also suggested including industry-specific guidance in the list, as well as historical data on the vulnerabilities. “Historical data on how the vulnerabilities have evolved over time could provide insights into emerging threats and trends,” he said.

OWASP Top 10 for LLMs project leader Wilson said OWASP is planning two major deliverables in the near future, as well as additional rigor:

International language versions of the list—“We're working on translating the list into 10 languages,” Wilson said. “We're almost done with Chinese and Hindi, which will allow a lot of software developers to consume this. We're looking to publish a bunch of those in the next month.”
A companion document for CISOs, called the Checklist—This document focuses on what needs to be considered as gen AI technologies are deployed in the enterprise. “We’re planning to have the first draft of that available for public comment in November,” Wilson said.
More rigor on data gathering—The aim here is to better highlight the likelihood and severity of risks to LLMs, Wilson said. “That's where we will almost certainly redefine some of the categories and change what's on the Top 10 list,” he said.

TitaniumCloud app for Splunk SOAR updated

contact@reversinglabs.com (ReversingLabs) — Mon, 06 Nov 2023 12:30:00 GMT

ReversingLabs has recently released version 1.2.0 of its TitaniumCloud app for Splunk SOAR. This release introduces our new network reputation action to help SOC teams identify malicious network indicators, increasing the count to a total of 33 available actions to improve your SOC team's efficiency. Here are the network reputation actions, and some example use cases.

What’s new TitaniumCloud for Splunk SOAR 1.2.0

This update mostly focuses on introducing our new network reputation APIs. Here are the new available actions:

• Get network reputation: the Network Reputation API provides a classification of network-related indicators, including URLs, Domain names, and IP addresses.

• Network reputation user override: this action enables TitaniumCloud users to override and set a classification value for a network indicator

• Get list user overrides: this action returns a list of all overrides made by a given user

• Get list user overrides aggregated: this action returns an aggregate of all overrides made by a given user

Continue reading to learn more about the network reputation capabilities of TitaniumCloud and how to effectively utilize the provided actions to automate the process of detecting and responding to network threats.

Network indicator reputation: Key for identifying malware

Network reputation lookups are a new feature that we are excited to offer our TitaniumCloud customers. Where other solutions only provide a one-dimensional result, TitaniumCloud combines traditional reputation information with our massive repository of billions of files and powerful file analysis capabilities to help SOC teams identify malware.

In Splunk SOAR, using the new “get network reputation” action will provide SOC analysts with reputation information for IP addresses, domain names, and URLs. The screenshot below shows the formatted output of an IP address lookup:

It is easy for analysts to gain insight into the reputation of an IP address, domain, or URL by referring to the bar graph that displays classification values from third-party analysis engines. Additionally, if TitaniumCloud has detected any malware samples related to the indicator, a simple True or False value is provided for quick identification.

Playbook use case: Artifact enrichment

This is a simple enrichment use case that will use the network reputation API to enrich all network indicators in a container. If any of the indicators are classified as malicious, the playbook will automatically update the severity of the container to High. Here’s what the playbook looks like when it’s finished:

The steps are pretty simple. First, create a filter that checks if the relevant artifact fields exist in the container:

By setting the condition to equal to true if the value of each artifact field isn’t empty, you can save on API calls in the event that the associated field isn’t present in an artifact. The next step is to call the network reputation action for each condition, using the associated artifact field as the network location input.

Next, add a decision step that checks if the classification value is equal to malicious for any of the reputation lookups. This can be accomplished by providing the classification value from each of the previous “get network reputation” actions as input to the conditional:

<action_name>:action_result.data.0.rl.entries.0.classification

From here, add another action that will set the severity to “High” if any of the indicators are malicious, and do nothing if none of them are malicious.

Using an enrichment playbook like this is a great way to help improve your SOC team's efficiency by focusing on the validated threats.

Playbook use case: IOC harvesting

By utilizing the "get downloaded files" action within the enrichment playbook, it is possible to expand its capabilities even further. This action checks in with TitaniumCloud to determine if any files associated with a URL have been previously analyzed for malware. This feature is particularly useful for identifying additional indicators of compromise and for blocking potential threats.

Simply adding the “network_locations” value from the previous network reputation action as input to the “get downloaded files” will return all files associated with the URL:

In this example, the supplied URL is hosting a single malicious PDF document. TitaniumCloud has already analyzed the file and determined it to also be malicious:

<action_name>:action_result.parameter.network_locations

The playbook in the previous use case can be further modified to take advantage of Splunk SOARs orchestration capabilities by integrating with your SIEM or EDR tool to check for instances of this document in the environment. The screenshot below shows an example of using Microsoft Defender for Endpoint’s Advanced Hunting query action to look for the associated SHA1 file hash:

The rest of this example playbook continues along the same path as the previous example by setting the severity to High if any indicators are malicious, but you can use your imagination to add additional steps that are relevant to your environment and workflows. Consider taking actions to block the discovered indicators, send the indicators to your TIP, or even quarantine endpoints if samples are found.

Conclusion

We hope that SOC teams will find these new network reputation features useful in detecting threats in their environment. If you are an existing TitaniumCloud and Splunk SOAR customer and would like to use the example playbooks demonstrated in this post, see the playbooks in our Github repository.

Interested in learning more? See the demo for how you can get access to TitaniumCloud for increased SOC efficiency.

Special shoutout to our senior integration engineer Dinko Jakovljevic for making this release happen!

The Power of Complex Binary Analysis

contact@reversinglabs.com (ReversingLabs) — Fri, 03 Nov 2023 13:14:00 GMT

A prism is a fascinating thing. It separates a single stream of light into different wavelengths to make visible different colors. It is a fitting metaphor for ReversingLabs complex binary analysis. It takes in a single entity, a file or software package, and through our own analysis and “refraction,” we can separate out critical insights, making it possible to see malware, tampering, vulnerabilities, exposed secrets, malicious behavior, and more. This is the power of complex binary analysis.

ReversingLabs delivers the industry’s leading complex binary analysis technology, powered by ReversingLabs TitaniumCore. It delivers critical visibility into files, malware, and software necessary to stand up to the most advanced cybersecurity attacks. Capable of digging deeper and providing the unfettered insights necessary for any analyzed file, ReversingLabs delivers the fastest and most comprehensive solutions for automated static analysis of binary files. Proven in the field for over 15 years, the world’s leading cybersecurity enterprises and Fortune 500 partners trust ReversingLabs data analysis to enable their security teams, power their security solutions, and enhance their visibility into the modern threat.

In the evolving cybersecurity landscape, detecting and mitigating threats has become increasingly complex, especially with the rise of sophisticated attacks through software supply chains and advanced obfuscation techniques. Traditional cybersecurity tools often rely on dynamic analysis, executing software in a controlled environment to observe its behavior. While effective in specific scenarios, dynamic analysis is resource intensive, and can be easily evaded using malicious techniques such as time-based payload execution delay methods used within the SolarWinds software supply chain attack.

Traditional tools, including traditional endpoint security and dynamic analysis systems, cannot scale in the face of stealthy, zero-day exploits that can bypass execution-based detection mechanisms. They are often constrained by the need for known signatures or identifiable malicious behaviors without fully parsing or comprehending the file structures, making them less effective against novel or sophisticated attacks embedded in software components.

The need to adopt a robust approach to analyze complex files and detect the most advanced cybersecurity threat in a post compilation, pre-deployment state is clear.

ReversingLabs TitaniumCore delivers the granular and accurate technology critical to scale to these complex threats. It is the heart of a highly scalable and automated complex binary analysis technology, adept at recursively unpacking and extracting threat and risk indicators and classifying files to enhance real-time and high-volume applications. By deconstructing binaries at scale and identifying malicious components before they make it to production, it provides a crucial layer of defense that bolsters the security of software supply chains and addresses a critical blind spot in cybersecurity defenses.

[ Learn how to address the monsters in your software supply chain ]

Analysis Without Detonation or Source Code

ReversingLabs static binary analysis can dissect and scrutinize the binary code without execution and even the need for source code in the case of software analysis. This need becomes more acute considering the surge in open-source software adoption, where binaries often come from disparate and unverified sources, mixed with commercial and proprietary code components in final builds.

High-Speed Analysis of Complex Files

The power of RL’s complex binary analysis is not just in the depth of its analysis but also in its unmatched processing speed, providing a solution for operations of any scale - from a few files to millions of samples daily. File and software size is no limiting factor, with the ability to deconstruct and analyze files up to 100GB with speed and accuracy. Analysis of a 30GB file can take as little as two hours. This scalability and efficiency make complex binary analysis a formidable solution to the challenges posed by the sheer volume of complex files and software components that must be analyzed and deconstructed in today's extensive attack surface - and keep development teams moving at speed.

Deep File Analysis

Our complex binary analysis digs deep into the internal contents of files, recursively unpacking and deobfuscating them to reveal the risks and threats inside. The analysis engine performs high-speed, static analysis to unpack files, extract internal indicators, determine threat levels, and expose vital information for remediation. This high-speed and accurate analysis ensures that hidden threats are accurately identified, delivering an essential layer of security in protecting against complex cyber threats.

Complex Binary Analysis vs. Software Attacks

While specialized tools like SCA help prevent specific issues from making it to the build, they are not designed to address the modern software supply chain attacks and can miss threats introduced later in the pipeline. These classic tools all work together, but software producers need the ability to validate trust and security of their products in the final state that they will be delivered to their customers. ReversingLabs provides that final build exam.

ReversingLabs TitaniumCore can unpack over 400 types of packages and analyze well over 4,800 unique file types. From there, the solution can recursively unpack an application’s components down to the binary elements and scan everything for malicious code, exposed secrets, tampering, suspicious behaviors, and more.

As the enterprise attack surface evolves, the tools we use to defend must also advance. ReversingLabs’ technology transforms the way security professionals approach the deconstruction of complex files, from the software supply chain to malware analysis and threat hunting. Unmatched in size, capability, and accuracy, TitaniumCore is the crucial technology addressing a critical blind spot in cybersecurity defenses and powers the full ReversingLabs suite of solutions.

Learn More About ReversingLabs

ReversingLabs Software Supply Chain Security solution gives developers and application security teams revolutionary new capabilities that legacy secure SDLC solutions cannot provide. Its revolutionary capabilities provide broader visibility into software supply chain risks while automatically suppressing false positive results that are not actionable by developers. ReversingLabs can reveal when software is a malware monster, protecting the developer and its customers from a modern software supply chain attack.

5 best practices for putting SBOMs to work with CI/CD

jaikumar.vijayan@gmail.com (Jaikumar Vijayan) — Wed, 01 Nov 2023 11:30:00 GMT

Software bills of materials (SBOMs) have become a central component of enterprise efforts to secure the software supply chain. President Biden's 2021 Executive Order on Improving the Nation's Cybersecurity, EO 14028, made it a requirement for federal agencies to implement SBOMs when developing software internally or procuring it from external contractors.

Concerns about the transparency and traceability of software supply chains have been driving broad interest in SBOMs in the private sector as well. A survey that Sonatype conducted earlier this year showed that 76% of enterprise organizations in the United States and the United Kingdom maintain SBOMs and that 60% require their software vendors and others they work with to do the same for their software. Other factors driving adoption include broader cybersecurity posture — improvement plans and concerns over software supply chain attacks, the study found.

EO 14028 and related documents focus on requirements to use SBOMs and on the content that SBOMs must include. But making SBOMs useful is tricky in modern development organizations. Here are five best practices for implementing SBOMs in continuous integration/continuous deployment (CI/CD) environments.

[ Learn more about SBOMs | Get a free RL SBOM and supply chain risk analysis ]

1. Automate SBOM generation

The key to operationalizing SBOMs in your CI/CD pipeline is ensuring that they are automatically created with each software build. Multiple tools for generating SBOMs are available that integrate directly into CI/CD tooling. Examples include OWASP Dependency-Check, CycloneDX, and FOSSA.

Choose a tool that is scalable, supports multiple languages, and works with widely accepted data formats. And ensure that the build-time SBOM tools you choose provide a holistic view of what's in the application and cover what customers want enumerated in their SBOMs, said Tom Goings, product consultant at Tanium.

Not all tools do the same thing. OWASP's Dependency-Check, for instance, is a software composition analysis (SCA) tool that analyzes primarily open-source components within a project, identifying dependencies and checking for known vulnerabilities. CycloneDX does the same thing, but for both open-source components and custom or internally developed code.

The SBOM that you provide to customers should provide a comprehensive view of all the off-the-shelf, open-source, and internally developed components, Goings said.

"Build-time SBOMs allow software vendors to provide customers with a complete list of what is in their software when they ship. They are focused on providing details to customers about what is in the application they purchased."
—Tom Goings

2. Ensure your SBOM has the required elements

An SBOM should list all components, including direct and transitive dependencies, libraries, frameworks, and any custom code, open-source code, and/or third-party modules in an application. The list of baseline elements that the National Telecommunications and Information Administration's (NTIA) developed in response to EO 14028 identifies these elements: the name of the component, the component type, the author, the supplier's name, the version string, the unique identifier, and component hash and dependency information.

Get as granular as you need when it comes to including information in an SBOM, advised Michael Mehlberg, CEO of Dark Sky Technology. "Provide a list of all components, source location, version information, and authorship information so that dependencies can be tracked for all dependencies in the entire dependency tree," he said. Storage is cheap and processing power is easily available when it comes to storing and processing SBOMs. So there's no need to shortchange or second guess what to include in an SBOM, he said.

"Generate an SBOM with the most information available, store it with your release, then operationalize it to track things like software license rights, security vulnerabilities, etc."
—Michael Mehlberg

Including data on when during the software lifecycle the SBOM data was collected can also be useful. The NTIA recommends — but does not require — that federal agencies include data on whether, for instance, component data was collected from the software source, or at build time, or via a binary analysis tool. SBOMs can have differences based on when the data was collected, so documenting when, where, and how the data was collected can be useful, the NTIA has noted.

3. Export SBOMs in a standard data format

Using a standard data format for your SBOM is critical to interoperability so that different tools can process it.

The NTIA's Minimum Elements for a Software Bill of Materials document requires federal agencies to generate and consume SBOMs in one of three formats: CycloneDX, Software Package Data eXchange (SPDX), or Software Identification (SWID) tags. Though all three formats can be used to represent SBOM information, each has a slightly different focus and use case. The primary use case for CycloneDX, for instance, is cyber-risk mitigation. With SPDX, the main focus is communicating information on the components, licenses, and copyrights associated with a software package. And SWID is a standard for uniquely identifying software applications and components.

Be sure the format is both human- and machine-readable and can be consumed by the software consumer, Dark Sky's Mehlberg said. "Make sure the format captures the information you are required to capture and deliver to your consumers," he advised. "CycloneDX, SPDX, and SWID are all great SBOM formats but have their own set of data they track, which may or may not be applicable to your software requirements."

4. Ensure your SBOMs' integrity and authenticity

It's important that a software consumer is able to verify the authenticity and integrity of an SBOM and to ensure that the SBOM has not been tampered with during transit or storage. The NTIA recommends that software developers consider using existing mechanisms for integrity and authenticity — such as digital signatures and cryptographic hashes — for providing that assurance. "Those supplying and requesting SBOMs are encouraged to explore options to both sign SBOMs and verify tamper-detection," the NTIA has noted in its guidance on the topic. "Such a mechanism should allow the signing of each component of a given piece of software and allow the user to determine whether the signature is legitimate."

CycloneDX and SPDX both support the inclusion of such information in an SBOM.

5. Keep your SBOMs updated

Component information can change, and new vulnerabilities can emerge in third-party, open-source, and custom-built software. Keeping an SBOM updated is critical to ensure continuous security and compliance with licensing and regulatory requirements. It's not just a nice-to-follow practice, but a required one for U.S. federal agencies. The NTIA requires a new SBOM every time a software component is updated. The requirement applies to every new build or release of software or when a component or dependency in a software build gets updated,

Anthony Tam, manager of security engineering at container security vendor Tigera, which also is the primary maintainer of Calico open-source software, said using an SCA tool to scan your software and its dependencies is a good measure for unearthing vulnerabilities and license issues that might have crept into your software since the last build. "It is important to continually monitor open-source components for new vulnerabilities, as they are constantly evolving," Tam said. "When vulnerabilities have been identified, it is important to prioritize them based on severity and potential impact."

"Prioritization can be done by using a risk-based approach, considering factors such as the likelihood and potential impact of a vulnerability being exploited."
—Anthony Tam

Making SBOMs operational is key

While SBOMs are crucial to securing the software supply chain, they are of little value if an organization doesn't know how to operationalize them fully. Mehlberg said an SBOM tells you what your software is made up of, but it says nothing about what is in it, the trustworthiness of the developers who developed it, the vulnerabilities associated with it, the quality of the code in the packages, or the licenses that could affect you legally. He recommends this routine:

"Get an SBOM. Check it. Track it. Then analyze it for security, trust, and legal risks."
—Michael Mehlberg

Matt Rose, Field CISO at ReversingLabs, said that for SBOMs to be effective, organizations need to adopt the same integration and automation into DevOps for SBOMs as they do with all their other application security testing tooling.

"Without automation and standardization, SBOMs will be out of date and ineffective."
—Matt Rose

IAmReboot: Malicious NuGet packages exploit loophole in MSBuild integrations

karlo.zanki@reversinglabs.com (Karlo Zanki) — Tue, 31 Oct 2023 11:30:00 GMT

ReversingLabs has identified connections between a malicious campaign that was recently discovered and reported by the firm Phylum and several hundred malicious packages published to the NuGet package manager since the beginning of August. The latest discoveries are evidence of what seems to be an ongoing and coordinated campaign.

Furthermore, ReversingLabs research shows how malicious actors are continuously improving their techniques and responding to the disruption of their campaigns. Specifically, threat actors have moved from simple downloaders executing inside install scripts to a more refined approach that exploits NuGet’s MSBuild integrations feature.

An IAmRoot reboot? Revisiting a hidden code execution technique

On October 15, three packages exploiting a previously unseen execution technique were published to the NuGet repository: ZendeskApi.Client.V2, Betalgo.Open.AI, and Forge.Open.AI. These are typosquatting on popular Nuget packages named ZendeskApi.Client, Betalgo.OpenAI and Forge.OpenAI.

Typosquatting attacks are common, as we have reported. But these packages employed an unusual code execution technique that is worth mentioning. Most of the malware published to the NuGet repository places malicious code inside the initialization and post installation PowerShell scripts. These packages use a different approach, with the malicious functionality placed inside the <packageID>.targets file in the “build” directory.

The first NuGet package we detected using this technique for malicious purposes was version 6.5.3 of Pathoschild.Stardew.Mod.Build.Config package. Versions 6.5.1 and 6.5.2 of this package contained malicious functionality in initialization PowerShell scripts, but version 6.5.3 didn’t include them. Instead, the malicious functionality was placed inside the <packageID>.targets file in the “build” directory.

Figure 1: Malicious content inside the Pathoschild.Stardew.Mod.Build.Config.targets file

The code encapsulated inside the <Code> property of this XML file is almost identical to the functionality present in the PowerShell scripts from the earlier two versions of the package. When run, it downloads an executable from a remote location and executes it in a new process. Since we haven’t previously seen malware with the malicious functionality observed in the .targets files, we did a bit of research, which led to some interesting discoveries.

First, the string artifact in the first line of the file, “IAmRootDemo” led us to the root of this execution technique. Several years ago, in 2019, the IAmRoot package was published by C. Augusto Proiete. The purpose of the package: “To demonstrate that any NuGet package can run arbitrary code on your machine.”

IAmRoot uses MSBuild integrations, which were added in NuGet v2.5 to improve the support for native projects, to achieve execution. How does it function? As described in the NuGet release notes: “When NuGet installs a package with \build files, it will add an MSBuild <Import> element in the project file pointing to the .targets and .props files.”

The sneaky part is that MSBuild files can include inline tasks, which can contain executable code. Imagine you are developing package A and you want your package to use package B. Package B contains a .targets file with an inline task containing executable code. When you add package B to your package A, the content of .targets file from package B gets imported into the project file of package A. From that moment on, every time package A is built, inline tasks from the imported .targets file will get executed. There has been an ongoing discussion about the security implications of such mechanisms in NuGet’s GitHub repository, but the issue hasn’t been resolved.

We’re now dealing with the consequences of that. Based on our research, this is the first known example of malware published to the NuGet repository exploiting this inline tasks feature to execute malware.

Based on our research, this is the first known example of malware published to the NuGet repository exploiting this inline tasks feature to execute malware.

Figure 2: Utilizing MSBuild integrations to execute malicious code in NuGet packages

All in the (malware) family

The three previously mentioned packages — ZendeskApi.Client.V2, Betalgo.Open.AI, Forge.Open.AI — are clearly part of the same ongoing campaign, started in August, and are very similar to the Pathoschild.Stardew.Mod.Build.Config package. They contain almost identical functionality in the .targets file (Figure 1), except that the obfuscated stage 2 payload is in the latest case downloaded from a GitHub repository and not from an attacker controlled IP address.

The malware authors also tried to make the malicious code harder to spot by using spaces and tabs to move it outside of the content visible within the default screen width. (ReversingLabs researcher Lucija Valentić observed a similar technique used in campaign on the Python Package Index (PyPI) in February.) They also inflated the download count numbers to make the package look more trustworthy, as evidenced by the vast majority of package downloads being attributed to an “unknown” client, versus some version of the NuGet client.

The malicious NuGet packages were detected by ReversingLabs within less than 24 hours of being published and were reported to the NuGet security team and removed shortly after preventing a more severe impact of the campaign. This discovery has been linked to a previous campaign which utilized init.ps1 scripts to achieve code execution.

One week later on Sunday, October 22, we observed malicious actors preparing to publish another set of malicious NuGet packages. Threat actors created several packages and published two versions that contained benign code in the .targets file that writes a simple message to the console.

Figure 3: Version stats for one of the malicious packages

The next day, downloads for the package were pumped up to make package statistics look more trustworthy. Then, on October 24, the malicious versions of the packages were finally published. They contained the same downloader functionality, fetching the stage 2 malware payload from the newly created, throwaway GitHub repository. This time, the Stage 2 malware was a .NET executable which executes an obfuscated command line embedded as a resource.

Figure 4: Newly created, throwaway GitHub account

The packages published in this group imitated popular packages published by the following NuGet publishers: CDataSoftware, ServiceTitan, cloudextend-oss and syntellect. These typosquatting attacks were very convincing, using the same icons for packages and package names that differed by only a single dot. Such decoy packages would be difficult for a developer to identify without close inspection of the packages to spot these subtle differences (Figure 5).

Figure 5: Search results displaying an legitimate (top) and malicious, typo-squatted package

This is more proof that the threat actor behind this campaign is being careful and paying attention to details, and is determined to keep this malicious campaign alive and active.

Round up the usual code execution techniques!

As noted, the latest packages have strong links to a campaign described in a recent research blog post published by Phylum on October 6. That research described a typosquatting campaign delivering SeroXen RAT. In that campaign, the malware used a well-known execution technique that was also observed in a campaign distributing the Impala Stealer and reported by JFrog in March, 2023.

In both cases downloader functionality was placed into PowerShell scripts located inside the “tools” directory of the NuGet package. This included init.ps1, install.ps1 and uninstall.ps1 scripts, which are run on certain events including installation and uninstallation of a package, depending on the version of the Visual Studio. These scripts are deprecated by newer versions of the NuGet format, but Visual Studio still executes the content inside the init.ps1 script upon installation of a NuGet package, regardless of whether it is specified in the .nuspec file.

This autorun mechanism is quite a popular technique for code execution in NuGet packages and the packages Phylum reported are a part of a broader, previously unreported campaign started in August 2023. This campaign was quite noisy, and included more than 700 packages which were quickly detected and removed from the NuGet repository. They very likely didn’t have a big impact. The packages detected by Phylum weren’t very sophisticated and contained only the basic files required to satisfy NuGet requirements. Even the name of the .nuspec file didn’t conform with NuGet package ID naming convention, making it easier to spot.

Figure 6: Content of the malicious Nughettt.TestPO package published in August

The malicious functionality was fairly simple. It was located in the tools/init.ps1 script and downloaded a stage 2 payload from a remote location and executed it afterwards.

Figure 7: Content of the init.ps1 script from one of the detected packages

The first package published as a part of that campaign was Nughettt.TestPO, published on August 1st. There were several connections between the 700 packages published in August and the packages from Phylum’s report. The first one is the comment “# IGBOAT Crew” detected in the code from both groups of packages. More proof of this was found in the fafagewg.nuspec file, which is located in the Nughettt.TestPO package and also in some of the packages published by the author Disti, mentioned in Phylum’s report.

Additionally, a package named Pathoschild.Stardew.Mod.BuildConfig, almost identically named as the Pathoschild.Stardew.Mod.Build.Config (different in only one ‘.’) package from Phylum’s report, contained the same payload as the initial Nughettt.TestPO package, further proving that all of these packages are part of the same campaign.

Discussion

Previous research reports from ReversingLabs have warned about security threats in the npm, PyPI and RubyGEMS ecosystems. This newest finding adds the NuGet package repository to that list, and proves that NuGet is equally exposed to malicious activities conducted by threat actors.

Specifically, this research report describes an ongoing campaign which has been targeting the NuGet repository since August 2023. The threat actors behind it are tenacious in their desire to plant malware into the NuGet repository, and to continuously publish new malicious packages. As soon as the previous packages are removed from the repository, ReversingLabs detected newly published packages on a daily basis.

The new malware samples ReversingLabs detected suggest that the malicious actors responsible for this campaign are adopting a documented but uncommon technique that exploits NuGet’s MSBuild integrations feature in order to plant malicious code on their victims. As always, developers need to remain vigilant of the threats lurking in the open source ecosystem.

What's needed is deep visibility inside software packages, to distinguish malicious functions from legitimate ones. This can be challenging with legacy application security testing tools, and demands specialized skills and knowledge that many organizations lack. Modern tools like ReversingLabs Software Supply Chain Security can bridge the gaps, and help development and application security teams protect their supply chain from compromise.

Indicators of Compromise (IOCs)

NuGet packages:

package_name	version	SHA1
Pathoschild.Stardew.Mod.Build.Config	6.5.1	f474da140a91aca8eb75084b8af0580a2a5f9f9c
Pathoschild.Stardew.Mod.Build.Config	6.5.2	d716dda6b465e16222287f1973454fc6daa62c66
Pathoschild.Stardew.Mod.Build.Config	6.5.3	c6f7dc7f9e2a5447f966f582d4fe41869ee07275
KucoinExchange.Net	5.0.1	48dfbe8ceb801a556255841e1270bd1f55132572
KucoinExchange.Net	5.0.2	a45b7b2f73864dcc50993cab9465081f6974094b
KucoinExchange.Net	5.0.3	6ee07eb39946ce546f7a96645affa12e568c47ab
Kraken.Exchange	4.1.1	f1b54fa7dc92998d82f7453f7c41e31d86288c18
Kraken.Exchange	4.1.2	2d81de5fe1c88cd5b732deb04e449d13ce60072e
Kraken.Exchange	4.1.3	d056eb9d74c250b337be8b239dfdef55ef78d56a
DiscordsRpc	2.3.4.41	109c09147586389ba45b7761fd83ec88841e4d59
DiscordsRpc	2.3.4.42	9e59ca377199ddd839de785cf2dff73aa6670144
DiscordsRpc	2.3.4.43	23f2faf65e8b0d024a1f9cca80c42c56c62e8184
DiscordsRpc	2.3.4.44	c4b2077af263b72b9e90c815b13e505fe2026e47
DiscordsRpc	2.3.4.45	68ae280dd3c7b0caa0f5aac3128fc924cc24ab32
SolanaWallet	1.25.1	2a09ef73b8e6e28ffee0aa2daf9e8a1905d389f4
SolanaWallet	1.25.2	40145b10a331be75a7d77577f4577e83e81117a6
SolanaWallet	1.25.3	b7dadebdd6c4b4c978a733fb1ae31857896701ad
SolanaWallet	1.25.4	a405145005cee5823de3531f4c66631d7c4e0033
SolanaWallet	1.25.5	5f7f882c59e31e7d83129d0a09579b47fd931be0
SolanaWallet	1.25.6	8ab0b3b437fa3aaecd89eaa4681d56eb4990cb06
Monero	2.3.4.41	679875b3bc415fb81f83919f7ecc6f226b372dde
Monero	2.3.4.42	1d72719509f2f2a6852bb001ad6b52a38489c09d
xopxopxopxopxopx	1.4.0.2	0706311de6caa47ee4febb54e8aa7e57290281d2
Modern.Winform.UI	1.4.0.1	b548221b4fadcf00bde6567eea11189e0719a812
Modern.Winform.UI	1.4.0.2	e7d54ba61fe291d8ea862ce7a23b9c3cd8e8f988
Modern.Winform.UI	1.4.0.3	64d257ba67db909446007944fe8d4c145c3b4f03
Modern.Winform.UI	1.4.0.4	39f5dfd63237530abe5d1e8f418f739992d0d766
Modern.Winform.UI	1.4.0.5	708e16fee69655dd0ee0ee60220c6395779b0070
Modern.Winform.UI	1.4.0.6	dcfb36931677d0860e62552e35f1d67a5d77e2a1
MinecraftPocket.Server	1.0.2305	4bf3e03363d0e59051d22fdd2e498c02dfb19dd0
CodeExecTest	2.0.0	c03b21f48cf80e5cd9ee89e254d6327d74f5c8fb
IAmRootx	2.0.0	45d715d7597cfaa043b7532efc71f69209d15a51
IAmRootx	2.0.1	f182a3c99fc568d4ebcf22fd7d558d93bd00c7c7
IAmRoot	0.0.1-beta	14af9c50437f4894a44325a6dd45f12ea52c8247
IAmRoot	1.0.0	ae9fd408f32bddddd54329e641984ce7e2ca4310
IAmRoot	1.1.0	2b76e606281d33cb88de47e68a9e456a7c03ab8b
IAmRoot	1.1.3	0c050ea1afbe29f1c4126b778d8ea640f15a9301
IAmRoot	1.1.1	69738f031300662f2cfc034b3f290953918c467b
IAmRoot	1.1.2	de67e07596ccfb2257675b8d4d1d092a86d8d855
IAmRoot	2.0.0	fa7063ab77cc0bc40ebaef5716024174a2d8dbef
ZendeskApi.Client.V2	5.0.6	62f6a2715a379468bbc38b28066e7bda2137fd98
ZendeskApi.Client.V2	5.0.7	d72534b14f5fedcdca0629367f9b93af92bd6bd5
ZendeskApi.Client.V2	5.0.8	bae28ac375dc5b89d0be371f0d4421abe17bde84
ZendeskApi.Client.V2	5.0.9	8950d150f8f7ad70accb928e792e114bfdb22719
ZendeskApi.Client.V2	6.0.0	8a1d7189b2e4547ab730397fe1e95898474c1f41
Betalgo.Open.AI	7.1.8	d9e517e2dc0f54c99727a0f17df9b241a2a1aabc
Betalgo.Open.AI	7.1.9	75361acfb735c1c46f073b7142d66cc944f37bef
Betalgo.Open.AI	7.2.0	ec5bd0c43eef8a94b340e64cf6e649d65b9a9d90
Forge.Open.AI	1.1.3	d18e6074b797bcf80d0a203fc9c278eeaded44b9
Forge.Open.AI	1.1.4	d46c0641697e18011bd084cb62110ffc394b9ae8
Forge.Open.AI	1.1.5	3ffe89ee4b7a3cb9184ffe84aa0279c91b5b8dca
Forge.Open.AI	1.1.6	c0f04c7b015cff331921b7996f66a762a430e76a
Nughettt.TestPO	1.0.0	a11ac467846b4e3e541b74d6d59ec8d5e6fcbb6f
Pathoschild.Stardew.Mod.BuildConfig	6.2.1	ff0990ce50448be5f19c89d4ac2d18714facb566
Pathoschild.Stardew.Mod.BuildConfig	6.2.2	0f88db4448334cf5bb75542a955475f42dca004d
Pathoschild.Stardew.Mod.BuildConfig	6.2.3	1044dc4fccab73c8d238b5d4505adc67b977dcb4
Pathoschild.Stardew.Mod.BuildConfig	6.2.4	f1ccafe37c8b84f83d1954b9ae438d7cf0eec42a
Pathoschild.Stardew.Mod.BuildConfig	6.2.5	853254467e9667efab60ed800f0a5021232a8c83
Pathoschild.Stardew.Mod.BuildConfig	6.2.6	a4c3569b076113b4d1258c7210cb3c5a242659cc
Pathoschild.Stardew.Mod.BuildConfig	6.2.7	c6ff26c0670806aa80d7f1d5bc7d662b263b1124
Pathoschild.Stardew.Mod.BuildConfig	6.2.8	d81a7608a97b44af04157dd9086c4e2e46c93369
Pathoschild.Stardew.Mod.BuildConfig	6.2.9	9cfb17c19ea29dba6a4dfb4281633660c74f6cf0
Pathoschild.Stardew.Mod.BuildConfig	6.3.1	993d0f3594b217573b504d5f190670d480d386b9
Pathoschild.Stardew.Mod.BuildConfig	6.5.1	f5e8e315fc6a0cd7cb452859e492ed45da6c932f
CData.NetSuite.Net.Framework	23.0.8669	247ad37694ea0eaaf93ee9eaffda22703b0653b4
CData.NetSuite.Net.Framework	23.0.8670	1c03781c4033d160dabe18bcc38504ef21eb56a8
CData.NetSuite.Net.Framework	23.0.8671	9490bf38a151fc0f3b99d940bb04359792862e95
CData.Salesforce.Net.Framework	23.0.8669	fae0697f55d9244980bffdf65216f98961153953
CData.Salesforce.Net.Framework	23.0.8670	b4e6deceabaef67d64865cbe6197397dec420a86
CData.Salesforce.Net.Framework	23.0.8671	ff9d0e9f91e9837069c302539747fd1a1f2140c3
CData.Snowflake.API	23.0.8669	fdc40bf0a0b372358767670e7b9e518c8208962d
CData.Snowflake.API	23.0.8670	b6a2589eade5649b6ad41237a38d1547634a4148
CData.Snowflake.API	23.0.8671	79c52e34bdbbe00fb54f3c78817223436596b1c4
CData.Snowflake.EntityFramework.Net	23.0.8669	f30b9cb625fde948fc00724a370a4420e1426732
CData.Snowflake.EntityFramework.Net	23.0.8670	03d5532e39357ec0422614a7913e2a426beb0730
CData.Snowflake.EntityFramework.Net	23.0.8671	1ccec9016788bdacae3635eab81a322258f314a9
Chronos.Contracts.Net	3.6.0.16	12dbb19aa8059f0c73a689db48bc86dcff757d3d
Chronos.Platform.Linux.API	3.6.0.16	1d369efe94859986f549ae0ecde92750fd3e147f
Chronos.Platforms	3.6.0.16	7026a7f2b50bd4999927b59e58a18601891ecfc6
LazyProxy.Unity.Net	1.0.2	e33ec6d268711f7b882c00c568002c27ef995bfc
Stl.Blazor.Authentication.Net	6.5.8	47896d0cf5c8d10bd03b57d1d1f5005b1f67cdd9
Stl.Blazor.Authentication.Net	6.5.9	2cab3c7e4781bd5f0e35d40c4382ad0ebad3ebb4
Stl.CommandLine.Net	0.2.22	c6d6e5f66f50793bee955a6abd3ece7a1e0c3eac
Stl.CommandLine.Net	0.2.23	519767ceb3af15336f8ecfcc09d5ba9237a9ff9d
Stl.Fusion.Ext.Contracts.Net	6.5.8	cdda2b33879b3e2d028b3099cc7e885501c8e00d
Stl.Fusion.Ext.Contracts.Net	6.5.9	7987192d807124f8a4c5c45399dff7b77349a6cb
Stl.Fusion.Ext.Services.Net	6.5.8	1bb64c3b078440c7bf7f3130bfa1e0f64fb56e71
Stl.Fusion.Ext.Services.Net	6.5.9	5702153b0b44071d916f099d75155f1867d80e4a
Stl.Generators.Net	6.5.8	8123f5fab4cc5acfaee5f419b1efba52a69ac456
Stl.Generators.Net	6.5.9	d959ac811872fde62386725456a937b943e236ee
Stl.Plugins.Extensions.Net	0.2.22	96aa8d35910118e51eb962c5b6a5f64e9c3f8f99
Stl.Plugins.Extensions.Net	0.2.23	0170734a8a42976aa20cbc09e999433c1aabed9b
Stl.RestEase.Net	6.5.8	2a22fa4277644bf07a4b92575248cf4b931e8614
Stl.RestEase.Net	6.5.9	f0220fdc65fe5a4be3cf67b9d2eea44c79473117
Stl.Rpc.Server.Core	6.5.8	72fe525e541fca4b7766d05bd0d0162c32002fa1
Stl.Rpc.Server.Core	6.5.9	95ec7567218829bc95d4b10d546186116b477ad8
Stl.Rpc.Server.Net.Fx	6.5.8	922bb97ba1bff39324f79daf305fb021bf42246c
Stl.Rpc.Server.Net.Fx	6.5.9	3fc3056ac2736278aa11c8deaad012d9a8e9de3b
Syntellect.Winium.Cruciatus.Net	3.1.0	34f7c52873404ca899733d95899c5b8cf1d76db6
Syntellect.Winium.Element	0.2.1	d014e8287dd2430386cadeb5fcea324dff82ce10
Syntellect.Winium.Web.Driver	0.1.2	fe30654a7947c337a6718679df8ee436da7f8e0e
Tessa.Analyzer	3.6.0.16	c19e63c685b85bc50b0bc6a8124f19d1c3d4a0f0
Tessa.Compilations	3.4.0	1ddff92c47b04502fe2d5a6e0a87545cc8e4df54
Tessa.Core	3.6.0.16	390afcb6201d1d6ef85dbac9ca472d7f3d19628b
Tessa.Linux.V2	3.6.0.16	28985a918ff7b537daa912c49d7f907e6e82a104
Tessa.Net.V2	3.6.0.16	e5225a52fa7ca6f5f2581bbb6db54a0ae9e5d529
Tessa.Postgre.Sql	3.6.0.16	ac9043342bfcab56689bff96bd5d8a03ba7c37c4
Tessa.Server.Net	3.6.0.16	00d153ba2f6bbe0be3c67096565f07ce66cbe2e8
Tessa.UI2	3.6.0.16	c11f384c065a51871155a1a59e77f69d49daad15
Tessa.Web.Client.Net	3.6.0.16	7e4b02793685f3835231c46ea60c767c84b13366
Tessa.Web.Core	3.6.0.16	b604a24356f337f9d6806bc328d9980ea7020eed
Tessa.Windows.V2	3.4.0	11ebf1f7a6c974915ac1575bbcc13d26ca8baa0f
Celigo.Service.Manager.NetSuite	7.1.2	16d256f3daf8982ea5a3d7cb469dfd824b5f4f9c
Celigo.Service.Manager.NetSuite.REST	1.3.1	d64b2da8fcc14c51d707acebbd4ebcf93eb55fd9
Celigo.Suite.Talk	7.1.2	d2832302dc687e260354be8143c69fc90144dc9b
DistributedLocks.AzureStorage.Net	1.0.2	dfbb6853f84d78f989deba3235cef26f51fd4d70
EBBuildClient.Net	1.0.92	5409be191e8cec6edaf111a5481b62ecd80205c7
LagoVista.CloudStorage.Net	3.0.2287.946	1f3f9b4188ecf54a997a7d51ec8e21dbd3165df5
OCI.DotNetSDK.Ai.speech	73.0.0	ed6e7868bfab896663c91a4b242dac93943c2d19
OCI.DotNetSDK.Ai.vision	73.0.0	db57c5769ac4997c6d6cc06009b0c19864cd6886
OCI.DotNetSDK.Apm.config	73.0.0	5798a6be7106029a2f6fca860dbfd96e3caa601d
OCI.DotNetSDK.Appmgmtcontrol.Net	73.0.0	7fbcfa699b56e55d2089294a1edd61cd55cbae61
OCI.DotNetSDK.Certificates.Net	73.0.0	f3dd64b8314afab0d47f0859c6346b97670514b1
OCI.DotNetSDK.Certificatesmanagement.Net	73.0.0	194e0a759a52371c69af70ff98dd0d25ec44e69f
OCI.DotNetSDK.Dashboard.service	73.0.0	83f9fb69c198e24ae67f67871269b088053285c0
OCI.DotNetSDK.Databasetools.Net	73.0.0	73e8cf24d205e6800a448f292cb90dd845f109f8
OCI.DotNetSDK.Datalabeling.service	73.0.0	d05d1aa8f90e145cda664a3b8823482c1e0a0e92
OCI.DotNetSDK.File.storage	73.0.0	67508b2a6cfa6532994e30f8924a1f2566c32f20
OCI.DotNetSDK.Net	73.0.0	fabac069323a7521c37052c55c2abb0a7c28ee0a
OCI.DotNetSDK.Ospgateway.Net	73.0.0	250091edab3a9ec2f5d207b174677900f874aaad
OCI.DotNetSDK.Osubbillingschedule.Net	73.0.0	d52d9ad3a258ac47b33c58320303f65e0a366cd3
OCI.DotNetSDK.Osuborganizationsubscription.Net	73.0.0	dd00638e3a9201d645d96a97d0ebe58b73da5fef
OCI.DotNetSDK.Osubsubscription.Net	73.0.0	413c8f589aea0a1295f0dfb481f741eb3d7aa744
OCI.DotNetSDK.Osubusage.Net	73.0.0	50e5192337e5b8df41a31bc8daead884e7838d82
OCI.DotNetSDK.Servicemanager.proxy	73.0.0	f1acc14265a44ea98d5539885329e36a9c8bbd5b
OCI.DotNetSDK.Threat.intelligence	73.0.0	9f57f74b0d586c74c3602de6ef404b76997d4785
OCI.DotNetSDK.Usage.Net	73.0.0	f9549c90de2134e2540aa44a043ed61fa202f9e5
OCI.DotNetSDK.Visualbuilder.Net	73.0.0	0979601ec510bf0c48563a63391a941fa62133b3
OCI.DotNetSDK.Waf.Net	73.0.0	e54ec3cbc36f4ee0832aa231df2de893d4329546

How mature is your open-source risk management? S2C2F helps map out dependencies

jaikumar.vijayan@gmail.com (Jaikumar Vijayan) — Thu, 26 Oct 2023 11:30:00 GMT

The Secure Supply Chain Consumption Framework (S2C2F) from the Open Source Security Foundation (OpenSSF) is a useful resource for enterprise software teams addressing risks from open-source dependencies.

The framework provides a structured list of guidelines and best practices to protect development organizations from consuming vulnerable and compromised open-source software (OSS) components. It enumerates real-world open-source risks and recommends processes for identifying, evaluating, and monitoring them throughout the software development lifecycle (SDLC).

Microsoft developed the framework and used it for several years before turning it over to the OpenSSF to manage. Here's what you need to know about the S2C2F's strength in mapping out OSS risk. But there is one key caveat: Remediation of OSS risk is left to organizations to work out.

[ Join November 14 Webinar: Secure by Design - Why Trust Matters for Software Risk Management ]

8 focus areas and 4 maturity levels are key

The recommendations are built around eight focus areas: ingest, inventory, update, enforce, audit, scan, rebuild, and fix+upstream. The S2C2F spells out requirements for each of the focus areas that organizations can implement to improve security processes in that area. The requirements, which range from the basic to the aspirational, are organized into four maturity levels.

By using the eight practices and four levels of the S2C2F, organizations have a road map to tell them where they are now and where they need to go. Matt Rose, field CISO at ReversingLabs, said the practices are a clear and concise explanation of where to do certain activities with OSS workflows to mitigate risks

"It is basically like having Google Maps for mitigation of OSS threats. Without it, there is a ton of confusion on what to do when and where."
—Matt Rose

S2C2F and SLSA work hand in hand

The S2C2F is primarily consumer-focused, unlike another framework for open-source security, Secure Software Supply Chain Levels for Artifacts (SLSA), which is focused primarily on software producers. The two, however, are complementary. While SLSA focuses on progressive levels of security for artifacts such as source code, the S2C2F recommends best practices for OSS consumers to address risks. OpenSSF noted last year about the collaborative work:

"One of its primary strengths, and why we were so excited to adopt it into the OpenSSF, is how well it pairs with any producer-focused framework such as SLSA. For example, S2C2F’s Level 3 requirement for provenance of all dependency artifacts can be achieved through generated artifact provenance in such a manner deemed trustworthy through SLSA."

S2C2F enables an incremental approach

Because each S2C2F requirement maps to a specific maturity level, organizations have an opportunity to take an incremental approach to securing their open-source supply chain. For instance, requirements for Level 1 on the S2C2F scale include the ability for organizations to use package managers to automate the tracking and updating of open-source components, to maintain an inventory of their open software, and to scan them for vulnerabilities.

Organizations at Level 2 of the S2C2F maturity scale have technology for improving mean time to vulnerability remediation. At Level 3, the focus is on preventive controls and proactive code analysis to reduce risk from compromised or malicious open-source software. Organizations at the highest S2C2F maturity level (Level 4) have controls that can help mitigate against the most sophisticated attacks.

As the OpenSSF describes it, Level 1 requirements are fundamentally basic and include practices that many organizations have already implemented, while Level 4 requirements are challenging to implement and likely aspirational for most organizations today.

Getting proactive with app sec is key

Callie Guenther, senior manager of cyberthreat research at cyber-risk monitoring firm Critical Start, said the S2C2F is designed to offer organizations a systematic approach to enhance the visibility of their open-source security posture.

"By emphasizing the importance of utilizing package managers and continuously inventorying OSS at its initial level, the framework provides a foundation for clear visibility into OSS components in use."
—Callie Guenther

As organizations progress through the levels, the S2C2F guides them to integrate more proactive security measures such as verifying the provenance of dependency artifacts, which can enable deeper insights into the origin and integrity of OSS components, Guenther said.

The inclusion of requirements to bolster mean time to remediate vulnerabilities ensures that organizations can react swiftly to emerging security threats, Guenther said. Other requirements at the higher maturity levels — such as those focused on prevention and proactive risk analysis — mitigate against accidental consumption of malicious and compromised OSS components.

"This proactive stance ensures security checks are ingrained in the workflow even before OSS consumption takes place. For projects of paramount importance, Level 4 ushers in advanced controls that serve to protect against sophisticated adversaries."
—Callie Guenther

John Gallagher, vice president of Viakoo Labs, said that with the S2C2F, the OpenSSF has given organizations a comprehensive framework to assess their maturity when it comes to open-source software. Having a maturity-model approach is critically important, especially when different parts of the organization are at different levels of maturity with open-source software, he said.

"A good example of this is with how organizations may be at a high level of maturity with their core IT systems, but are relatively immature when it comes to IoT security."
—John Gallagher

Why software integrity verification matters

As with all frameworks, development organizations need to implement the S2C2F in a manner that is consistent with how they consume open-source components and how they develop applications, ReversingLabs' Rose said.

"S2C2F is a great way for organizations to initiate a threat-based risk-reduction approach. However, it is just a framework to base your program on. It does not actually do the scanning or remediation of the threats. So more granular tooling is also needed."
—Matt Rose

There's also the issue of verifying that software built with open-source components behaves in the manner intended. This is especially important when performing supplier and third-party assessments. Organizations cannot rely on a software producer's assurance that its software is secure; binary analysis of the actual software deployable is very important for commercial and third-party software assessments, Rose said.

"That's because when you analyze a binary, you get a view of the entire application and not just a piece of the application. Binary code analysis is basically the final exam for all your software development processes, to ensure that the software you are developing is free from threats."
—Matt Rose

John Bambenek, principal threat hunter at Netenrich, said context is important for organizations evaluating the S2C2F. At present, the framework remains an early-stage effort. It provides guidance and principles to organizations looking to address their third-party open-source supply chain risks, but that's not a comprehensive approach.

"It’s built around eight practices and drives requirements from there. Therefore, it remains a little high-level for most organizations that can’t fill in the blanks on their own."
—John Bambenek

App sec prioritization is priority No. 1 for CISOs

ericka@chickowski.com (Ericka Chickowski) — Wed, 25 Oct 2023 12:00:00 GMT

As application security and DevSecOps teams try to get the most bang for their app sec buck, one of the perennial problems has been figuring out where to focus their secure coding and vulnerability remediation efforts.

The scale of vulnerabilities that must be chased down in each application and the extent of the code that stretches across a typical enterprise portfolio of applications (and the enterprise's attendant software supply chain) make deciding on even the first step of prioritization a complex affair.

For the better part of a year, app sec veteran Mark Curphey and his business partner John Viega, who have depth of experience in the app sec space, heard variations on this complaint time and again. Curphey founded OWASP and had a hand in founding the companies OpenRaven and SourceClear, acquired by Veracode. Viega founded Secure Software, which developed the app sec testing tool Fortify, bought by Hewlett-Packard.

Before launching their next venture, Curphey and Viega went on a listening tour with top CISOs to get at their biggest app sec pain points. Here is what they learned in those conversations.

[ Join Nov. 14 Webinar: Secure by Design: Why Trust Matters | Learn more: Software Supply Chain Risk Report ]

Scan-and-fix is noisy and time-consuming

Curphey and Viega found general agreement that app sec leaders and their CISO bosses are faced with more and more noise as the complexity of scan-and-fix keeps rising.

"We sat down with about 100 CSOs and we basically said, 'We're going to do an app sec company, so that's the scope, but within that what's your biggest unsolved problem?' And what we heard very consistently was, 'We've got all the money in the world. We've got all the tools in the world. We can hire people. But we have massive amounts of noise, so we don't know what we should work on.'"

One recent study bolsters this point. In the survey, conducted among 300 security professionals by Backslash Security, 85% of respondents see being able to differentiate between real app sec risks and noise as critical to their success, but only 38% of them think their organization is able to do that. The biggest problem with their app sec tools? Almost half of the respondents (45%) said it was prioritizing findings, which takes a considerable amount of time given that they are "pretty noisy."

Curphey said that one CSO on their tour summed it up with a simple formulation:

"He said, 'If you could tell me what to work on now, next, or never, I'd write you a check right now.'"

The context gap

At many companies, security teams often run their tools on a piece of code without knowing whether that code is deployed in production, whether it has security fixes waiting to be deployed, and whether it is touching personally identifiable information (PII) or running critical business processes.

"All they have is this kind of myopic view of vulnerabilities."
—Mark Curphey

For many years, the only context available to organizations has been the criticality of vulnerabilities, but leaders seeking to prioritize their app sec efforts to gain better context about vulnerabilities — how they're deployed in the application stack, what kind of traffic is running through them, and how the application is used by the business. Curphey cited a game company he learned about during the tour.

"They have 6,300 repos, and they have no clue how many are in production. So they're scanning, and they're asking the developers to update the libraries in all 6,300. It's just noise. They don't need to be doing it. They don't know which ones are deployed into production, which ones have the highest traffic, or which one is touching PII."
—Mark Curphey

How to kill noise

Of all the contexts, knowing what is in production is one of the best ways to kill noise, the security leaders told Curphey.

"I think everyone historically — me included with SourceClear — focused on vulnerable libraries, and absolutely they are a problem. But the reality is that most of the vulnerable libraries never get put into production, so therefore it is just noise. You don't actually have to deal with it."
—Mark Curphey

The point was brought home by the CISO of a large financial services company.

"They didn't know what repos were in production but they knew the vast majority weren't, so they told me, 'The first thing we'd like to do before we do anything is just kill the noise at the source so that we don't have to figure out deduping and all of that other stuff.' Their take was, 'I can get rid of 95% of the problems right off the bat with that knowledge.'"
—Mark Curphey

Most SBOM efforts are still busywork

The general consensus from the listening tour on White House Executive Order 14028 on software bills of material (SBOMs) was that it is creating busywork for CISOs.

"You can generate one with your tool, but it's basically like writing your own doctor's certificate and signing it off yourself. It's totally easy to fake. Then, if you have one that happens at the build system, it is usually completely different than the one that's in the code repo and different from the one that runs in production, where you have hot loading and things like that."
—Mark Curphey

SBOMs are useful when you have attestation "and you have confidence that this SBOM is generated here, that one there, and so on," Curphey said. He explained that the fire drill of Log4j showed weakness in the narrative about SBOM usefulness.

"Most people sent folks around with clipboards trying to find out where it was. And even when it was in production, they found it was in test directories where it wasn't being called into production. They spent all of this time, shut down dev teams, and I think there's scar tissue for a lot of CISOs, who are saying, 'We can't rely on a lot of this. We can use [SBOMs] to help feed things, but ultimately they're not a source of truth."

From tour to open-source tool

Many of the observations from Curphey and Viega's tour have been folded into what Crash Override is doing with the release of its open-source security tool, Chalk, which collects metadata from build artifacts to provide queryable graphs that can help app sec teams get visibility into what part of a codebase is in production, as well as the context of how things are deployed.

GitHub boosts secrets scanning: A necessary step, but supply chain security is key to managing risk

jpmellojr@gmail.com (John P. Mello Jr.) — Tue, 24 Oct 2023 11:30:00 GMT

Credentials leaks are a major threat to supply chain security. In the hands of an adversary, application development secrets will open the door to a host of attack strategies. The CircleCI hack made this crystal clear for software supply chain risk management.

Many potential leaks can be discovered through scanning software repositories. GitHub recognized that earlier this year when it began offering secrets scanning free on the public repositories that it hosts. But scanning can create its own problems, especially when it comes to remediation of scanning results.

A key to remediation is determining whether tokens — which are used for things such as pushing and pulling code, creating and managing repositories, and opening and closing issues — are active or not, a process that can be ornery and time-consuming. GitHub is tackling that problem with its validity checks feature.

Validity checks remove a lot of the manual effort and friction from the remediation process. A token’s status can be seen within the UI, saving time and allowing remediation tasks to be prioritized so they can be performed more efficiently. That's especially useful when scanning produces hundreds or even thousands of alerts.

With its latest secrets security enhancement, GitHub is extending validity checks to select tokens on other platforms, namely Amazon's AWS, Microsoft, Google, and Slack. "These account for some of the most common types of secrets detected across repositories on GitHub," the platform's senior product marketing manager, Zain Malik, and senior product manager, Courtney Claessens, wrote in a blog post.

GitHub's secrets-scanning efforts are a step in the right direction and will help development teams reduce some secrets leaks. But managing the risk from secrets leaks is bigger than that — and requires a holistic software supply chain security approach.

[ See Special Report: An Essential Guide to Securing Secrets in Software ]

The importance of enhanced secrets scanning

There are many ways for software teams to leak development secrets, and many places to do so. So it's valuable for organizations to be able to scan as many places as they can, said Justin Cappos, a professor in the computer science and engineering department at NYU's Tandon School of Engineering.

"It's really good that [GitHub's] effort is looking in a broader way to secure the ecosystem of credentials API tokens and similar things."
—Justin Cappos

John Bambenek, a principal threat hunter at Netenrich, said such scanning has become increasingly important as organizations become more dependent on cloud services. “Traditional perimeter defenses and other security tools just aren’t available. “When you are talking APIs, it’s not even possible to deploy MFA [multifactor authentication].”

“Lost secrets give adversaries worldwide immediate access to your cloud data and services, and it requires minimal skills to scan repositories to find them."
—John Bambenek

Philip George, executive technical strategist at Merlin Cyber, said GitHub’s extension of its security tools into popular cloud environments is welcome, what "with the growing amount of private and public sector organizations migrating workloads into the cloud."

“CI/CD pipelines will adjust accordingly and take advantage of the cloud's programmable infrastructure, which presents an even greater attack surface and overall risk of threat actors exploiting vulnerabilities posed by inadequate secrets management. However, choosing to extend validity checks and static cryptographic scanning tools across cloud service provider environments can be an effective way to manage this risk.”
—Philip George

One key problem with secrets scanning: Alert fatigue

As important as scanning has become, it often produces an avalanche of alerts. When security alerts become too noisy, legitimate alerts get lost — or worse, or they get ignored, Bambenek said.

“Rapid triaging to remove false positives is essential to prevent analysts from developing muscle memory in bulk closing tickets without sufficient thought."
—John Bambenek

Such scans are known for creating false positives, but Tandon School of Engineering's Cappos said GitHub is “pretty good” at avoiding them. However, while things like credit card numbers are more easily identified, he said, it’s not always possible to tell whether something is a secret or not.

“For example, if I give you a nine-digit number, it could be someone's Social Security number, or it could just be a nine-digit number."
—Justin Cappos

Secrets security demands a holistic approach

As significant as the CircleCI hack of 2023 was, Philip George, executive technical strategist at Merlin Cyber, said the Codecov supply chain breach of 2021 better illustrates the ramifications of inadequate secrets management.

“Threat actors were able to obtain access to the targeted code repository, scan for production secrets and authenticators, then utilized the discovered secrets across production systems, resulting in direct access to protected data and widespread compromise of build and production code."
—Philip George

Preventing secrets compromises is essential to software supply chain security, George added. "Obtaining a level of zero trust coupled with continuous validation across the CI/CD pipeline and container environments will raise the level of assurance for the consumers at the end of the supply chain.”

While discovering secrets in software repositories is a good start in addressing the risk from leaked secrets, it’s only a start, because secrets can be exposed in many other places, Bambenek said.

“I have found them in scripting wrapped around the DevOps workflow, stored in flat files, and even in scripts or other documents stored in SharePoint, OneDrive, or Google Drive. There are many digital equivalents of the ‘password on the Post-it note’ in the digital world, and many of those equivalents are also cloud services that can either be compromised or have overly permissive access controls.”
—John Bambenek

George cited containers as another potential area of attack. “Ensuring that all facets of the container ecosystem are being scanned for secrets management compliance is equally as important as covering code repositories,” he said.

Modern software development environments are complex, and that means risk management needs bigger thinking.ReversingLabs Field CISO Matt Rose said it isn't just about the code or the compiled package, it's the technologies — the tooling— that actually poses the bigger threat to organizations from things like secrets leaks.

"That's why the CircleCI hack was an eye opener to a lot of organizations out there."
—Matt Rose

Secrets risk management: All together now

Cappos said he's glad to see GitHub taking clear steps on security secrets in its repository, noting the fact that they are "the easiest targets in that space."

"There are other places they could look, but you get diminishing returns. What people are trying to do is target the easiest things and knock those out because you get the biggest bang for the buck."
—Justin Cappos

While repository validation is an essential step, Rose said the secrets problem was also growing along with the complexity of modern software development — an organizational risk that could not be ignored.

"Modern applications, software, and cloud infrastructures do not exist without secrets. The problem is that organizations are managing more and more secrets every day. Without prioritization of which secrets are most dangerous you may not be focusing on the right secrets and miss something."
—Matt Rose

[ See Special Report: An Essential Guide to Securing Secrets in Software ]

Rust on Android goes bare metal: 3 key security benefits

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 19 Oct 2023 15:26:39 GMT

A milestone in the software industry's move toward safer programming languages was reached last week with Google's announcement that it is extending the use of Rust into bare-metal Android environments.

Google has been moving native Android code from C++ to Rust, which the company says has resulted in fewer security vulnerabilities. Most of that code runs in Linux. This move is about extending Rust beyond the Linux kernel.

Andrew Walbran, a member of the Android Rust team, wrote in the Google Security Blog that many security-critical components of Android run in bare-metal environments — outside of Linux — and they are typically written in C. "As part of our efforts to harden firmware on Android devices, we are increasingly using Rust in these bare-metal environments, too."

To achieve this shift, Google has rewritten the Android Virtualization Framework’s protected virtual machine (pVM) firmware in Rust to provide a memory-safe foundation for the pVM root of trust. That firmware performs a function similar to a bootloader and was initially built on top of U-Boot, a widely used open-source bootloader, which Walbran said "was not designed with security in a hostile environment in mind."

"We fixed the specific issues we found in U-Boot, but by leveraging Rust we can avoid these sorts of memory-safety vulnerabilities in the future."
—Andrew Walbran

Google's use of Rust in bare-metal applications will make Android a safer platform and have a broader positive impact on the Rust community, industry experts noted. Here are three key takeaways from the move.

1. Fewer memory safety issues

The move to extend Rust's use has the potential to make Android applications that utilize the Android Virtualization Framework (AVF) more secure by hardening the root of trust for the protected VMs, said Michael Mehlberg, CEO of Dark Sky Technology.

Mehlberg compared the AVF to Intel's Secure Enclave, which lets the Android application ship a section of code that will run in a separate virtual machine, be "completely isolated from the host Android platform, and only interacting with the base Android system through a very narrow interface."

"Using Rust in the pVM firmware will reduce memory safety issues in that interface between the protected virtual machine and, ultimately, the Android application that kicked off the computation in the pVM."
—Michael Mehlberg

He noted that the reduction in memory safety issues in the pVM firmware comes from Rust enforcing bounds-checking, as well as providing a strict ownership of memory by default. It also requires programmers to opt in to unsafe behaviors through specific code constructs that can be targeted for more stringent inspection during review.

Shane Miller, a senior fellow at the Atlantic Council and a distinguished advisor to the Rust Foundation, said that transitioning to Rust makes Android applications more secure.

"Memory safety has a huge impact on security, so replacing unsafe code like C with memory-safe Rust substantially improves the security of Android applications. In every industry study, more than 50% of security vulnerabilities are attributable to a lack of memory safety in the code."
—Shane Miller

2. A smaller attack surface

Irena Bojanova, a computer scientist with the National Institute of Standards and Technology (NIST), said that by rewriting Android's pVM in Rust, Google is reducing the potential attack surface of the pVM's root of trust.

"A more secure pVM implies a stronger foundational security, which indirectly can make Android applications running on top of it safer."
—Irena Bojanova

However, Robert Schiela, technical manager of cybersecurity foundations at the Software Engineering Institute at Carnegie Mellon University, said the shift was limited by its reach. He noted that while Google's move has the potential to secure Android systems — and the applications running on them — it won’t necessarily do much to make the applications’ software packages individually more secure. But he also sees benefits in the development.

"It could prevent exploits that might enable an attacker to control the underlying system and possibly cross application or device boundaries they shouldn’t be able to. At least, it should reduce the chances of that happening even if it doesn’t prevent it."
—Robert Schiela

Joel Marcey, director of technology at the Rust Foundation, said the use of Rust in a bare-metal environment has a deep impact on securing Android itself.

"These bare-metal components, now written in Rust, are outside of a normal operating system, such as Linux, where actual user applications will run. Therefore, this change has the potential to further secure the Android environment itself, which is the first step in ensuring that everything running on top of Android can be secure as well."
—Joel Marcey

3. Benefits for the Rust ecosystem

Dark Sky's Mehlberg said Google's move will have a bigger net benefit, by boosting Rust's usage more broadly. As more companies use Rust in bare-metal contexts, the ecosystem of Rust libraries that target bare metal will grow, and the existing bare metal–capable libraries will be enhanced through bug-fixes and features, he said.

“Additionally, this will help drive the development of future Rust language features and patterns for working in bare-metal contexts."
—Michael Mehlberg

NIST's Bojanova said Google’s move is significant for the Rust programming language because “it demonstrates Rust's growing popularity and trust in the industry for security-critical applications.”

“Google's adoption of Rust for a critical component in Android virtualization will likely inspire other organizations to consider Rust for their projects, particularly when security is a top concern. This could lead to increased investment in Rust development, the creation of more libraries and tools, and a broader community of Rust developers.”
—Irena Bojanova

Josh Amishav, founder and CEO of Breachsense, said Google's move will have a clear impact on the Rust universe. "Google's endorsement of Rust for such a critical component will validate Rust's capabilities in a real-world, large-scale setting,” he said.

“This can serve as a case study and potentially motivate other organizations to consider Rust for similar use cases. As a result, the move will also lead to more developers getting interested in and contributing to the Rust ecosystem.”
—Josh Amishav

Rust's development: It takes a village

While this isn’t the first release of a Rust implementation on bare metal, the Google Android team's transparency about the limitations of Rust’s safety features will have a huge impact on the Rust community’s ability to understand and prioritize future improvements, the Rust Foundation's Miller noted.

“Google’s emphasis on collaborating with the Rust community to implement those improvements also makes the delivery of that work more achievable and improves the security of all Rust implementations. Google’s model for responsible use of open-source software has a huge impact on the Rust universe.”
—Shane Miller

The evolution of app sec: Getting off the scan-and-fix hamster wheel remains elusive

jpmellojr@gmail.com (John P. Mello Jr.) — Thu, 12 Oct 2023 17:10:44 GMT

Over the last 20 years, cybersecurity has changed a lot, but one thing has remained resistant to change: scanning resources for defects and fixing them. Now may be the time to hop off that scan-and-fix hamster wheel, argues Chris Romeo, CEO of the threat modeling company Devici, in a recent Security Table podcast.

"This pattern is just wrong. It's broken. We've seen a history of the challenges following this pattern does in working with developers."
—Chris Romeo

Travis McPeak, co-founder and CEO of the policy-as-code tools company Resourcely, seconded Romeo's call for a reset in commenting on Romeo's LinkedIn post on the subject.

"You're singing my song. Scan and fix sucks. We'll always be in reactive, vulnerability management hell. As an industry, we're pretty bad at vulnerability management. Sixty percent of breaches involve known vulnerabilities."
—Travis McPeak

But wait. Wasn't "shifting left" — moving security functions closer to the beginning of the application development lifecycle — supposed to derail the hamster wheel by averting security problems that needed fixing? "No," Romeo argues in his LinkedIn piece. "It just recommends starting the hamster wheel earlier," he wrote.

When will application security evolve? Experts say replacing scan-and-fix could remain elusive. But tools are emerging that could slow that hamster wheel and provide prioritization and automation.

[ See special report: The Evolution of App Sec | See Webinar: Why AST fails at supply chain security ]

Are RASP and IASP the answer?

What about using app sec tools that don't scan and fix, but rather view and block or allow? Could applying the techniques used by runtime application security protection (RASP) and interactive application security testing (IAST) tools be the answer?

Jeff Williams, co-founder and CTO of Contrast Security, said RASP actually does "fix" flaws, although it does it at a different — and better — location. For example, instead of trying to fix every SQL query everywhere (which will never happen), RASP adds a trust boundary to database access methods to detect when untrusted data modifies the meaning of a query — essentially the definition of a SQL injection attack, he explained.

"So with RASP, you get both visibility into who is attacking, what vectors they are using, which vulnerabilities they have discovered, and really strong protection against exploit. The typical 'fix' — replacing with a parameterized query — thwarts the attacks, but you get no visibility. And you have to modify all of the queries."
—Jeff Williams

Romeo said RASP and IAST won't work in practice as alternative to scan-and-fix, however.

"We’d have to embed static application security testing (SAST) into the runtime of the application, where it scans the code as it’s used and blocks the request if there was a code-based flaw. I’ve already talked myself out of this option for many reasons."

Those reasons include a hit on performance and the placement of a security control in a strange place, Romeo said.

What about an IDE solution?

Another place to break the scan-and-fix pattern might be in the integrated development environment (IDE).

"If we could introduce the scanning function into the IDE in real time, we should be able to sound a buzzer and get the developer to fix the problem in real time so we get away from the stack of issues."
—Chris Romeo

However, all that buzzing is likely to break developers' workflow and hurt their productivity, Romeo said. "This still doesn’t feel like the answer to our industry’s woes."

Paul Hodgkinson, a security specialist at GitHub Advanced Security, said that having security alerts and fixes in an IDE would be effective — but also pose problems.

"[Getting] consistency in using alerts in IDEs is very hard. You’ll never get 100% compliance in most teams. That means you always have to follow it up with checks in the code review pipeline, such as at [pull request] time or in [continuous integration] for those who don’t do [pull requests]."
—Paul Hodgkinson

Hodgkinson added that real-time scans have a trade-off of the usual triad of speed/quality/cost. "Deep SAST analysis with dataflow and taint, and accurate representation of the code takes time and is expensive in processing, relative to fast scans that can give you partial results," he wrote in response to Romeo's post.

"Some tools claim they can operate in your IDE but then farm the work off to a server and you eat the resulting costs. Some tools claim to operate in your IDE, but they're anemic cut-down tools that don't satisfy."
—Paul Hodgkinson

What about AI?

Artificial intelligence (AI) seems to be the answer to all the world's problems these days. Could AI offer an alternative to scan-and-fix? Might an AI tool scan and introduce PRs/fixes that relieve the ignored issues problem?

"[Even] with AI, we’re still talking about scan-and-fix. It's just fancy robot fixing."
—Chris Romeo

So what's so bad about scan-and-fix after all?

During the Security Table podcast, there was some pushback to Romeo's criticism of scan-and-fix from Izar Tarandach, a senior staff engineer at the monitoring and security platform Datadog.

"Scan-and-fix, by itself, is not a bad thing. It may generate results that are not optimal, but if you add context by understanding more and more about where that scan is happening, you're going to have shorter, prioritized, contextualized cycles of fix."
—Izar Tarandach

So rather than breaking the pattern — which still has value, especially as the knowledge we have gets better — "it becomes a problem of prioritization," Tarandach said.

Smarter app sec tools are emerging

ReversingLabs field CISO Matt Rose said the problem with the hamster wheel of scanning and fixing is its focus is on identification over remediation.

"Organizations are typically great at identification but less effective at remediation. The best way to address remediation is by having a clearly defined and understood security policy that defines what risks you care about and what risks are not important. This saves time, money, and resources."
—Matt Rose

The main problem with scan-and-fix is noise — lots of alerts, lots of false positives, lots of false negatives, said Matthew Coles, Product Security Engineer at Dell Technologies, during the roundtable.

The way you solve that is you make the results prioritized, more actionable — and less noisy, Coles said.

"So you need the tools to be smarter because that will reduce the noise and allow humans to make intelligent decisions about what to fix first. But you're not going to ever solve the problem because developers are introducing bugs into the system. Until that stops, you're going to have to have analysis."
—Matthew Coles