However, companies confront extensive barriers when developing reliable application security programs. Just to name a few, we’ve got: 

• Narrow coverage that causes blind spots and exploitable vulnerabilities
• Slow remediation times that leave lingering vulnerabilities and increased risk
• Costly multiple tools and increased operational overhead
• Reduced collaboration and poor visibility due to siloed teams
• Limited scalability and adoption of current tools

That’s why Mend.io today unveiled the Mend AppSec Platform, a solution designed to help businesses transform application security programs into proactive programs that reduce application risk. The Mend AppSec platform offers customers everything needed to build proactive application security through one solution, at one price.

“To gain true visibility into security risk, customers need a variety of AST tools, all in a single platform,” explained Rami Sass, CEO and co-founder of Mend.io. “The Mend AppSec platform removes the barriers that often prevent companies from covering the full range of risk across critical software supply chain components: custom code, open source software, containers, and increasingly AI models. This fills a crucial gap in the marketplace.” 

Find out more about the Mend AppSec Platform

A single platform that supports both developer and security teams

See the platform

The Mend AppSec Platform is designed to businesses solve important challenges with the following benefits:

• Wide-range coverage. Holistic coverage addresses multiple attack surfaces and eliminates gaps in security.
• Reduced tool complexity. Simplifies security management with a centralized platform for easier deployment and reporting. 
• Lower risk and faster remediation. Early risk detection coupled with actionable insights reduces threats introduced into an application and simplifies remediation. 
• Reduced operational costs. Adopting a single integrated AST solution such as the Mend AppSec Platform can significantly reduce operational costs by eliminating multiple licensing fees, streamlining implementation and integration efforts, minimizing ongoing maintenance requirements, and reducing the need for specialized resources.
• Increased collaboration and visibility. Centralized visibility into a company’s full risk posture builds a shared sense of security responsibility among development and security teams. 
• Improved scalability and adoption. A complete AST platform makes it easy to scale application security across multiple teams with a single tool, increasing adoption, enforced policies, and unifying threat detection.

The Leaderboard allows the Mend.io team to leverage and share a valuable resource. There is no better arbiter of package reliability than Renovate, which has gathered crowd-sourced data on over 25 million dependency updates. By analyzing what packages are consistently releasing good updates, we built an accurate picture of a package’s overall reliability for software engineers trying to balance functional risk with the security risk imposed by our increasingly vulnerable software supply chain. 

“The Leaderboard helps shift the AppSec view from detection to prevention, a valuable perspective for reducing the risk imposed by our increasingly vulnerable software supply chain,” said Rhys Arkins, vice president of product management at Mend.io. “Success hinges on having the knowledge necessary to prevent possible open-source vulnerabilities from ever being installed in the first place. For that to happen, companies need to know not only what packages are in use at their companies, but how safe they are.” 

The full report showcases detailed rankings for npm, PyPi, and Maven.

Key findings:

Group runs bring down overall package reliability. 

Any fan of the TV show Survivor can tell you that in competition, groups are often hurt by their weakest link, and the same holds true when it comes to group updates. A group of ten packages is ten times more likely to encounter a failure. 

Release frequency has no effect on average success rates.

You would think that more-frequent releases would improve reliability through faster bug fixes and an engaged maintainer community, but this was not the case. 

Looking across the overall categories, the top three most reliable packages for each language are: 

Npm:

1. prettier-eslint
2. np
3. jest-cli

Maven:

1. org.apache.maven.scm:maven-scm-provider-gitexe 
2. com.github.ekryd.sortpom:sortpom-maven-plugin
3. org.apache.maven.plugins:maven-release-plugin

PyPi: 

1. Pulumi
2. Botocore-stubs
3. types-python-dateutil

Read the full report

That’s why we believe in automated testing tools that integrate application security into existing workflows — making tools easy to use generally translates into more seamless adoption, and teams that work better together. Wherever possible, we create integrations that overcome this problem.

With that in mind, we are particularly excited about the forthcoming availability of Jira Security dashboards, which features a new supporting enhancement to Mend.io’s Jira integration capabilities. Now Jira users will have a single place to view and triage security alerts from mixed security vendors.

In addition to the enhanced integration support, the new capabilities will include:

• Vulnerability linking to Jira issues.
• A new ability to create issues directly from within the Security Tab. Fields are pre-populated with data pulled from Mend.io’s security testing integration.
• The new ability to filter by severity, CVE identifier, and more to run vulnerability triaging and prioritization rituals.

Jira Security will help development and security teams increase collaboration and shared responsibility for security by centralizing vulnerability information in a shared space where teams manage their work. It will also empower development teams to bring security into agile ceremonies such as sprint planning, and quickly triage and address vulnerabilities to incorporate security into the development process.

The Installation and configuration process is relatively simple, as users can select “Jira Security Dashboard” both in the onboarding process and within advanced settings. 

Once selected the user then selects Mend Applications (Products).

Once Mend Applications is selected for a Jira instance, they are available for the selection in the Project configuration for Project Admins. The user can select what security containers (Mend Projects) will be a source of vulnerabilities for this Jira Project.

After containers are connected to a Jira Project, Mend.io will continuously update this dashboard with alerts from the respective Mend.io Project on the following: 

• Severity
• Vulnerability description 
• Vulnerability status – Open, Closed, Ignored, Unknown 
• Vulnerability detection date
• CVE information
• Issues 
• Actions 

Benefits

According to research by Atlassian, the average Jira customer has around three security vendors who push data to Jira or would like to. By viewing all vendors in one place, using the integration with Jira, users will save valuable time and resources when they’re security scanning. And now, developers will enjoy more flexibility and choice to secure their software and applications when using Jira.

Additionally, the integration enables users to find and fix issues and vulnerabilities quickly and early in the SDLC. Integrating Mend enables users to send security findings directly to Jira Security, and Mend users will now be able to adopt and implement cutting-edge capabilities from Jira so that they can better manage their security more easily. For both Mend.io and Jira users, the integration accelerates the early detection and remediation of vulnerabilities that expedite security processes by anticipating and addressing issues before they can compromise your code base.

That’s the feeling you get when a malicious package, a software package containing malware, infiltrates your software. These seemingly harmless bits of code, lurking in trusted repositories like npm and RubyGems, can wreak havoc on your applications and steal your data.

In this article, you can expect to learn how malicious packages work, the different ways they can infiltrate your systems, and the growing threat they pose. We’ll also explore the impact they can have on your organization and how to defend yourself against these digital tricksters.

A fast-growing threat

As the name implies, a malicious package is software that is created with malicious intent. What makes them particularly concerning is that they are remarkably easy to create. Useful for any number of malicious intentions, these packages are hard to avoid and to detect, unless you know what to look for.

Malicious packages aren’t new, but they’re proliferating at an alarming pace. In our “Malicious Packages Special Report,” Mend identified a 315% increase in malicious packages published to npm and RubyGems alone from 2021 to 2022, and expects that trend to continue.

Malicious packages use similar techniques to trick people into downloading them, where they wreak havoc inside users’ systems. Because malicious packages are something that generally come from places you think you trust, they are abnormally effective.

Anatomy of a malicious package attack

Malicious packages are used to steal credentials, exfiltrate data, turn applications into botnets, or erase data. But first, attackers need to trick someone or something into downloading the package.

Malicious packages can deliver maximum bang for the bad guy’s buck. It can be as simple as hiding a malware payload in open source code and tricking a careless developer into using it, or elevating bugs in package manager systems and then benefitting from the opportunities afforded by the scale of a corrupted software supply chain. And make no mistake: Like any malware, malicious packages can inflict significant damage. They can steal credentials, exfiltrate data, turn you into a botnet, or erase your data.

This, of course, explains their growing popularity. Threat actors never ignore a good opportunity, particularly when it comes to attacking their favorite target: applications. Unfortunately, most companies are only now beginning to explore technology that can defend against malicious packages, and for many, the barn door has been open a little too long. Mend’s 360 degree malicious package protection has already discovered evidence of threat actor success — thousands of malicious packages hiding in existing code bases. 

Malicious packages are more dangerous than vulnerabilities

Once a developer downloads a malicious package, how much damage it does will depend on several key factors:

1. Intent – When threat actors infiltrate using a malicious package, their intent substantially determines the impact. A threat actor trying to inform people about a war or protest action with annoying messages has a lower overall impact than one trying to steal information or turn developers’ machines into cryptocurrency miners.

2. Organization type – Attacks designed to exfiltrate personal information will have a larger, potentially long-term impact on companies trusted with sensitive data. Ransomware attacks that disable systems can have an outsize impact in organizations like hospitals, where lives depend on uptime.

3. Duration – When malicious packages are discovered quickly and removed completely, the damage they cause can be limited. The greatest damage can be caused by packages that remain undetected for months or years while quietly delivering their payload.

4. Spread – Some of the most dangerous malicious packages are designed to provide initial access to a network, at which point the threat actor can move laterally through systems to steal passwords or protected information in order to gain even more access.

Unlike vulnerabilities — which can and do often exist for months or years in application code without being exploited — a malicious package represents an immediate threat to your organization.

Think of it like this: If your applications and organization are a house, then attackers are like burglars. A vulnerability is your proverbial unlocked window: It could let a burglar in some day, but that’s only a possibility. On the other hand, a malicious package is like accepting a FedEx box that already has the burglar inside.

Malicious package attack vectors

In order to deliver a malicious payload via an open source package, attackers must find a way to get the package downloaded. That means attackers need to fool someone – or something – into downloading it. Let’s take a closer look at several of the ways that malicious packages can be downloaded. There are four basic attack vectors for malicious packages: brandjacking, typosquatting, dependency hijacking, and dependency confusion.

Brandjacking is an activity whereby an attacker acquires or otherwise assumes the online identity of another company or an owner of a package and then inserts a malicious code. It doesn’t necessarily mean he actively steals something, but just takes advantage of an opportunity to take ownership related to the brand name.

In a typosquatting attack, an attacker publishes a malicious package with a similar name to a popular package, in the hope that a developer will misspell a package name and unintentionally fetch the malicious version.

With dependency hijacking, an attacker obtains control of a public repository in order to upload a new malicious version.

With dependency confusion attacks, the threat actor creates a public repository package with the identical name of an internal package within the intended target system. The intention is to trick the target’s dependency management tools into downloading the malicious public package instead of the safe internal one.

Malicious package attack examples

Malicious packages can be used for a variety of nefarious purposes. For instance, we saw a package on npm that stole AWS IAM data, with techniques similar to those used in the Capital One hack. 

Similarly, another more recent critical vulnerability involved a malicious version of a popular utility, which could be exploited to gain unauthorized access via SSH.

The fight against malicious packages is an ongoing battle. As attackers become more sophisticated, so too must our defenses. The future of software security likely involves a combination of automated detection tools, developer education programs, and increased collaboration between open-source communities and security vendors. By staying vigilant and adapting to new threats, we can keep malicious packages from becoming the norm.

Scaling Software Supply Chain Source Security in Large Enterprises

Rao Lakkakula, senior director of security engineering at JPMorgan Chase, gave a great overview of the extreme complexity involved in securing the software supply chain from the perspective of a large enterprise. The bottom line: while nobody can predict what’s going to happen, companies that proactively plan are better able to respond effectively to critical events. He outlined the following process: 

Understand the software process

Identify entry points into the enterprise where software is ingested, such as open source, purchased software, and third-party developed software.

Look out for shadow application development. It’s a pretty sure bet that people are using stuff you don’t know about.

Monitor integration processes

Validate the security of providers and dependencies of OSS and closed-source components. Use high-quality, valid versions of components from fewer reliable sources.

Why is this important? It’s not that easy to delete vulnerable software once it’s in the system. You risk breaking things if code is deleted or updated. The more you do at ingestion to minimize damage, the better off you are. 

Build comprehensive software bills of material (SBOMs). You need to have a realistic way for finding the next log4j, so build an asset inventory of both vendor software and OSS code, and where they deploy to. Also pay it forward by generating SBOMs for everything you ship to others.

Lakkakula gave a great analogy illustrating the complexity of SBOMs in the enterprise. He started with comparing an SBOM to a Dairy Milk candy bar list of ingredients. But SBOMs in the enterprise are more like a giant candy store that sells a ton of candy from all over the world, some of which is no longer in production. Enterprises are similar: they can bring in OSS software from all over the world, they don’t always know who wrote it, and some is probably no longer maintained.

Secure the internal CI/CD pipeline

Building a secure internal developer infrastructure starts by thinking of security integrity, build integrity, deployment integrity, and so on. This means that any components, dependencies and data are consistent, accurate, trustworthy, and protected from unauthorized modification. 

Automate vulnerability monitoring

Continuously monitor for new vulnerabilities to patch deployed software. Leverage the asset map and SBOM. Build and enforce policies based on your risk appetite.

Get involved

AppSec is a relatively new field and it’s a problem that’s complex enough that no one single company can do it alone. Government sector agencies and groups like OpenSSF, FS-ISAC, SLSA, and NIST often have working groups that are open to the public, so that’s a good place to start.

Telling Fairy Tales to the Board: Turn Attack Graphs into Business Stories

Andy Ellis and Oren Sade of Orca Security gave entertaining advice on how to translate an attack path that security understands into a business story that the board can understand. Key points:

• Drop all the technology phrases. “We have to assume that executives don’t understand these phrases. When they try to build a mental model based on keywords, those are the wrong words for them,” Ellis said.
• Focus. It’s very important to use the smallest argument to spur action.
• If there is a human responsible, don’t throw them under the bus. “Human error is an error in a system in need of redesign,” noted Ellis.
• Management needs to see the line from hazard to fix. If there are two things you have to do, you need to match a fix for each hazard.

Running in the Shadow: Perspectives on Securing the Software Supply Chain

Did you hear the one about a developer, a CISO, and a policymaker who walked into a conference session? This panel discussion featured three different — and important — perspectives on building a secure supply chain. Moderator Jessica Hardcastle of The Register led the panel, which included James Higgins, CISO, Snap, Inc.; Dan Lorenc, CEO and co-founder, Chainguard; and Camille Stewart Gloster, White House Office of the National Cyber Director. Key quotes:

Higgins: “From a CISO standpoint, the issue is easy to identify, just impossible to implement. If you can understand the landscape and where the code is coming from, you’ve solved 80% of the problem.”

Higgins: “Inventory is the most critical thing you can possibly do. What is your code? Where is it stored, and where is it coming from. If you can solve for that, you can solve the rest rather easily. It doesn’t mean I’m protected from something like Log4j, but I can tell the board we know where everything is, and it’s not a problem.”

Lorenc: “This is a developer problem. It’s a code quality and process problem. We have to change the way developers build software.”

Lorenc: “Open source is really complicated. When they grab a piece of code and run npm install it’s the equivalent of picking up a thumb drive in a parking lot and plugging it into your laptop. Nobody wants to talk about this but it is really scary.”

Stewart Gloster: “In open source software, the government should not lead, but we can be supportive: We can get our own house in order. We can invest in cleaning up code. And we could make sure that there is funding for supporting open source software investments.”

The Psychology of DevSecOps

Jennifer Czaplewski, senior director at Target and Kathryn Pimblett, senior cyber manager at A.P. Moller Maersk presented two different psychological approaches to building successful AppSec programs.

The DevSecOp team at AP Moller Maersk uses a three-pronged approach based on the theory of planned behavior to challenge the belief that AppSec is a blocker to efficient application delivery and to increase developer buy-in and collaboration.

The key: Reduce pain for developers and make it fun. “We really leveraged gamification for AppSec training,” Pimblett said. “As it stands, we have almost a third of developers actively engaging in the platform—and it’s all voluntary.”

At Target, DevSecOps uses organizational psychology — how people behave in the workplace — to build a security-minded developer culture. The main tool lies in using psychological contracts to establish standard product security values.

The three contracts: Meet developers where they work, offer end-to-end solutions, and the right way = the easiest way. “Whenever possible, we integrate right into the tools they are using so they don’t have to be interrupted,” Czaplewski said. 

The National Cyber Strategy as a Roadmap for a Secure Cyber Future

This panel of public-sector cyber strategists discussed two fundamental shifts outlined in the National Cybersecurity Strategy: rebalancing the cyberspace defense responsibility onto those most capable of bearing it, and realigning incentives to favor long-term investments over temporary fixes. One key question arose: How can organizations better support open-source software developers and infrastructure? Here’s what the panelists had to say:

Eric Goldstein, executive assistant director, Cybersecurity and Infrastructure Security Agency

“One piece is that we need a model of shared responsibility across the breadth of the OSS ecosystem. We need to make sure that the developers creating and maintaining libraries and packages have the support, resources, and information they need for that project to remain fit for purpose.

We need to know how to prioritize the libraries and packages that are heavily used in critical uses and establish a baseline for good security so it can raise the bar across the world. Because we know that there are many vulnerabilities out there. Example: A shockingly high percentage of Log4j still being downloaded are malicious.

We want to think more about what a package manager can do to create friction and speed bumps to filter and block malicious packages.“

Robert Knake, acting principal deputy national cyber director, Office of the National Cyber Director

“One of the issues is how we are talking about software liability. We want to shift responsibility in bad outcomes from end users to companies that develop that software.

But when it comes to an OSS development strategy, we don’t want to place that responsibility on open-source communities. It does no good if you hold responsible individuals doing this for free on a part-time basis. The question is, how do we create a situation where commercial software developers make better choices about what OSS to use?”

Liesyl Franz, deputy assistant secretary for international cyberspace security, Acting, US Dept of State | Cyberspace and Digital Policy Bureau 

“We can be a coalition builder for various aspects to the extent that we can help carry the message and demonstrate the activities and expertise of team CISA. “

Bryan Vorndran, assistant director at the FBI, noted that the agency is not involved in areas of regulatory action. But he did point out the value of early training on cybersecurity best practices. “We currently have no academic standards for best practices in this area across the US academic institutions. We need to up this farther upstream. “

Achieving the AWS Security Competency differentiates Mend.io as an APN Advanced Tier Technology Partner that provides specialized software designed to help enterprises adopt, develop, and deploy complex security projects on AWS. To receive the designation, AWS Partners must possess deep AWS expertise and deliver solutions seamlessly on AWS.

“Mend.io is proud to achieve AWS Security Competency status because it acknowledges our technical and business strength and our position as a leader in the field of application security,” said Yariv Shapira, director of global cloud alliances at Mend.io. “Our team is dedicated to helping companies achieve their security goals by combining our technology and our expertise with the range of powerful security tools that AWS provides.”

Mend.io’s AWS Security Competency status reinforces the strong partnership that was built with AWS over several years. This achievement connects the company more closely to the global AWS security teams, strengthens the Mend.io brand, and provides valuable additional resources to offer AWS customers. The recognition by AWS reinforces Mend.io’s position as a trusted provider of application security for AWS customers.

Mend.io helps enterprises meet their obligations as part of the AWS Shared Responsibility Model. Under that model, AWS is responsible for the security of the cloud, while customers are responsible for securing their apps in the cloud. Together, Mend.io and AWS provide an end-to-end application security solution.

AWS enables scalable, flexible, and cost-effective solutions from startups to global enterprises. To support the seamless integration and deployment of these solutions, AWS established the AWS Competency Program to help customers identify AWS Partners with deep industry experience and expertise.

Find out more at the AWS Marketplace.

Indeed, the increased complexity extends to responsibility. Mend Vice President of Outbound Product Management Jeffrey Martin, recently participated in a lively roundtable as a panel of industry experts discussed the main challenges of figuring out who does what when it comes to application security. Key takeaways include the following: 

Open Source makers aren’t AppSec teams

With commercial software, the builders take responsibility for the security of the software being sold. Not so with open source software. While people often assume the responsibility for security belongs to the open source community, it really lies with the user of open source code. Companies that aren’t vigilant with open source essentially enter into a risk transfer to an unknown entity that they then don’t monitor. 

Governance standards are just the beginning

OWASP (The Open Web Application Security Project), NIST (The U.S. National Institute of Standards and Technology), and MITRE ATT&CK are good frameworks and ways to understand risk. Fundamentally, good security doesn’t have that many rules. Keep your stuff up to date. Make sure you know what your risks are. Prioritize those risks. Any good framework will actually get most of those basics correct.

Security should not be developer-led… 

We talk a great deal about shifting left and putting it on individuals. But if developers’ goals and incentives don’t include security, they won’t do it. Humans act in their own interests and unless their interests are made to be something different, they’re going to behave how they want to behave. If a company wants to secure code, it’s on them to put in place the standards, enforce the standards, and actually care and invest. Companies that don’t do those things will never be secure and are basically just setting up people to fail. Companies have to get their priorities right and invest in the tools and training that empowers developers to perform robust security.

…But they do need to be engaged

There are things that development managers can do to introduce more security in a reasonable way that doesn’t cost a ton of extra time and money. Importantly, they can lead by encouraging developers to take reasonable steps that will help. For instance, when introducing a new library, don’t introduce anything that’s got a known vulnerability, kind of a “do no harm” approach. 

The real solution is to continually advocate for security to people who control the budgets and what is built. Emphasize that they’re not giving enough time or resources to create a secure application, only enough time to develop a functional application. If you don’t care about the person who controls the budget, you probably should.

Application security belongs to the company as a whole — but many don’t get it. 

Prioritizing speedy delivery over secure code inevitably results in technical debt that accumulates as an application ages. However, most companies don’t ask developers to maintain technical debt at a certain level because that’s not how the business works. If that application generates revenue, management will want it to last as long as it can. Management has to learn that huge amounts of technical debt mean insecure applications, which greatly increase business risk. That’s where the big changes have to come. Not just shift left in development and developer enablement, but shifting the responsibility to the actual company, the ones that control the resources.

Expect outside forces to drive wider change. 

Businesses that consume software expect it to be secure, but software security is simultaneously very distributed and not regulated. Companies are just beginning to wake up to the issue. SBOMs and the legislation around them have certainly driven some companies to at least demand a software bill of materials if they’re going to buy pieces of software from somebody. However, the average business is not yet asking the right questions about security, never mind putting commercial demand on their suppliers. It will come, however. Because of that, companies will have to change their behavior, not just developers. As consumer demand grows, companies will have to change in order to follow the money. We can also expect government regulation to drive that change, as evidenced by the new National Cybersecurity Strategy from the Biden Administration. Think of it this way. Until the Food and Drug Administration (FDA) was established, there was little regulation on food safety, and fraudulent practices were rife among food manufacturers. Perhaps it’s time for an FDA for software safety, too. Sometime in the next five to 10 years, we’re going to see the equivalent of an FDA for at least critical infrastructures. It’s too important to everything.

But what about tomorrow? The threat landscape constantly shifts as cybercriminals innovate and evolve their craft. With that in mind, we asked several Mend experts for a little insight into what they expect to see in the coming year -– and some ideas on how to prepare. 

Jeff Martin, VP of Outbound Product, Mend.io

Prediction:
In 2023 and beyond, we’ll start to really see a cybercrime AI arms race take shape. The application of AI for data pattern recognition — used for antimalware, antivirus, and traffic monitoring — is a boon for accurately identifying undesired behavior. On the flip side, bad actors are utilizing it for similar purposes, such as identifying weaknesses or even to create more effective phishing emails. Because it is unfortunately easier (and less expensive) to attack than to defend, we’ll see the bad actors benefiting more from AI on balance.

How to respond:
To prevent hackers from getting the upper hand, it will be crucial for defenders to ensure they’re handling the basics — known vulnerabilities, user education, zero trust frameworks and the like — to ensure that these more effective bad actors have a tough time finding anything to leverage into a breach.

Chris Lindsey, Sr. Solutions Architect, Mend.io

Prediction:
Over the course of the next year, we will unfortunately see more vulnerabilities like Log4j and Spring4Shell being exploited. A big trend that we’re noticing today is that malicious actors are buying up and changing the names of popular open source URLs, so a simple typo can go from directing you to the right thing to a malicious site — an attack vector known as typosquatting.

How to respond:
Having a good static application software testing (SAST) tool that quickly alerts you when it comes across malicious activity can help defend against these threats.

Prediction:
From an application security standpoint, we’re going to see open source getting more compromised. Cyberattacks will continue growing in frequency and scope.

How to respond:
If organizations adhere to good programming standards and app design, they can significantly reduce their chances of becoming the next victim.

Maria Korlotian, Development Team Leader, Mend.io

Prediction:
In 2023, we’ll see malicious actors continuing to improve on the creativity and sophistication of their attacks. For example, we recently spotted malicious code within a popular JavaScript package manager, in which the attacker uploaded a myriad of packages with malicious code targeted at supply chain scanners. When these packages were installed, it gave the intruder access to use the compromised computers for crypto mining at the expense of organizations’ resources, which could have been critical in some cases.

How to respond:
As these sorts of sophisticated attacks ramp up, it is imperative that organizations adequately invest into bolstering their application security. Those that fail to do so may think they’re saving on costs today, but there will likely be much more significant ones to deal with tomorrow.”

The report, which draws data from several sources, including our industry-leading vulnerability database and Mend Supply Chain Defender, delves into the significant risk posed by the ongoing rise in open source vulnerabilities and software supply chain attacks. According to the report, the number of open source vulnerabilities that Mend identified and added to its vulnerability database in the first nine months of 2022 was 33 percent greater than the first nine months of 2021, reflecting both the growth in the number of published open source packages and the acceleration of vulnerabilities. As businesses continue to heavily rely on their applications for success, this growing threat is a mounting concern. 

Key findings from the report include: 

• 33 percent growth in the number of open source software vulnerabilities that Mend added to its vulnerability database in the first nine months of 2022 compared with the same time period in 2021. This outstrips the estimated 25 percent growth in the amount of open source software available.
• According to a representative sampling of approximately 1,000 North American companies from January to September 2022, only 13 percent of vulnerabilities seen were remediated, compared with 40 percent remediated by those companies using best practices for application security.
• Data from Mend Supply Chain Defender shows a steady quarterly increase in the number of malicious packages published in 2022, with a significant jump in Q3, which increased 79 percent from Q2. 

“As security debt continues to rise, it’s crucial to find a way to prioritize the vulnerabilities that pose the highest risk to avoid falling victim to an attack,” said Jeffrey Martin, VP Product Management at Mend. “Using remediation tools to assess and prioritize the vulnerabilities that can most heavily impact systems is an important element to managing security debt. However, organizations should not just pay attention to severity details to ensure effective prioritization and remediation. They also need to look at the context in which flaws are exploited, both on their own and in conjunction with others.”

While companies remediate thousands of vulnerabilities each month, it takes modern remediation best practices to handle the ongoing wave of new vulnerabilities detected to prevent a growing backlog of vulnerabilities. The increase in open-source vulnerabilities outstrips the estimated 25 percent growth in the amount of open source software available. With applications being the lifeblood of the global economy, regular application security scanning and use of prioritization and remediation tools are essential. 

When thinking of adjectives to describe cyberattackers, it’s doubtful that many people would choose to call them innovative – a term we’re more likely to ascribe to things we enjoy. But the reality is that adversaries are innovative, constantly finding new ways to launch attacks that result in greater rewards for less effort.

Yet many organizations continue trying to defend against attacks using status-quo security solutions maintained by IT and security departments that haven’t innovated. In those organizations, teams are siloed, slowing development times, reducing software quality, and increasing the risk of a major security event.  

In fact, 29 percent of CEOs and chief information security officers (CISOs), along with 40 percent of chief security officers (CSOs), say their organizations are unprepared to deal with impacts from the ever-evolving threat landscape, pointing to factors such as increased supply chain complexity, the fast pace of digital innovation, and lack of executive support.

Modern application programs need a security culture that promotes collaboration between these teams. The organizational structure for developers and security  teams needs to reflect that they are working together to accomplish a well-defined set of goals, and they all need to be on the same page about what’s needed. 

This is especially important given the multitudinous challenges faced by IT and security teams, including dramatically increased speed and complexity in software supply chains. Today’s software development pipelines are more complicated and automated, relying more heavily on third parties within the software development lifecycle (SDLC), meaning there are more systems and infrastructure to safeguard. Likewise, these changes have created a much larger and constantly changing attack surface for which application security (AppSec) teams are responsible. 

The only way for organizations to overcome these challenges and ensure application resilience is to create a robust DevSecOps environment. In this collaborative environment, teams can develop the best way to balance resources and ensure that critical security issues are addressed. Successful DevSecOps teams have a shared-responsibility mindset regarding security across the organization, and that mindset is backed by executive leadership. It’s an environment built on effective communication, with strong feedback loops and promoted by security champions from throughout the organization.

As organizations move away from siloed, ineffective IT and security departments, they’ll be able to achieve greater results in combating cyberattacks. One of the natural results will be development of and greater dependence upon cyber resilience.

Learn more about what IT and security teams can do to prevent application attacks by downloading a copy of the white paper today.