Launched as an internal project by Spotify in 2016, Backstage was released under the Apache 2.0 open source license in 2020 to help other growing engineering teams deal with similar challenges. Backstage aims to provide a consistent developer experience and centralize tools, documentation, and services within a single platform.

What started as a way to help new developers onboard faster is now a fully fleshed out developer portal that standardizes how teams interact with their internal services, APIs, and resources. Backstage includes features for service catalogs, continuous delivery, observability, and plugin integrations—all customizable to fit specific workflows.

For application security teams, Backstage offers wide views and controls across the development process and with the Mend.io plugin, deep insights into application risks overall or by project, too.

Mend.io for Backstage

Switching across multiple tools and projects isn’t just annoying, it can also lead to potential security blindspots and delayed response times. Likewise, missing opportunities to address vulnerabilities early in the development process can lead to costly rework, delays in releases, and vulnerabilities in production.

We want to save you from that trouble and consolidate security information from SCA, SAST, and Container scans into a single view within Backstage, providing you with a comprehensive overview of projects’ security.

We built the Mend.io plugin for Backstage to help you:

• Stay where you are with integrated projects overview. We love our own UI, but we want to be wherever it is that you need us to be. Mend.io’s centralized project dashboard within Backstage provides visibility into each project and its security findings, giving a complete view of a project’s threat landscape.
• Zoom in for detailed findings or zoom out for the big picture. A proactive approach to application security requires insights to make broad strokes and fine lines. Mend.io’s findings overview dashboard drills down into identified risks for a deeper analysis right within Backstage and shows all identified vulnerability findings across your organization.
• Work on what matters with risk severity prioritization. Vulnerabilities are not all created equal and treating them that way is a waste of resources. The Mend.io plugin for Backstage displays the severity level of each identified threat to effectively prioritize remediation of the risks that matter most.
• Bring security directly to developers. Encouraging developers to take on ownership of security with enthusiasm starts with minimizing the disruptions security tools add to their environments. The Mend.io plugin for Backstage embeds security information directly into developers’ workflows and presents security scan results in a clear and concise manner, making it easier for developers to understand and remediate issues.
• Nip vulnerabilities in the bud. Help developers stay proactive with application security. The Mend.io plugin integrates security checks early in the development process, enabling developers to identify and address vulnerabilities while they’re still fresh.
• Keep track of the difference you make. It’s difficult to assess your security posture and demonstrate your team’s accomplishments to stakeholders if you lack clear metrics and insights. The Mend.io plugin for Backstage provides important metrics and reports to track security progress and demonstrate the effectiveness of security efforts.

Keeping applications secure is a tough job and Mend.io is here to assist you wherever you’re doing it.

Adding the Mend.io plugin to Backstage

Installing the Mend.io plugin for Backstage is simple. All you need is a simple script to install the back-end plugin plus a Mend.io API token. Information on both and everything else you need to get started can be found on the plugin installation page.

Knowing what you’re working with

Modern applications make use of thousands of third-party components, mostly but not entirely open source software (OSS), and it’s critical to keep track of them. That’s why, in theory, an SBOM is great. Requiring an SBOM seemed like such a good idea that both government agencies and customers started insisting that everyone have them. You get an SBOM, you get an SBOM, everyone gets an SBOM! 

However, once everyone started getting SBOMs, a new problem arose: what do we do with these things, anyway? While an SBOM is important, when you just get a list of all the components that are in your code, it’s incomplete information that isn’t actionable. 

In order to make SBOMs really useful, security pros needed something else—something to contextualize the mass of findings in an SBOM to help them understand what was really concerning and what was just a false alarm. As Frank Costanza once said, there has to be another way.

Streamlining risk management 

Thankfully, there is another way– VEX (Vulnerability Exploitability eXchange). VEX is a framework for communicating the exploitability of known vulnerabilities in the context of where and how they are used.

SBOMs enriched with VEX data make it easier for organizations to prioritize risk management by providing actionable insights into the exploitability of vulnerabilities. This allows your business to allocate resources effectively and focus on addressing the most critical risks.

A VEX producer can designate vulnerabilities as:

• Exploitable – This means a vulnerability can be used by attackers in the current implementation and needs to be remediated ASAP. This is what your immediate focus should be on.

• Not exploitable – While the vulnerability exists in theory, factors like how your application is configured mean malicious actors cannot access it, rendering the vulnerability harmless.

• Fixed – A vulnerability existed, but a mitigation or patch has already been applied.

• Under Investigation – This notation means further analysis is required to determine how exploitable this vulnerability is. Once you’ve dealt with the exploitable vulnerabilities, you’ll want to look into these next. 

With VEX, instead of just having the SBOM data of software dependencies, you also have information about the specific vulnerabilities within the code that you’re using and whether they actually need to be addressed. It saves you the time and dev hours tracking down false positives and prioritizing the biggest risks first, overall providing a lot more value to an SBOM.

Notes about what steps have been taken or need to be taken can also be included in the VEX. 

Additionally, documents in VEX format are machine readable (either CycloneDX or SPDX), allowing integration into asset management tools. This enables greater automation of risk management, once again saving time and ultimately, money.

VEX also includes actionable data about how severe a vulnerability is, whether mitigations exist, and if patches are necessary. The information provided by VEX allows security teams to determine how risky a vendor’s software truly is, which is impossible to know from an SBOM alone. 

Transforming SBOM with VEX

Having a method to consistently describe and share vulnerability data between organizations addresses some of the biggest headaches for security engineers. If the VEX data indicates that a vulnerability is non-exploitable because end users don’t have access to the affected function, it saves you the time of both tracking down that information and mitigating something that doesn’t need to be addressed imminently.

Say you scan your systems and discover 40 vulnerabilities within your software supply chain. Without VEX, you might spend days addressing all of them. However, with VEX data, you see that 10 of the vulnerabilities are non-exploitable, 20 of them are low severity and can be remediated later, while 10 are critical and exploitable. Now you’re able to prioritize the most severe vulnerabilities, schedule later remediations for the lower risk ones, and ignore the non-exploitable ones. Think of the time (and headaches) you’ve saved thanks to VEX.

Adopting SBOMs is an essential step toward modern software security, but without the right context, they remain incomplete. VEX is the key to transforming SBOMs into actionable, insightful tools. By providing crucial exploitability data, VEX allows organizations to allocate resources efficiently, reduce false positives, and focus on addressing real threats—saving time, money, and ensuring faster, more secure software deployments.

At Mend.io, we’re excited to offer SBOM exports enriched with VEX data, empowering our customers to turn their SBOMs into effective risk management tools. Interested in making your SBOMs more actionable? Schedule a demo today.

the latest Forrester Wave Software Composition Analysis Q4 2024 report

However, not every vendor approaches solving this challenge the same way. The Forrester Wave Software Composition Analysis Q4 2024, which evaluates 10 SCA vendors against 25 criteria, helps developers, engineers, and application security professionals better understand the leading solutions on the market so they can identify a tool that best fits their priorities. 

According to the report, SCA customers should look for software that “assists developers in remediating vulnerabilities and keeping libraries current, provides visibility into software supply chain risk, and prevents software supply chain attacks.” 

We’re honored to be recognized as a Strong Performer in the Forrester Software Composition Analysis (SCA) Q4 2024 report. Our top scores in over seven key criteria underscore our mission to help teams move from reactive to proactive application security. 

Our approach to software composition analysis

At Mend.io, we’ve always believed that gaining visibility into your open source components and securing the risk that comes with them shouldn’t be a laborious, expensive hindrance to development. 

We designed Mend SCA to go beyond simple detection and shallow coverage. It provides rich prioritization context and guidance, automated remediation, and elastic scalability empowering our customers to proactively secure their open source components and software supply chain. 

We’re thrilled to see our top-scoring criteria reflect our ethos and approach to empowering security teams to shift from reactive to proactive security. We received the highest scores across the following criteria:

• Prioritization and reachability
• Remediation and automation
• Malicious package detection
• Language support
• AI component analysis
• Pricing flexibility and transparency

Let’s explore how our approach aligns with our top scores.

Go beyond simple detection and coverage

Mend SCA received the top scores in:

• Language support
• Malicious package detection
• AI component analysis

With a profusion of vulnerabilities to manage and a shrinking amount of resources, AppSec teams need their SCA tools to go beyond simply identifying vulnerabilities. Mend SCA makes this possible with extensive coverage across 200+ programming languages (for both security vulnerability and compliance/licensing analysis), 30+ package managers, and coverage for containers (Docker containers, Kubernetes, several registries), and Linux OS. 

When Mend SCA scans your code, it not only inventories and analyzes your direct and transitive dependencies for vulnerabilities but also surfaces essential risk context, including reachability, exploitability, malicious package insights, and license and compliance issues. This gives you the insight you need to understand the risk likelihood and impact and prioritize and remediate risks appropriately.

“Mend.io pioneered reachability”

Prioritize with context and automate remediation

Mend SCA received the top scores in:

• Prioritization and reachability 
• Remediation and automation

Developers, engineers, and AppSec teams must cut through the noise and understand, “What is a critical risk to me? What do I need to address right now? What is the best path to fix?”

Fusing risk-specific context (like application architecture, fix availability, open source health information such as library age, and CVSS 3 and CVSS 4 severity scores) with likelihood factors (like our best-in-class reachability analysis, malicious package detection, public exploit availability and maturity, EPSS scoring, production information such as whether an image is deployed to production), and impact factors (like customer defined labels or policies, compliance standards, SLAs), Mend SCA prioritizes your most critical risks and provides the best path to remediate. 

Unique to Mend SCA, each SCA finding includes the sink-to-source trace in code, package health data (like package age, adoption rate, data gathered on failure rates of builds between versions, and merge confidence ratings), risk reduction impact statistics, and the optimal upgrade path for your vulnerable package – the newest, most stable, least vulnerable library version that provides the most significant risk reduction.   

Automated workflows and auto-remediation options for newly discovered vulnerabilities make it easier than ever for our customers to remediate at scale, all without breaking the build.

“Autoremediation for newly discovered vulnerabilities is a strength.”

Scale without breaking the bank

Mend SCA received the top scores:

• Pricing, flexibility, and transparency
• Support services and offerings

The application security risk landscape is expanding and transforming at an insane rate. Add AI, ML, and LLMs into the mix, and it feels like we’ve unleashed Pandora’s box. While risk may expand exponentially… unfortunately, most budgets do not.

To remain secure and compliant, you need to be able to optimize and scale your AppSec programs with ease, including expanding and deepening security coverage. The Mend AppSec platform offers customers everything needed to build proactive application security through one solution at one price, meeting your evolving needs and budget constraints.

“Mend.io’s new pricing strategy is a strength: It offers one price for all products and services, including SCA, dependency updates, SAST, container security, and AI security, and it reflects the vision that customers need a holistic view of the application stack.”

Great things are on the horizon

The Forrester Wave states, “Mend.io is a great fit for enterprises that need an all-in-one solution for security, license, operational risk, and supporting services.” 

But we’re not done! As noted in the report, we’re in the midst of reshaping and transforming the Mend AppSec Platform so our customers have a unified, holistic view of their AppSec risk. 

A holistic approach allows findings to be correlated across the entire application attack surface. It enhances workflows and policies, integrates insights from additional tools, and ultimately enables our customers to proactively and significantly improve their AppSec posture.

Read the full Forrester Wave: Software Composition Analysis, Q4 2024 report to learn more about what to look for in a software composition analysis vendor and for additional information on Mend.io’s Strong Performer ranking.

The increasing reliance on open-source software coupled with the accelerated pace of software development has created a growing need for support of deprecated packages. The significant majority of open-source software packages are not actively maintained, meaning vulnerabilities are not patched, thereby leaving systems open to attack. Malicious actors often target deprecated open-source packages for this very reason. 

In addition to increased vulnerability risks, deprecated packages can become incompatible with modern systems or libraries. This leads to performance issues, making it more difficult to extend your application’s life. 

Using deprecated packages also increases your technical debt. The longer you put off replacing updated code, the more complicated it becomes to resolve the issues it incurs. 

This is why we are excited to announce an exclusive partnership between Mend.io and HeroDevs. HeroDevs NES (Never-Ending Support) keeps deprecated packages maintained, saving you the cost and hassle of migration while also keeping your software versions secure and compliant. 

Value of a joint partnership between Mend.io and HeroDevs

Mend.io helps developers keep their applications secure by identifying outdated and vulnerable open-source packages and providing recommendations for updating to newer, safer versions.  However, sometimes those updates don’t exist because the package is no longer supported. 

While developers are capable of fixing issues with deprecated packages they use, it is a risky, costly, and time-consuming task. That’s where HeroDevs comes in. They provide continued support for deprecated packages, ensuring there’s always a safe, updated version available.

Benefits of HeroDevs NES

By combining the power of the Mend AppSec Platform with HeroDevs NES, our joint customers achieve:

• Reduced Risk: The use of deprecated packages leaves applications at risk. Pairing the Mend AppSec Platform with HeroDevs NES proactively addresses vulnerabilities in deprecated packages, reducing the risk of data breaches caused by unmaintained packages.
• Increased Compliance: Compliance standards like PCI DSS, HIPAA, and GDPR require companies to take measures to protect sensitive data.  HeroDevs NES adds extended support to deprecated packages that can leave applications vulnerable to attacks, putting companies out of compliance.
• Time and Money Savings: Manually patching deprecated packages can be a time-consuming and expensive process for developers. HeroDevs NES provides upgrade paths for these packages, accelerating remediation, saving costs, and freeing developers to focus on building new features and delivering value faster.

With the power of both the Mend AppSec Platform and HeroDevs NES, you can rest easy that your software supply chain will be well-protected from vulnerabilities, malicious packages, and performance issues that stem from deprecated packages.

RAG adds some extra steps to typical use of a large language model (LLM) so that instead of working off just the prompt and its training data, the LLM has additional, usually more up-to-date, data “fresh in mind”.

It’s easy to see how huge this can be for business; being able to reference current company data without having to actually train an AI model on it has many, many useful applications. 

How does RAG work?

RAG requires orchestration of two models, an embedder and a generator. A typical RAG system starts with a user query and a corpus of data such as company PDFs or Word documents.

Here’s how a typical architecture works:

During a pre-processing stage, the corpus is processed by an AI model called an embedder which transforms the documents into vectors of semantic meaning instead of plain words. Technically speaking, this stage is optional, but it makes things a lot faster if the documents are pre-processed and accessed from a vector database, rather than processed at runtime.

When a user query comes in, the prompt is also fed to the embedder, for the same reason.

Next, the embedded user query is used by a retrieval system to pull relevant pieces of text from the pre-embedded corpus. The retrieval system returns with a ranked set of relevant vectors.

The embedded user query and relevant documents are fed into a generative AI model, specifically a pre-trained large language model (LLM), which then combines the user query and retrieved documents to form a relevant and coherent output.

Security risks with RAG

The two biggest risks associated with RAG systems are poisoned databases and the leakage of sensitive data or personally identifiable information (PII). We’ve already seen instances where malicious actors manipulate databases by inserting harmful data. Attackers can skew the system’s outputs by making their data disproportionately influential, effectively controlling the AI’s responses, which poses a serious security threat.

When implementing RAG, it’s essential to ask key questions: What models are you using for embedding and generation, and where are you storing your data?

Choosing the right models is crucial because different models handle security, accuracy, and privacy differently. Ensuring that these models are fine-tuned for security and privacy concerns or that services are blocking malicious behavior is key, as poorly selected models and third-party services can introduce vulnerabilities.

If you’re using a vector database like Pinecone or LlamaIndex, you must ensure that your data storage complies with security and privacy regulations, especially if you’re working with sensitive data. These databases store the map between the embedding and text, and ensuring that they are properly encrypted and access-controlled is vital to prevent unauthorized manipulation. Developers often choose platforms like OpenSearch, a low-code vector database solution, because it offers easier management of these security aspects, with built-in monitoring, access control, and logging to help avoid data poisoning and leakage.

In addition to model selection and secure data storage, all AI systems operate with a system prompt—a hidden instruction set that initializes every task or conversation. Adjusting this system prompt can help mitigate security issues, such as preventing the model from generating harmful or sensitive content. However, while strengthening the system prompt can help reduce certain risks, it’s not a comprehensive solution. A strong system prompt serves as the first line of defense, but addressing AI vulnerabilities requires a broader approach, including fine-tuning the models for safety, ensuring data compliance, and implementing real-time monitoring, code sanitizers, and guardrails.

In summary, securing a RAG system involves more than just selecting the right models and storage solutions. It requires robust encryption, data governance policies, and continuous oversight to protect against data poisoning, information leakage, and other evolving security threats.

How to protect RAG systems

Protecting AI systems, including RAG systems, requires a multi-layered approach that combines proactive testing, security mechanisms, and safeguards to prevent vulnerabilities from being exploited.

One effective strategy is to red-team your model. Red-teaming RAG systems involves simulated attacks to identify weaknesses in your AI system, such as prompt injection or data poisoning, before they can be exploited in real-world scenarios.

To protect RAG systems, there are several key approaches to consider:

1. Firewalls

In AI, firewalls act as monitoring layers that evaluate both input and output. They can use heuristic techniques to detect suspicious activity, such as attempts to inject harmful prompts or commands. For example, if a user tries to manipulate the AI to ignore its initial instructions (via prompt injection) and generate unintended or harmful output, the firewall can flag this as a potential attack. While firewalls provide an extra layer of security, they aren’t foolproof and may miss more sophisticated attacks that don’t match known patterns.

2. Guardrails

Guardrails are predefined rules or constraints that limit the behavior and output of AI systems. These can be customized based on the use case, ensuring the AI follows certain safety and ethical standards.

NVIDIA NeMo Guardrails offers several types of guardrails:

• Input rails filter and control what kinds of inputs are acceptable, ensuring sensitive data (like names or email addresses) is not processed.
• Dialog rails shape conversational flows to ensure AI responds appropriately, based on predefined conversation structures.
• Retrieval rails ensure the AI retrieves only trusted and relevant documents, minimizing the risk of poisoned data entering the system.
• Execution rails limit the types of code or commands the AI can execute, preventing improper actions.
• Output rails restrict the types of outputs the model can produce, protecting against hallucinations or inappropriate content.

NVIDIA Garak, another tool from NVIDIA, is an open-source red-teaming tool for testing vulnerabilities in large language models (LLMs). Garak helps identify common vulnerabilities, such as prompt injection or toxic content generation. It learns and adapts over time, improving its detection abilities with each use. Promptfoo is another tool that might be used.

3. Fact-checking and hallucination prevention

RAG systems can also incorporate self-checking mechanisms to verify the accuracy of generated content and prevent hallucinations—instances where the AI produces false information. Integrating fact-checking features can reduce the risk of presenting incorrect or harmful responses to users.

4. Shift-left security

A shift-left approach focuses on integrating security practices early in the development process. For RAG systems, this means ensuring that the data used for training and fine-tuning is free of bias, sensitive information, or inaccuracies from the start. Additionally, many RAG vulnerabilities may be in the code itself, so it’s worth scanning the code and organizing for fixes to take place before the production stage. By addressing these issues early, you minimize the risk of the system inadvertently sharing PII or being manipulated by malicious input.

Conclusion

As AI systems like RAG become more advanced, it’s critical to implement these protective measures to guard against an increasing array of security threats. Combining firewalls, guardrails, fact-checking, early security practices, and robust monitoring tools creates a comprehensive defense against potential vulnerabilities.

Fear of AI: A missed opportunity?

A long cultural history of sci-fi movies and books featuring all-powerful artificial intelligences that do not always have the best interests of humans at heart has scared many people away from using real-life AI technology in any form. Many at Mend.io believe this is a bad idea; workers and companies that shy away from utilizing AI miss out on the impressive capabilities AI tools provide and may be left behind. You may have already heard of large language models like ChatGPT, Claude, and Microsoft Copilot, as well as AI text-to-image programs like DALL-E and Stable Diffusion, and we think you should use them, but with a few security points in mind.

Just another tool (but a powerful one)

While AI might be more difficult to understand than other, traditional technologies, Maria Korlotian, Director of Development, points out that AI is merely a new tool and “not some mystical force beyond our control.” 

According to Maria, “Using AI isn’t fundamentally different from using any other everyday technology – it’s just more advanced. Think of it like a supercharged calculator. We don’t fear calculators because we understand their purpose and limitations. AI is similar, just with a broader scope of applications.”

“Right now, we’re in the early stages of widespread AI adoption, and that naturally causes fear and misunderstanding. But this is normal for any revolutionary technology. The key is to approach AI with curiosity, not fear. It’s hard to use a tool efficiently if you don’t know what to expect from it. We need to understand AI’s capabilities and limitations. As we become more familiar with AI, much of the current uncertainty will fade. It’s just another tool in our technological toolkit – incredibly powerful, yes, but still a tool designed to augment human capabilities, not replace them.”

Unpredictable (but worth the effort)

Others at Mend.io backed Maria on the values of AI. Bar-El Tayouri, Head of Mend AI, described AI as “much less predictable than traditional technology. Unlike regular code, which can be read and understood, an AI model consists of complex weights that make it difficult to predict its reactions and behavior. As a result, AI has much greater power and flexibility but requires careful regulation and guardrails to control its outputs.” Again, while AI might seem frightening to new users, the power and capabilities it brings to the table make it worth learning how to use.

Your brilliant (and potentially misunderstood) colleague

Rhys Arkins, VP Product Management, described AI as being similar to “a new, brilliant colleague with unlimited time to help you be successful, while at other times being the colleague most at risk of completely misunderstanding you.”

Yael Barnoy, General Counsel at Mend.io, agreed and called AI “revolutionary” because the uses for it “are unlimited and no prior knowledge is required to produce excellent content. Even children can speak to an AI model and write their own books complete with pictures by using currently available AI programs. Also, many AI programs are free and available to the general public.”

Tips for using AI safely

We asked our expert teammates what advice they would give to friends and family about using AI safely and compiled this list.

1. Don’t overly rely on AI without understanding its outputs. While AI can provide impressive results, trusting its suggestions without comprehension can lead to errors or misuse. Always strive to understand the reasoning behind AI-generated content or recommendations.
2. Check, double check, and triple check your results. When you use AI in your areas of expertise you see that the output isn’t always accurate. When you use AI for cases where you don’t have as much prior knowledge, it requires checking the facts with a reliable source. This is just like using a regular search engine – you will find some more reliable sources and less reliable sources. In addition, there are still some areas where many AI tools do not provide the required result but make up (“hallucinate”) results instead. Verify information before using it.
3. Avoid using AI for critical decisions without human oversight. AI should complement human intelligence, not replace it entirely, especially in high-stakes situations.
4. If you use AI to look clever internally, don’t hide it from others. You’ll still look clever for knowing how to use this tool effectively.
5. Don’t assume AI is objective or infallible. AI systems can inherit biases from their training data or design. Be aware of potential biases and critically evaluate AI outputs.
6. If you use it with any type of work material, use it only with an account your employer set up for you, unless you have explicit permission otherwise.
7. Never input private customer information into AI unless you have explicit permission internally.
   

AI is an exciting new tool that will help us all reach new heights. As long as you keep these basic cybersecurity principles in mind, you will be able to achieve great things and maintain your safety while using AI. 

Share this blog with friends and family who you think could use some tips on using AI safely.

Many teams think of DAST as almost an afterthought, just the dessert you may or may not order just before the software is released. But modern DAST solutions offer powerful insights necessary for a well-balanced security posture.

Why organizations sometimes restrict DAST scans

Before we get into suggestions on why and how to run DAST scans more frequently, let’s talk about why many organizations have limited their DAST scans. Typically, these reasons include:

• Time constraints. DAST scans can be time-consuming, especially in large applications. Many teams struggle to balance comprehensive security testing with the need to meet tight release deadlines.
• Misconceptions. Some believe that DAST is only part of QA or external pentesting processes.
• Manual intervention. Some DAST solutions require manual validation or configuration adjustments, adding extra work to already busy teams.

Despite these challenges, there are ways to integrate DAST more seamlessly into the development pipeline that allows teams to run more frequently and catch issues earlier.

Have your cake: the benefits of running frequent DAST scans

Running DAST scans once a quarter or only before a major release can create blind spots where vulnerabilities are introduced but remain undetected for extended periods. Here’s why running DAST scans more often makes sense:

• Early detection. Frequent scans allow teams to catch vulnerabilities as soon as they are introduced, rather than at the end of a release cycle when they may be more difficult and costly to fix.
• Updated feedback. Security testing should be proactive, not reactive. Frequent DAST scanning provides steadier, more regular feedback to developers, allowing them to address vulnerabilities in smaller and more manageable increments.
• Risk minimization. Every day that a vulnerability goes undetected, an application is at risk. More frequent scans reduce this window of opportunity for attackers, strengthening your application’s overall security posture.

Mend.io + Invicti

See how Mend.io and Invicti extend your AppSec coverage from code to runtime.

Download the solution brief

Adding DAST to your daily diet

To make DAST scans a more regular part of your development cycle, it’s essential to address the time, resource, and manual intervention barriers. We recommend the following tactics:

1. Automate DAST in your CI/CD pipeline

One of the most effective ways to run DAST scans more frequently is to integrate them into your CI/CD pipeline. By automating the process, you eliminate the need for manual scans, allowing DAST to run automatically whenever code is committed or deployed. Use incremental scanning to focus on only the recently changed parts of code, saving time and resources.

2. Use cloud-based DAST solutions

Traditional on-premises DAST tools can be resource-intensive, but modern cloud-based DAST tools offer scalability and flexibility. By leveraging these improved solutions, teams can offload the heavy lifting away from local resources.

3. Run scans in parallel with other tests

DAST can be integrated with other testing processes to run in parallel and reduce bottlenecks. For instance, while functional tests run, a DAST scan can simultaneously check for vulnerabilities. When DAST is integrated with other types of testing, teams can get a holistic view of both the functionality and security of their application in one go.

4. Collaborate with developers

Security is a shared responsibility. By working closely with developers, security teams can ensure that security is considered from the earliest stages of development. Frequent DAST scans help security teams provide more on-time feedback, empowering developers to write code that’s less likely to introduce new security issues in the first place.

Application security food groups: better together

Static Application Security Testing (SAST) offers a chance to find insecure coding early, before it goes anywhere near production, but some things still fall through the cracks. DAST helps teams discover vulnerabilities that make it into the build.

Utilizing both SAST and DAST frequently helps security teams stay on top of vulnerabilities and provide developers with crucial and on-time feedback about the security of their code.

With that in mind, Mend.io has partnered with Invicti to provide comprehensive solutions and pair Invicti’s DAST and API Security domains with Mend’s SAST, SCA, and Container Security solutions to give customers full code coverage and continuous security. One login grants access to everything you need from vulnerability scanning, analysis, and tracking. It’s like having a master key to the entire AppSec kingdom.

The Mend AppSec Platform’s platform-native design goes beyond the mere unification of multiple products to revolutionize various aspects of AppSec. Here’s how:

One platform experience

The Mend AppSec Platform offers a cohesive user experience that simplifies adoption and reduces training needs with the following attributes:

• Platform common data model. Build platform-level data classification and segmentation to manage assets
• Platform Application Program Interfaces (API). Third-party applications and integration can leverage any necessary data via API
• Open and extensible architecture. Mend AppSec Platform has two primary zones. The first provides shared platform modules, functionalities, and data visualization and the second contains back-end services for specific scan engines and the dashboard.
• Faster onboarding. New users can quickly adapt to the platform due to its intuitive interface and all-in-one approach for application security vulnerability management.
• Land-and-expand capabilities. Start with one or two products’ functionalities and easily add new functionality as your needs evolve, using consistent and extendable UI/UX concepts.

Simplified user management, authentication, and authorization

A consolidated platform offers effortless user access management across all application security tools. It eliminates the need for multiple logins and interfaces. A centralized control and access database means that one login grants access to everything you need from vulnerability scanning, analysis, and tracking. It’s like having a master key to the entire AppSec kingdom.

Find out more about the Mend AppSec Platform

A single platform that supports both developer and security teams

See the platform

Unified AppSec CLI and code repositories application with common platform capabilities

Empower your security champions and DevOps team with a powerful Unified AppSec CLI.

• Cross-product scans in one CLI  and ode repositories application. Perform quick SAST, SCA, and Container Security, AI Model scans with one CLI distribution and deployment
• Version management and maintenance. Centralized CLI version management with auto-update functionality for ease of pipeline maintenance
• Common platform capabilities. Streamline workflows and integrate seamlessly with platform workflow and policy-enforcement features with one policy and workflow automation gallery for AppSec as a whole.

Centralized analytics and statistics data based on new technology

Traditionally, security teams have been bombarded with data from disparate tools, making it difficult to identify trends and prioritize vulnerabilities. The Mend AppSec Platform offers a unified data hub for all security data, facilitating comprehensive analysis with insightful analytics that help prioritize vulnerabilities and optimize security posture.

A single data hub and automation streamlines workflows and policies

Consolidation fosters a unified data lake and data structures, eliminating data silos and inconsistencies to achieve contextual risk-based prioritization and assessment.

• Streamlined workflows. Automate repetitive tasks across various AppSec tools, boosting team efficiency with out-of-the-box risk-based policies
• Enforced policies. Centrally define and enforce security policies across the entire application development lifecycle
• Improved collaboration. Foster seamless collaboration between security and development teams
• Asset segmentation and classification. Leverage platform-level labeling for deeper segment and context-based insights, optimized workflow, and strict policy enforcement
• Data discovery as contextual risk data point across AppSec. Get deeper and wider insights based on your application inventory (i.e., code, packages, AI models, container images, and runtime information) for better risk assessment and prioritization
• Out-of-the-box risk-based policies covering compliance and security best practices. Pre-defined, industry-standard security policies and best practices, augmented with contextual risk data points, help organizations implement a robust threat detection, prioritization, and response framework. This secret sauce enables efficient identification and mitigation of potential vulnerabilities, enhancing overall security posture while optimizing risk assessment and resource allocation.

Open platform—API first and event-based processing

Moving towards an open event-driven architecture and API first unlocks a new level of integration and communication:

• Ease of integration and cross-product flows. Extendable design concept to add more scanners and vulnerabilities results for home-grown and third-party vendors
• Real-time updates. Security tools react to events in near real-time, ensuring data consistency across the platform
• Seamless integration Easier integration with internal products, third-party tools, and open infrastructure

Beyond the technology: Mend.io’s internal culture shift

The Mend AppSec Platform isn’t just about technology; it’s about fostering internal cross-team and department collaboration. Mend.io R&D inner-source practices are used to build and share platform components, and cross-team guilds are like Mend.io secret weapons. We share knowledge, best practices, and code, which has led to a higher velocity and effective alignment approach. Last but not least, to get closer to our customer-level experience, we are using the Mend AppSec Platform in our internal secure SDLC process.

A brief history of the KEV catalog

The KEV Catalog was created and is maintained by the Cybersecurity and Infrastructure Security Agency (CISA), a component of the Department of Homeland Security, and NIST, the National Institute of Standards and Technology, an agency within the Department of Commerce. 

In 2021, CISA issued “Binding Operational Directive (BOD) 22-01 – Reducing the Significant Risk of Known Exploited Vulnerabilities”, which requires all federal civilian executive branch (FCEB) agencies to comply with regulations to ensure protection of government systems and information from cyberthreats. These regulations include regular monitoring of the KEV catalog and remediation of all known exploited vulnerabilities included in the catalog within specific timeframes. 

Though it is not legally required for private sector organizations to follow CISA’s guidelines, all organizations with online applications and websites are strongly encouraged to regularly monitor the catalog to better protect themselves and their clients. 

How does a vulnerability get added to the KEV catalog? 

The KEV catalog only contains vulnerabilities that pass an evaluation process. When a new vulnerability is disclosed, it is typically assigned a Common Vulnerabilities and Exposures (CVE) ID and analyzed to determine potential impact and exploitation status. CISA then seeks feedback from security experts, federal agencies, and the private sector to gain insight into the vulnerability.

In order to be included in the catalog, the vulnerability must meet the following criteria:

• Evidence of active exploitation
• An assigned CVE ID
• Existing methods for remediation, typically from the vendor

 If the vulnerability meets these criteria, it is added to the KEV catalog with detailed information. Once a vulnerability is added to the catalog, information is regularly updated to include remediation guidance. It’s important to emphasize that vulnerabilities aren’t added to the catalog until there are ways to address them.

Prioritize with CVSS, EPSS, known exploits and reachability

See Mend SCA

Are all vulnerabilities created equally?

Though the government also maintains a National Vulnerability Database (NVD) with over 160,000 CVEs, the majority of potential vulnerabilities have no known exploits in the wild. Research from CISA indicates that less than four percent of CVEs have been exploited. However, once a CVE is exploited, threat actors move quickly, which is why regular monitoring of CVEs and their exploit status is important. 

While a vulnerability may be known to many within cybersecurity, it does not typically warrant action until a public exploit is discovered. Academics frequently release papers on potential ways an exploit could be performed, but it cannot cause harm until an exploit is performed in the real world. The KEV catalog helps filter out theoretical threats from active threats by only including vulnerabilities with known exploits. 

Are all actively exploited vulnerabilities in the KEV catalog?

No, not all known vulnerabilities are reported through the CVE process, even though they could be, and will thus not be included in the KEV catalog. It’s also likely that some known and unknown vulnerabilities are being actively exploited right now, but no one has discovered it yet. Other things we sometimes think of as vulnerabilities, like malicious packages, cannot be reported through the CVE process so they won’t show up in KEV either. But if you’ve installed a malicious package, there’s no question on whether it’s exploitable or not–you are actively under attack.

Prioritizing with known exploits 

The KEV catalog can make it easier to determine which exploits should be addressed first. Though a CVE may have a critical severity score, if it has no known exploits, it is less of a threat than an CVE with a medium threat severity score that is listed in the KEV database, as that means there are active exploits for it. A CVE that has active exploits should always be prioritized over CVEs with only theoretical exploits. 

While the KEV catalog is not the end-all, be-all of application security, it is an important tool for those within application security. Utilization of exploit information such as data from the KEV catalog, in addition to other vulnerability metrics, including Exploit Prediction Scoring System (EPSS) and Common Vulnerability Scoring System (CVSS), can aid any organization in strengthening their application security.

Application security is the combination of tools, practices, and policies that are used to protect the application layer of software from threat actors. Once something of an afterthought, application security is now widely and rightfully recognized as a vital part of the software development life cycle (SDLC). As the complexity of technology increases, considering application security early and often in the SDLC is imperative to keeping data and resources from falling into the wrong hands.

This straightforward guide will help you build a better understanding of application security and the tools and practices your organization can use to stay protected. 

Why is application security important?

Globally, the average cost of a data breach in 2023 was over 4 million. For US companies, that number was over 9 million, according to IBM.  The Verizon 2024 Data Breach Investigations Report found that web applications are the top hacking vector in breaches. The cost of ignoring application security is high.

Beyond the painful enough money loss, the good reputation of a business that took years to build up can crash in the blink of an eye after a serious security failure. In 2017, Equifax suffered one of the worst data breaches in history. The following year, after compiling financial data and several customer surveys, USA Today declared Equifax “The Most Hated Company in America” Ouch.

Virtually all businesses, not just those in tech, now use software to run their daily operations, ultimately meaning that application security, or a lack thereof, affects nearly every human on the planet.

• Global average cost of a data breach:  > $4 million
• U.S. companies: > $9 million
• Top attack vector: Web applications

The major challenges of AppSec

Protecting applications isn’t for the weak. Here are some of the major challenges to keeping apps safe today.

App + Sec relationship status: It’s complicated

A vast, sprawling, and complex landscape filled with vulnerabilities at nearly every twist and turn, the application layer is the top infiltration spot for bad actors in search of valuable data and other assets. The increasing complexity of applications and the systems and architectures they connect to makes securing them properly a real technical challenge.

Third party woe

Modern software is rarely built entirely from scratch. Rather, modern software is composed, often by about 80% existing open source and third-party code and 20% custom code to bind it all together and add a layer of innovation. Open source code by definition is freely available to examine and is used by many people, making it an extremely inviting vector for bad actors. Code from a vendor may be more obscured but as the SolarWinds hack showed us, can still provide a major attack surface.

Who, me?

A frequent challenge to application security lies in intra-organizational confusion about who exactly is responsible for it. This ends up with a lot of pointed fingers and not a lot of positive action. Unsurprisingly, the answer to who is responsible is “everyone” but that really must start with the people controlling the budgets.  Taking security seriously starts with funding the tools needed to do a good job.  

Deep in technical debt

We all love our old software, still functioning and bringing in money, but aging software is especially prone to accruing large amounts of technical debt, which leaves applications insecure. Shortcuts made to keep up with shrinking software release cycles are another source of technical debt and security weaknesses. Finding the time and will to pay down the debt can be a struggle for many organizations.

Application security best practices

From how you organize your company to how you write a single line of code, there are many ways to practice great application security. The application security best practices here are just a few high-level suggestions to get you going.

Work together

Not to be cliche, but teamwork really does make the dream work. If application security is not already a part of your organization’s culture, here are some things you can do to get started.

Bring down the firewalls between development and security teams

Name one or more members of your development team as security champions. Security champions are active members of a development team that serve as security ambassadors within their team. Security champions also provide visibility of their team’s security activities to the application security team, and often  the point person between developers and a central security team.

Incentivize developers to use security tools

As a group, devs may not be particularly well known for their people skills, but they do know something about human nature: people don’t like to do things that are repetitive or tedious. In software engineering laziness is a virtue, so meet developers where they are and give them tools to work smarter and minimize busywork–tools that are embedded right into the work environments they’re already using and coding within.

Manage privileges

For all the silos you should knock down to integrate your team into a lean, mean DevSecOps machine, you should be bringing up walls when it comes to user privileges. Make sure that users across your organization are restricted to only having access to the data they absolutely need, so you can reduce your attack surface from security concerns from both within and outside your organization.

Know your stuff

It’s difficult to protect something that you aren’t aware you have, and it’s also not so easy to convince people you’re doing something if you aren’t even sure yourself. It’s time to clear the fog. 

Track assets

Tracking your assets simply means knowing which hardware and software you’re using and what they’re doing.  

While you’re taking stock, it’s a good idea to note and prioritize those things that:

• Access vulnerable networks (like the public internet)
• Access personally identifiable information (PII)
• Access financial information
• Are subject to regulation
• Are public facing
• Are crucial to business function

You should have a record of all of the code, open source and custom, that your products depend on, all of that code’s dependencies, and all of those dependencies’ dependencies, and… you get the idea. Another great reason to create and keep updated SBOMs.

Model threats

Malicious actors care about what you care about. Now that you have a good idea of what’s important, you can start looking for ways they might try to get it for themselves.

If you’ve never threat modeled an application before, here are the basic steps:

1. Document how the application functions, focusing on the flow of data through the application.
2. Find threats against the application by following the flow of data and identifying places weak to certain exploits (attack databases work well here).
3. Address threats by rating them and deciding on mitigation strategies.
4. Validate the model to make sure you didn’t miss anything.

Define your metrics—know your risk, track your efforts

Quantifying and tracking security isn’t always a straightforward task, especially when the best security is done before there’s even a problem. But having good numbers for your efforts, results, and risk profile is essential to making good decisions and justifying your work. Which metrics to track and how to track them are very organization-dependent, but consider measuring:

• Risk. Use this basic formula: Risk = Probability of attack X impact of attack
• Time spent on education and estimated number of issues prevented
• Percentage of process made to be automated over time
• Number of issues kicked back to developers
• Average time for developers to fix an issue

Shift left, shift everywhere, shift smart

Sometimes even agile organizations find themselves administering security to the tempo of an old school waterfall pipeline—a software idea is born, a team of developers writes it into being, and then the big bad security team finds numerous flaws that need to be addressed by the devs before release, causing a major break in flow and a bottleneck in the SDLC. There is a better way.

Shift left – design with security in mind

The rumors are true: the beginning is in fact a very good place to start. “Shift left security” means moving security considerations as early into the SDLC as possible and that should mean right into the very design and conceptualization of a product. One way to achieve this is to define your security policies right from the start to set consistent boundaries and create efficient development processes.

Shift everywhere – make security a part of every stage of development

But wait there’s more! There are many spots in the SDLC where security can and should move left. Bringing security testing into the early development stage, as code is created, is preventive care that immediately translates to time and money saved. But don’t stop there. Use your security champions to ensure that security concerns are addressed regularly throughout development processes.

Shift smart – automate security and minimize false positives

Done correctly, shifting security up, down, and all around shouldn’t slow production. Add a dash of automation, and you might even find development speeding up. Tools are really the driving force behind shifting smart. Find the right tools that automate security and give developers just-in-time feedback that allows them to remediate security concerns without requiring them to become security experts themselves.

Find out more about the Mend AppSec Platform

A single platform that supports both developer and security teams

See the platform

Application security assessment

It is important to perform an application security assessment in order to evaluate and understand your true risk and to create a plan for addressing security issues. A full application security assessment includes identifying sensitive data, threat modeling, mapping out your applications to identify which areas will need which types of security tools, searching out gaps in your security process, and creating a security roadmap.

Vulnerability assessment

A vulnerability assessment is a systematic review process that uses vulnerability scanning to identify areas of an application that potentially need security improvements. This differs from penetration tests, which are usually more limited in scope but identify real and exploitable application vulnerabilities.

Popular resources for application security

Be comforted by the fact that you are not alone. A large number of individuals, teams, and organizations have dedicated their time and experience to bringing application security to all. Here we highlight some fantastic (and free) resources.

MITRE’s CWE Most Dangerous Software Weaknesses 

Using real-world data from the U.S. National Vulnerability Database and combining frequency and severity to determine rank order, every year this community-developed project puts out a list of the top 25 hottest, most on-trend software weaknesses.

OWASP Top 10 

Open Web Application Security Project (OWASP) puts out their own list that is unsurprisingly focused on web application security. It is well worth a gander as it particularly comprises low-hanging fruit that hackers love to bite.

The Linux Foundation

A hub of open-source activity, The Linux Foundation’s website is a wealth of resources including guides, webinars, research papers, and free courses.

OpenSSF

One of The Linux Foundation’s many projects, Open Source Security Foundation (OpenSSF) offers free training and certifications, guides, reports, and a robust community of security buffs.

MITRE ATT&CK Framework 

A major resource for threat modeling and beyond, MITRE’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) is a knowledge base and playbook of offensive moves and the defensive actions necessary to combat them.

Cybersecurity Framework from NIST

If you like comprehensive security frameworks, this one’s for you. Designed with the security of critical U.S. infrastructure in mind (and likely to become mandatory for some sectors), the Cybersecurity Framework from NIST is a well-organized body of standards, guidelines, and practices that can help any kind of organization stay secure. It is helpfully available in 10 different languages.

Some important application security tools

Perhaps someday there will be one tool to rule them all and cover the entire software supply chain, but as it stands, staying secure typically requires multiple application security scanning tools to get the job done well. As code changes throughout the SDLC, so do the tools needed to keep it secure. Here are a few stand-out tools to protect both your custom code and the third-party and open source code that makes up your software supply chain.

Application security testing

Application security testing is a market category that includes both security scanning tools and runtime protection and monitoring tools. Software composition analysis (SCA) is also part of this category but we’ve put it into a different section with other tools concerned with open source software.

Security scanning tools

• Static application security testing (SAST) – Implemented at the coding and testing stages of development, SAST tools analyze custom application source code from the inside out (“white-box” testing) and look for coding and design issues that may indicate security vulnerabilities, including old favorites like SQL injection, input validation, and stack buffer overflows. Because SAST tools are deployed at the development stage, before applications go live, the issues they find tend to be cheaper and easier to locate and fix than issues found later in applications that are already running.
• Dynamic application security testing (DAST) – A complement to SAST, DAST takes the opposite approach and tests running code for security vulnerabilities without any visibility into the source code (“black-box” testing). DAST is usually limited to testing only the exposed HTTP and HTML interfaces of web-enabled applications and takes a hacker’s rather than a developer’s perspective.
• Interactive application security testing (IAST) – IAST is designed to complement SAST and DAST. Like DAST, IAST is deployed in a QA or testing environment to test running code. Unlike DAST, IAST has knowledge of the post-build code and can identify the line of problem code and notify a developer for immediate remediation. IAST is not without its own limitations, however, as it does not scan the entire codebase, and coverage across all languages and platforms is still lacking. 

Application security monitoring tools

• Runtime protection tools are used in production and designed to defend against threat actors in real time. This market is segmented into web application firewalls (WAF), bot management, and runtime application self-protection (RASP).

Open source software security

Keeping open source software secure typically involves keeping components cataloged and up to date. Here are a few tools that help you do that.

Software composition analysis (SCA) – SCA tools manage the use of open source components by performing automated scans of an application’s code base (and related artifacts, including containers and registries) to identify all open source components, their license compliance data, and any known security vulnerabilities. Many SCA tools also detect malicious packages and enforce an organization’s policies on bringing new open source components into projects.

Automated dependency update tools – Automated dependency update tools scan repositories for open source dependency information, check for updates, then create pull requests for the latest versions.  

Cloud-native application security

Cloud-native applications have a lot of advantages in terms of scalability but they introduce a few unique security issues that new cloud- and container-specific security tools address.

Container image scanning – Container image scanners are similar to SCA scans applied to container image layers but with some container-specific twists. In addition to scanning for and reporting vulnerabilities at each image layer, they scan for misplaced secrets and configuration issues.

Cloud-native application protection platforms (CNAPP) – CNAPP consolidates a number of cloud security services into a single platform including container scanning, cloud workload protection, and runtime vulnerability and configuration scanning.

Trends in application security

Worldwide government interest in AppSec

World governments and legislatures across the globe have taken a strong interest in cybersecurity, particularly application security, in recent years. The Biden Administration’s 2023 Cybersecurity Strategy shows that the United States government is pushing for regulatory mandates relating to software used in critical infrastructure and the European Union, Australia, and many other governments have announced similar goals for cybersecurity. Meaningful progression security compliance may start with government contracts but it won’t end there. Civilian business consumers of software are also starting to demand more secure applications and transparency into what their vendors are doing to keep code safe.

Increased adoption of SBOMs

One way for vendors to provide that transparency is in the use of Software Bills of Material (SBOMs), machine-readable logs  that account for all software components, their dependencies, and their relationships. SBOMs take their name and function from traditional industries like automobile manufacturing where makers keep records of information about all of the parts in a machine. Should one of those parts get recalled, these manufacturers know which vehicles to call back to the dealership for repairs. So it goes with SBOMs. By keeping an up-to-date record on hand to be provided by regulators when requested, software companies are kept responsible for their products. Needless to say, governments are pretty excited about it, but companies should be, too. SBOMs are invaluable instruments for tracking a large breadth of code and finding vulnerabilities even before the authorities come knocking.

Automation becomes essential

Across the globe, the number of jobs for security professionals continues to rise quickly, while the supply of people to fill these jobs continues to lag. This leaves organizations with little choice but to train their developers in security and automate as much as possible. But even if your organization had a budget big enough to snag all the top cybersecurity talent in the world, modern software is so complex and is deployed so quickly that trying to address application security without automation is nearly impossible and definitely unrealistic.

Application security forecast

Finger to the wind, here’s what we think may be coming down the pipeline soon.

Increased demand for suppliers to not just provide SBOMs but list known vulnerabilities

With great maturity comes great responsibility. As the software industry matures, the expectation that vendors are responsible about securing their products increases. In the past, software customers often didn’t have security on the front of their mind, but things are changing. Expect to be asked not just for SBOMs but a list of known vulnerabilities in the near future.

FDA-type bodies to regulate software concerning critical infrastructure

Application security concerns don’t go away if one political party or another is in charge. World governments have stated their seriousness about cybersecurity in the last few years, but so far most of their statements remain only recommendations. We think an increase of hard regulation and the formation of regulatory bodies to monitor compliance is on the horizon.

Increased use of artificial intelligence and machine learning

AI and ML both hold great promise. Unfortunately that’s for the bad guys, too. As developers lean on more AI-written code, scanning for security concerns will become more crucial than ever. New issues beyond anyone’s comprehension a few years ago are sure to soon arise such as “hallucination squatting” where crafty malicious actors take advantage of AI’s tendency to hallucinate (i.e. make up) credible sounding sources of information like the names of open source repositories. On a happier note, the integration of machine learning into security tools will soon make triaging issues even better.

How Mend.io can help

The Mend Application Security Platform provides comprehensive security solutions for your entire codebase.

Mend SAST allows your developers to rapidly design new applications while maintaining the security of their custom code. With Mend SAST integrated right into your favorite DevOps environment and continuous integration/continuous development (CI/CD) pipelines, developers can easily evaluate the recommended code changes and approve them using a simple pull request.

Mend SCA detects open source vulnerabilities in over 200 languages, frameworks, and development tools. Like Mend SAST, it provides pull requests with automated remediation, enabling developers to update the recommended open source package with just a single click. Mend SCA also enables the easy creation of SBOMs.

Mend Renovate automatically resolves outdated dependencies saving time, reducing risk, and mitigating the impact of security vulnerabilities.

Mend Container gives you agentless reachability analysis for container vulnerabilities as well as secrets detection and Kubernetes cluster scanning to help make vulnerability prioritization simple.

Mend AI catalogs the AI models in your codebase and keeps track of their licenses, versions, and security alerts.

FAQ