The software supply chain has been a subject of fierce debate in 2021, as a rash of malicious attacks have exposed vulnerabilities exploited by threat actors from rogue nation statesto criminals. From the ransomware attack on Kayesa to the backdoor installed into SolarWinds Orion, companies have had to to reexamine how they protect the integrity of their development and code process.

The vast majority of security and software development professionals agree future attacks will use similar techniques that were deployed in the SolarWinds attack in 2020, according to a study released in July from Venafi. 

That attack involved the malicious insertion of malware into the SolarWinds Orion platform through a backdoor that exposed thousands of customers to potential downstream attacks. It effectively poisoned the well of trust between an application developer and companies that depend on the software to monitor IT performance.

There is strong disagreement, however, over which side of the fence — security teams or DevOps — should be responsible for detection and mitigation of security flaws found during the software development process. Exactly 48% on each side said security or software development teams were responsible for fixing flaws, according to the Venafi study of more than 1,000 InfoSec and DevOps executives.

"The only way to reduce these risks is to dramatically improve the security of the development pipeline and the software it delivers," said Kevin Bocek, VP of security strategy and threat intelligence at Venafi. "However, if we can't even agree on who is responsible for taking these actions, it's pretty clear we aren't even close to making meaningful changes."

Part of the problem stems from a lack of confidence in the robustness of internal mechanisms to achieve security standards.

Four in five of respondents are not completely confident in their organization's ability to protect against attacks targeting the software build, Venafi found.

The study also shows 69% of respondents on the developer side believe the developer is responsible for the security of software build environments, while on the security respondents side, 67% say it is their responsibility on the security side.

Game, set . . . insecure

Outside security researchers spend countless hours working to discover vulnerabilities that can be exploited in the wild. Depending upon the organization, a flaw may be discovered during the development process, or left undetected for years. 

Researchers at SonarSource recently uncovered vulnerabilities in an open source programming language called SquirrelLang, which is often used for video games and cloud services, including the popular title Counter-Strike: Global Offensive, which has millions of players

The game utilizes the Squirrel Engine for the creation of custom game modes and maps, however researchers found when downloading and hosting items from the community, Squirrel code is executed without warning, according to a blogpost released Tuesday.

The Squirrel Engine is normally sandboxed within the GS:GO process, but the vulnerability allows attackers to bypass those restrictions and execute arbitrary code within the SquirrelVM, providing an attacker access to the underlying machine, according to the blog.

"We had previously researched vulnerabilities in CS:GO and noticed that Squirrel was deployed in servers," Simon Scannell, vulnerability researcher at SonarSource, told Cybersecurity Dive via email. "We decided to take a look at the Squirrel core as it is an open-source component of the Source engine." 

"Such vulnerabilities could be used to embed backdoors in community content which can be distributed via the Steam workshop," Scannell said.

SonarSource sent details of the vulnerability to the Squirrel GitHub repository back in August. By mid-September a commit containing a patch was pushed to the repository, according to SonarSource officials, however as of the date SonarSource published the blog on Tuesday, the commit had not been included in a new, stable release of Squirrel. 

SonarSource is recommending that all project owners who depend on Squirrel to rebuild the latest Squirrel version from source code.

Disclosure and remediation debate

A major problem within the software development community is the lifecycle question of mean time to remediate, which raises the question of why a vulnerability is often fixed so far past the original discovery, so customers are left exposed to the flawed application. 

Om Moolchandani, CTO, CISO and co-founder of Accurics, said processes to detect vulnerabilities are often aimed at production environments and patching runtime environments make the process far too costly. 

"A better approach is detecting vulnerabilities in the design and development phase and using automation to remediate flaws," Moolchandani said. "This way flaws are found and fixed in the software code — meaning those security vulnerabilities are wiped out for everything that comes after, when the software or platform is actually used by the business."

The Kaseya ransomware attack raised considerable questions about the timing of when companies have the obligation to notify customers of a potential vulnerability and whether those risks need to be reported to some outside authority that can share that intelligence or help work on a patch. 

"There is a significant public relations benefit (or harm) in being seen as proactive or lagging in responding to vulnerabilities that are brought to a company's attention or disclosed," Mitchell Schneider, Gartner principal research analyst, said. "In the past, companies were scrutinized on whether they were breached or not, however we know now that anyone and everyone can be breached."

Gartner has developed guidance around notification: 

• Notify clients with enough detail so they can make a decision on what the issue is and what will be the outcome if the vulnerability is exploited.
• Provide clear details on any workarounds/configuration changes that can be put in place before a patch is available.
• Provide clear details of a patch when it becomes available. If possible include any cohabitation issues if a patch cannot be installed. 
• If there is a researcher to thank, do so.
• Point directly to your responsible disclosure program to encourage researchers to reach out to you for any issues that may come up in the future.