As it turns out, the 52 percent of respondents that can keep up with vulnerability remediation tend to outperform those that can’t in several important areas, and it pays off.  These companies were nearly twice as likely to say they have not experienced any serious security incidents tied to a software vulnerability/web application exploit over the last 12 months. 

So what are some important differentiators?  Let’s take a look: 

Know what’s in your code. Better visibility into their code base gives companies better control over it. Organizations that report the ability to efficiently remediate vulnerabilities were much more likely to say they view being able to answer questions about their code as critical, including being able to document the composition of their code, assess where their code is stored, know their code’s provenance, and who has access to code components.

Embrace DevOps. The speed and volume of development means that the responsibility for security must now extend beyond just security teams. Security is increasingly shifting left, earlier in the software development lifecycle (SDLC), so it benefits from the involvement of development teams in a DevOps approach that incorporates security processes into development. Organizations that report the ability to efficiently remediate vulnerabilities were more than twice as likely to report they have extensively embraced DevOps.

Drive collaboration to build a culture of security. The overwhelming majority of companies with effective remediation programs — 93 percent — say that they encourage collaboration between application development, security, and operations to build a culture of security. With this culture in place, developers are more likely to willingly implement secure coding practices and work regularly with others to help protect their codebase. Organizations that promulgate shared responsibility create trust between developers and security and succeed in building stronger, more secure AppSec processes.

Indeed, the earlier the better.  Organizations that initiated collaboration during the “requirements and design” phase of the SDLC exhibited a lower average of 2.3 serious security incidents compared to 3.2 incidents experienced by organizations that engaged in collaboration only during the SDLC’s later stages. This highlights how effective early-stage teamwork can be in strengthening security, staying ahead of threats, and minimizing vulnerability-related risks.

Deploy automated tools.  Effective application security programs embrace automation. According to the report, organizations that can keep up with critical vulnerability remediation more often automate the identification and remediation of malware (83 percent) and configuration and software vulnerabilities before deployment to production (78 percent). It encourages developers to adopt best security practices by making security a seamless part of their workflow that’s easy to implement and adopt. Automation overcomes developers’ objections that security processes hinder them and drives the collaboration that’s so valuable for hardening security. 

What tools give you great AppSec?

Hardening your AppSec involves a combination of tools to comprehensively identify, update, and fix flaws, vulnerabilities, and threats to your code base. The most prominent are:

SBOMs. The research highlights the need to address third-party and open source software (OSS) because developers use vast libraries of this software to build their applications. Visibility is essential to achieving this. We’ve already noted the importance of understanding the provenance of code and where it’s stored. Organizations that do this well are much more likely to say that generating a software bill of materials (SBOM) is a mandatory part of their application development process.

SCA. Organizations that are confident about their security identify and remediate malware and vulnerabilities earlier in the SDLC. Nearly two-thirds of them (60 percent) use software composition analysis (SCA) to achieve this with OSS. SBOM inventory and audit capabilities are also key to addressing important issues of open source compliance. 70 percent of organizations confident in addressing and prioritizing critical vulnerabilities say they log all changes in software for compliance audits.

Dependency management enhances the job that SCA does for OSS by ensuring that the dependencies you’re using in OSS are updated so that vulnerabilities can’t impact your codebase. Automated dependency management makes this even more efficient. Unsurprisingly, 64% of organizations confident about their security implement dependency management.

SAST. Alongside these tools, 60 percent of these organizations are using static application security testing (SAST) or dynamic testing (DAST) to scan their proprietary code and identify and fix vulnerabilities. 

With this integration, Mend.io offers developers access to the security knowledge database of Secure Code Warrior® to help fix security vulnerabilities in their proprietary code. Whenever a developer commits to the repository the latest changes to their proprietary code, these changes are checked for security vulnerabilities by Mend SAST. For each detected finding, the specific Secure Code Warrior learning sessions and knowledge resources for this vulnerability type can be accessed by the developer with a single click on a link. This enables developers to find, and remediate vulnerabilities faster and more easily. It helps minimize the burden of securing code by integrating security within developers’ existing repository workflow, so that they can stay in an environment with which they are familiar.

What does this integration do?

Integrating with Secure Code Warrior® helps educate developers about security, encourages good practices, and drives their adoption by simplifying and facilitating access and use within developers’ workflow. Our integration empowers developers to understand risks and threats better, prioritize those that need addressing first, and help them take preventative measures before any threats become damaging problems.

“Our goals at Mend.io align with Secure Code Warrior® so it’s a natural integration. We’re both focused on promoting robust application security and making it as quick, simple, and seamless as possible for developers to implement. Together, we can amplify the importance of the organization’s security practices and tools, and optimize their use for a better overall user experience, higher productivity, and faster problem remediation that results in a stronger application security posture.”

Vered Shaked, Mend.io EVP, Corporate Development

Special features

Mend SAST with Secure Code Warrior® is fully integrated within the developer code repository, so that they can perform security procedures from the repo, rather than via links within the vendor web user interface, which is not the preferred environment for developers.   

Our solution focuses on differential results only. This means that developers can address the specific security issues that they introduced with their latest code changes and get the relevant training for them. They do not receive a long list of security issues and training links that are irrelevant and that they will never use. Consequently they can find, learn about and address the security issues relevant to them, faster and more efficiently.

Having it in the repo means that it is done in controlled / centralized way for all the enterprise developers with ability to monitor activity and improvements by managers.

Mend.io’s solution is housed in the repository, which enables it to perform and be deployed in a controlled and centralized way for all enterprise developers, and it enables managers to easily monitor activity and improvements to code.

Benefits

• Awareness: Increases developers’ awareness and understanding of the threats to their code and the vulnerabilities therein.
• Speed: Expedites the ability of developers to find, identify, and fix these vulnerabilities and threats as early as possible in the SDLC, before threats and flaws can become damaging problems
• Efficiency: Optimizes developers’ deployment of AppSec strategies and tools, which strengthens your security posture and enhances the effectiveness and efficiency of your AppSec program
• Simplicity and adoption: Easy to use within developers’ existing workflow, in their code repository, thereby lowering any barriers to adoption and maximizing its potential for use among developers.
• Prevention: Encourages a proactive approach to application security, which preempts and prevents issues rather than needing to respond to those that have already hit your codebase.
• Remediation: Facilitates effective assessment and resolution of detected security problems, enabling a dramatic reduction of software-related risk
• Versatility and scalability: A solution that grows with you, so you can successfully meet complex and large-scale application security needs, as they emerge.
• Productivity: All of the above benefits enable your developers to accelerate and enhance their productivity because the integration will enable them to produce better, more secure software and applications, faster and more confidently. Productivity is also improved by significantly reducing the likelihood of ineffective and inefficient handling of vulnerabilities.

Why is Mend.io launching this integration?

Our mission at Mend.io is to harden your application security and your software supply chain in the most seamless possible ways so you can improve the adoption of security best practices earlier in the software development lifecycle (SDLC). The need to shift security left and shift smart has become increasingly urgent because the volume of software components has expanded massively and deepened in complexity in recent years. This presents a much larger potential attack surface and escalating opportunities for malicious actors to exploit vulnerabilities and attack your codebase with malware.

Shifting left to address these threats requires developers to participate in implementing security strategies by using tools that enable them to do so simply. Successful modern application security can only occur when it’s integrated early into the SDLC and is easy for developers to adopt within their existing workflow. Developers simply won’t use tools that aren’t easy to use or those that require them to interrupt their development cadence, because they’re focused on maintaining productivity.

Mend.io is dedicated to empowering developers to strengthen their software and application security by creating ways to make the process as simple, intuitive and seamless as possible. This new integration of our SAST product with Secure Code Warrior® is the latest way in which we deliver on this promise.

As software delivery accelerates and the volume of releases increases rapidly, the risk from vulnerabilities and the threat of malicious packages grow, but the report, “Optimizing Application Security Effectiveness,” exposes some concerning findings about the readiness of companies to handle these issues. 

The scale of the problem

69 percent of organizations have experienced at least one serious security incident from a software vulnerability in the last 12 months.

Nevertheless, only 52 percent of companies say they can effectively remediate a critical vulnerability, and even fewer ― just 41 percent ― are confident in their ability to manage the security and compliance risks associated with open source software components used within internally developed applications.

Key best practices for effective application security programs  

Establish strong collaboration early

Organizations that report the ability to efficiently remediate vulnerabilities were much more likely to encourage collaboration between application development, security, and operations to build a culture of security (52% versus 34%). 

Shift security responsibilities left – with security support

Organizations able to keep up with vulnerabilities are 3.3x more likely to have extensively incorporated security into development processes.  These organizations are also more likely to have automated the identification and remediation of configuration and software vulnerabilities before deployment to production (78% versus 61%).

Security plays a centralized role

Companies that can efficiently remediate vulnerabilities were much more likely to say their security team is entirely centralized and separate from development teams (53% versus 30%).

Know what’s in your code 

Organizations able to efficiently remediate vulnerabilities were also more likely to say they view being able to answer questions about their code – such as knowing its source — as critical (49 percent vs. 31 percent).

Measuring program effectiveness: Preventing incidents

Finally, companies that can keep up with critical vulnerabilities succeed with the ultimate KPI for application security programs: lower security incident rates. Organizations that report the ability to efficiently remediate vulnerabilities were nearly twice as likely to say they have not experienced any serious security incidents tied to a software vulnerability/web application exploit internally developed applications over the last 12 months.

It’s this combination of aligning development and security teams, a full understanding of application composition, the adoption of DevSecOps, and the management of dependencies and risk that results in robust application security without compromising the speed of development.

Why is the OWASP API Security Top Ten important?

The API Security Top Ten focuses on application-programming interfaces (APIs), the bits of software that let two or more separate computer programs communicate and exchange information with each other. It sets out the categories of common flaws and weaknesses in APIs, particularly web-based APIs that communicate across the internet rather than through a closed network. It provides developers and security teams with an up-to-date guide to the most common and dangerous mistakes they could encounter that can cause vulnerabilities when building and maintaining web applications. APIs are vital to the development of software functions, and APIs for web applications are frequently sources of security vulnerabilities.

According to the foreword of the 2023 edition of the API Security Top Ten, “APIs are a critical part of modern mobile, SaaS, and web applications and can be found in customer-facing, partner-facing, and internal applications. . . By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII) and because of this, APIs have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.”

As APIs are a significant part of building web applications, reinforcing their security has become increasingly important to maintaining the integrity of organizations’ apps. So, the list is a useful reference for the DevSecOps community to know what to avoid during their builds.

Main findings

The report lists the top ten categories of weaknesses and then drills down into how exploitable, prevalent, detectable, and impactful each weakness is. It provides additional information on how each of these issues may arise, the sorts of problems each may cause, and the extent of its potential damage. It also provides ways to determine if an API might be vulnerable, examples of possible attack scenarios, and suggestions for how to prevent them.

The leading API security issues on the list are authorization and authentication, followed by access issues and unrestricted and unsafe consumption issues. The list identifies the full top ten as follows:

1. Broken object level authorization

Exposure of the endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues.

Exploitability: Easy. Prevalence: Widespread. Detectability: Easy. Impact: Moderate

2. Broken authentication

Authentication mechanisms implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Severe

3. Broken object property level authorization

Lack of or improper authorization validation at the object property level, leading to information exposure or manipulation by unauthorized parties.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Moderate

4. Unrestricted resource consumption

Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations. Successful attacks can lead to Denial of Service or an increase in operational costs.

 Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Severe

5. Broken function level authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. Attackers exploit these issues to gain access to users’ resources and/or administrative functions.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Severe

6. Unrestricted access to sensitive business flows

APIs vulnerable to this risk expose a business flow — such as buying a ticket or posting a comment — without compensating for how the functionality could harm the business if used excessively in an automated manner.

Exploitability: Easy. Prevalence: Widespread. Detectability: Average. Impact: Moderate

7. Server-side request forgery

These can occur when an API fetches a remote resource without validating the user-supplied URI. This enables attackers to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.

Exploitability: Easy. Prevalence: Common. Detectability: Easy. Impact: Moderate

8. Security misconfiguration

APIs and the systems supporting them typically contain complex configurations to make the APIs more customizable. Software engineers can miss these configurations, or don’t follow security best practices when it comes to configuration, opening the door for attacks.

Exploitability: Easy. Prevalence: Widespread. Detectability: Easy. Impact: Severe

9. Improper inventory management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation, and an inventory of hosts and deployed API versions highly important. Security can be compromised without it.

Exploitability: Easy. Prevalence: Widespread. Detectability: Average. Impact: Moderate

10. Unsafe consumption of APIs

Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. To compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.

Exploitability: Easy. Prevalence: Common. Detectability: Average. Impact: Severe

For further details of the main findings, visit the 2023 OWASP API Security Top Ten here.

What does this mean for application security?

APIs are critical to the digital transformation that huge numbers of organizations have undergone in recent years. Nevertheless, when it comes to application security best practices, they are often overlooked even though they are one of the biggest cybersecurity attack vectors. That’s because API security is commonly seen as separate from the overall application security posture of an organization.

APIs are vulnerable because they are exposed to the outside world and a lot of data that passes through the application layer, which makes it attractive to malicious actors. Plus, hacking APIs isn’t particularly difficult, so attackers can easily exploit APIs to perform a variety of damaging actions such as denial of service attacks on critical applications.

APIs are a way for attackers to get into your applications, and seriously disrupt them. Knowing what application risks and vulnerabilities to avoid is key to protecting them and helps you reinforce your application security.  

• Password creation and management
• Multi-factor authentication
• Updating software
• Recognizing and reporting phishing attempts

The campaign focuses mainly on educating end-users, but the issue of updating software also plays a critical role in securing code bases, software, and applications at the development level. At Mend, we’re proponents of shifting security left at the development stage ― implementing security measures as early as possible in the software development lifecycle (SDLC) ― and shifting security smart, by reiterating security best practice throughout the SDLC. This includes regular and frequent software updates, the most efficient of which are automated. Here’s why they’re so important.

1. Finding and fixing vulnerabilities

This is perhaps the most obvious factor. The older the software or the components, the more likely they are to have vulnerabilities that attackers will try to exploit, and attackers would have had more time to see if they can find, create, and use flaws to infiltrate your code and your systems. So, it stands to reason that you should regularly and frequently update your software because software updates often include patches for known and new security vulnerabilities. By applying patches when they are released, you can ensure that your codebase is protected as soon as possible, thereby fixing flaws and closing these avenues that malicious actors seek to exploit. Failing to update leaves your system exposed to potential attacks. So, implementing regular updates reinforces your security, and automating the process ensures that it happens frequently, regularly, seamlessly, and with little or no disruption to your development workflow.

2. Thwarting emerging threats

Hackers are always seeking new ways to breach cybersecurity. In addition to finding and exploiting vulnerabilities, they’re always developing new security threats and attack techniques, such as using malicious packages to disrupt and harm your software and applications. Automatic updates help you most efficiently stay ahead of these threats by delivering security fixes promptly. Without them, your codebase becomes a tempting target for attackers who know it’s not protected against the latest threats. Be mindful that businesses are using more software and applications than ever before, so manually updating them can be an arduous task. As codebases expand and contain increasingly complex interrelationships between components and dependencies, it becomes almost impossible to manually keep up with the updates necessary to keep them all as secure and efficient as possible. Under these conditions, automatic updates are vital to streamline the process, as they can handle a far greater volume of components than manual updates, and they can do so far quicker, more comprehensively, and with a vastly reduced risk of human error.

3. Maintaining compliance and improving governance

Companies in highly regulated industries such as finance, healthcare/pharmaceuticals, critical infrastructure, and defense, must assure their customers and their users that their software and systems are secure. That’s because these industries deploy software and applications that are used in highly sensitive environments, and hold valuable information, which malicious actors could abuse, ransom, or sell. Naturally, these companies are required to implement the most stringent security to comply with legal requirements and industry standards. Failure to do so can result in fines and legal consequences, above and beyond leaving them vulnerable to threats and attacks from hackers and other malicious actors that could seriously damage their business, or even worse, create perilous issues like threats to public health and national security.

Companies involved in merger and acquisition activity are similarly required by law and regulatory bodies to demonstrate robust security and account for the constituent components and dependencies in their software and applications. Furthermore, governments such as those in the U.S., the U.K., the EU, Australia, and New Zealand are leading the way with cybersecurity strategies that will demand more stringent software supply chain security and disclosure. Automatic updates can help ensure that you remain compliant with all of these guidelines and legislation, without constant manual intervention. They provide compliance with ease, by enabling the software updating and remediation process to happen in a way that doesn’t disrupt your development pipelines and your business as a whole.

4. Improving stability and performance

Software updates not only address security issues but also enhance stability and performance. In addition to creating conditions ripe for vulnerabilities, outdated software can lead to crashes, glitches, and slower performance, all of which can impact your codebase’s overall quality. Automatic updates help maintain a healthy and robust system and ensure that your software runs at peak efficiency. They optimize workflow and enhance productivity by minimizing interruptions caused by security vulnerabilities and performance issues.

And remember, keeping software up to date provides the latest optimizations and refinements from developers. So, software and application updates often include performance improvements, which enable you to work faster and more efficiently than using an outdated version. By extension, this means that the software and apps that you provide to your customers will also improve once you apply updates. Better, faster software means better performance for you and a better experience for your customers. That means happier customers, and that’s good for business. So, it makes sense to make updates as efficient and easy as possible, and that’s done by automating the process.

5. Building trust and confidence

Software updates also strengthen trust in your products and services. Organizations that provide complex software to their customers understand that their customers must have confidence in them. Reliability of performance and strong security are paramount. Any security breaches or operational issues arising from poorly updated software can damage your credibility with customers and threaten the relationship between vendor and customer. So, regular software updates are crucial. They demonstrate your commitment to providing the most secure and efficient technology. They reassure your customers that you’re the right choice of provider and that their security interests align with yours. Automating updates simply makes this important part of application security as easy and efficient as possible, and as such, it’s also good for business.

What is a vulnerability assessment?

A vulnerability assessment is a process of defining, identifying, classifying, and prioritizing vulnerabilities in your organization’s applications, systems, and network for the purpose of understanding your risks and formulating a strategy to improve your security.

At the core of vulnerability assessment is a reliance on automated testing tools that seek out known and potential vulnerabilities and bring them to the attention of security professionals and developers who can investigate and remediate as needed.   

Why is it important?

As recent major attacks like Log4j and SolarWinds have shown, the costs of a vulnerability can be very high. To stay secure, constant vigilance is needed, meaning good security practices require vulnerability assessment to be a repeated process, in some ways even daily, rather than a one and done.    

What are the main types of vulnerability assessments

As noted above, a vulnerability assessment should be carried out for all the elements of an organization’s infrastructure and assets. Attackers know that they have multiple routes of entry into an organization, so it is important to take a comprehensive approach that denies them access across the board. This requires the following types of assessment:

1. Host assessment – Take a hard look at hardware. Are your server, workstation, and laptop operating systems up to date with the latest security patches? Are your servers correctly configured with open ports properly protected with firewalls?
2. Networks and wireless assessment – Reports of the demise of the perimeter have been greatly exaggerated. Are you defining policies and implementing practices that will keep intruders from roaming freely around your network?
3. Database assessment – How we store our data matters. Is it configured correctly to keep prying eyes out? Mistakes in your AWS S3 or MongoDB configs can leave your precious info exposed, so you had better be sure that you are tracking all of your databases and confirming that they are being secured.
4. Application scans – Whether front facing or on the back end, applications are the gateway to your organization’s data, so you should use technologies for testing your proprietary code such as Static Application Security Testing (SAST), while Software Composition Analysis detects open source components with known vulnerabilities.

What is the vulnerability assessment process? How does it work?

The vulnerability assessment process can be broken down into four steps: identifying vulnerabilities, analyzing vulnerabilities, assessing actual risk, and remediation.

1. Identifying vulnerabilities — The first step is to use both manual processes and automated scanning tools to find all of the potential problems you are facing. The outcome of this step is a list of all vulnerabilities.
2. Analyzing vulnerabilities — Now that you have a list, it’s time to dive deeper into each vulnerability. What is the root cause of a particular vulnerability and which components of your infrastructure are responsible for it? This step should leave you with a good map of your systems and what remediation will be necessary.
3. Assessing risk — You can’t realistically fix everything at once. Assessing risk means considering how easily a particular vulnerability could be exploited, how costly an attack would be, and how critical the data, systems, and business functions affected by it are to your organization. Once you have completed this step you will have a prioritized list of vulnerabilities which brings us to…  
4. Remediation — Finally it’s time to go down that prioritized list and close the holes in your security. This step will likely require the efforts of both security and devops teams and may include updates to software, changes to configurations, and the development and implementation of vulnerability patches. 

Five vulnerability assessment misconceptions from the experts at Mend.io

Even if your teams are already running tests for vulnerabilities, they may be falling prey to a number of common misconceptions that can lead to costly mistakes.

We asked our vulnerability experts here at Mend.io about the worst misconceptions that they have seen, so that you can avoid them. 

1. Vulnerabilities are written with malicious intent

Despite the long-held belief among many security professionals, developers do not go out of their way to write vulnerabilities into their code. With very few exceptions, security vulnerabilities are simply bugs and mistakes by developers. Of course, malicious actors don’t care about developers’ intentions; they’re banking on them making mistakes and you not catching them. Cybercriminals may be a minority numerically, but their impact can be huge. It only takes one successful attack like SolarWinds or Log4Shell to cause havoc across multiple organizations.

Application security testing tools seek out these potential errors, flagging them for review before the software makes its way out to deployment.

2. It’s security or DevOps job to handle vulnerability assessments

Back in the day when new software was released once a quarter or so, it was perhaps more reasonable to expect that the security or ops teams alone could carry out vulnerability assessments. Developers just had to care about whether or not the product was working and out on time.

Those days are long gone. The concept of shifting security left has now gained traction and developers have the means to keep code secure themselves, meaning they can integrate automated vulnerability assessment tools into their coding environment to catch vulnerabilities early while they are still easy to fix. However, they need to do it at an unprecedented scale and speed. This can be challenging, when some may lack the familiarity and expertise needed to deal with the remediation of the vulnerabilities.   

3. You can shortcut security

It can be tempting to run a vulnerability assessment only on what you believe to be the most critical servers or layers of your network and call it a day. However, by leaving possible entry points into your environment open, you run the risk of being caught exposed. That said, prioritization does play an important role in planning what vulnerabilities to remediate. Do start with the systems that are the most critical to your business. Then work from there. Just make sure that everything gets some love and attention.

4. Your vulnerability assessment showed up clean, so you’re in the clear 

Sometimes the results of your vulnerability assessment scans will show up cleaner than expected. Take care! You may discover that your data is simply inaccurate. Check and see if it is consistent with past results. More likely is that other vulnerabilities are hidden in the indirect dependencies that you simply can’t see. 

Also remember that your vulnerability assessment only gives you a snapshot of where you stand at a specific point in time. New vulnerabilities emerge all the time, so you need to beware of them. Moreover, changes are always being made to databases or applications as they move through the SDLC.

That’s why you should run security testing continuously along with your assessments, adjusting as needed according to your findings.

5. Running a vulnerability assessment is the same as penetration testing

Vulnerability assessments and pentesting are not the same thing. Instead, they are a part of the same larger process in that the vulnerability assessment is the part that identifies potential weaknesses in your environment, whereas the pentest actually has someone poking around to see what will break.

In short, one step comes after the other, not in place of it. You need them both. An ethical hacker will run a proper vulnerability assessment to generate a to-do list of weaknesses that they should test out. Hopefully, they will use it as a starting point and have their own set of tests that can identify ways to break in, helping your team to remedy situations before someone not on your payroll decides to give it a try for themselves.

Although they complement each other, vulnerability assessment is generally less expensive than pentesting and should be done much more frequently. You can maximize your security spending by identifying and remediating all low hanging fruit through vulnerability assessment, leaving pentesting to take care of business logic flaws that may be missed by automated tools.

Some AppSec vulnerability assessment tools

The application layer is just one of many that need to be considered for your vulnerability assessment, but it’s a big one that takes a lot of effort and care to make secure.

For open source code

Open source code typically accounts for 60 to 90 percent of all code used in modern software products. If all code is equally likely to contain vulnerabilities, your open source components are naturally going to be the source of most of your vulnerabilities. Likewise, nearly all open source licenses require public disclosure that a particular open source component is being used, meaning malicious actors have insight into a large part of your codebase. 

So, performing vulnerability assessments on open source software is vital and the best tool for the job is Software Composition Analysis (SCA). When choosing an SCA, go for one with a low false positive rate and robust open source license tracking like Mend SCA.

For custom code

Even the best developers make mistakes sometimes. Custom code may be a smaller percentage of modern software but it still needs to be checked for vulnerabilities. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are two important and complementary tools for vulnerability assessments. SAST uses whitebox testing that integrates more readily into your continuous integration/continuous development (CI/CD) pipeline and can find security vulnerabilities even before code is fully functional. DAST, on the other hand, uses blackbox testing to check already built code for security issues.

For cloud

The SCA tool you pick should support cloud applications just as it does your on-prem code and be able to scan your containers and Docker images and find vulnerabilities in your cloud applications. Another concern for cloud-based application security is dependency management. Cloud applications rely on a lot of microservices which each have many dependencies which can become outdated and missing important security patches. You can easily scan your repositories for outdated packages with a dependency management tool like Renovate, while Mend SCA protects cloud-native applications throughout the software development lifecycle. 

Best practice for vulnerability assessment on enterprise networks

The scale and pace of enterprise networks make automation and comprehensive solutions a must. We know you’re busy so here are just two very brief pieces of advice to consider.

Get fully covered

Combine SCA and SAST tools to ensure that your entire codebase is comprehensively assessed and protected. Use one unified solution to simplify the process for yourself and for your developers.

Make security easy to adopt

Automate remediation by using tools that integrate seamlessly into your developers’ workflow. Don’t make them have to remember to launch a tool; make sure it’s already in their preferred repository, registry, IDE, package manager, or build tool.

Vulnerability assessment: Make sure all of your bases are covered

Running a vulnerability assessment is the first step towards making your organization more secure but remember that there is still a long road ahead. Now is the time to follow up on the results of your vulnerability assessment, combing through the findings and remediating vulnerabilities along the way.

Security expert celeb Bruce Schneider is famous for saying once that, “Security is a process, not a product,” underlying the fact that it is not enough to have products that can perform scans of your apps, networks, and systems. What is needed is for everyone in an organization to ensure that they are updating to the latest versions of the software that they are using and following other security best practices to stay a step ahead of the attackers. 

Just remember that good security is practiced on an ongoing basis, not just at quarterly security reviews.

Why has the landscape changed in the software supply chain?

First, more software and applications are being developed than ever before, with ever more complex chains of components and dependencies that have led to a rise in vulnerabilities and an increased threat of malicious packages. To demonstrate this, the Mend Open Source Risk Report recorded a 33 percent growth in the number of open source software vulnerabilities added to the Mend.io vulnerability database in 2022, which outstripped the estimated 25 percent growth in the amount of open source software available. And Mend Supply Chain Defender showed 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.

In turn, this has caught the attention of governments across the world from, the U.S. and the EU, to as far afield as Australia and New Zealand, leading to the second big trend, which is the introduction of governmental cybersecurity strategies and a recognition that regulation of the software supply chain is necessary to protect security on national, economic, public and private levels.

Why is dependency management important for securing the software supply chain?

Simply put, you can only protect your software and applications, identify issues, and then fix them if you know the following:

• What components and dependencies are in your software and applications
• Whether they are up-to-date and properly patched
• Whether open source third-party components and dependencies are compliant with the terms and conditions of their use
• Whether these components and dependencies are behaving as expected or are operating unusually
• If any others are being adversely affected
• What components and dependencies should and shouldn’t be there

Dependency management gives you the visibility you need to answer these questions and the capability to address any issues that you detect as a result. It involves identifying all dependencies used in your software, regularly monitoring and updating dependencies to ensure they are not vulnerable to known security issues, and maintaining a list of approved and unapproved dependencies.

How will escalating regulation affect the role of application dependency management?

More regulation means more accountability. More accountability requires increased visibility into the supply chain, comprehensive disclosure of components, dependencies, and any flaws and malicious packages that could threaten the stability and security of the software. So, the ability to catalog every component and dependency, identify threats and remediate them through a process of dependency management, becomes necessary.

With more stringent regulation and governance likely to be implemented, the transparency of software supply chain constituents becomes essential. Spearheaded by the likes of the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Five Eyes Alliance, government cybersecurity strategies will require any company working with federal, public, national, and international organizations to disclose all the components and dependencies in their software, applications and code bases. These strategies shift the responsibility to vendors, to both infuse security into their platforms and to declare any threats and vulnerabilities that they encounter. What has until now been voluntary best practice will become pre-requisites, and what begins with large public contracts will inevitably spread to the private sector, as vendors to federal and public bodies will demand that their suppliers in turn undertake the same level of due diligence.

What tools do you need to manage application dependencies effectively?

Effective dependency management involves the implementation of a prophylactic strategy that should include a combination of identification, detection, prioritization, updates and remediation.

Identification lies at the core of the regulations and strategies proposed by governmental agencies. It is the key to cataloging and knowing what components and dependencies exist within your software and applications, and it’s the foundation for accountability and transparency. You achieve this by using a software bill of materials (SBOM) and making it available to all your customers. The SBOM will not only provide comprehensive visibility into your code base, but it will improve your ability to detect anomalies, flaws, and vulnerabilities in your code which could be a threat. As a result, using an SBOM can reduce your time to respond and remediate any issues. As such, we anticipate that the SBOM will become a prerequisite tool for effective dependency management.

Having identified and detected any vulnerabilities, you need to update and patch your software regularly, frequently and in a timely manner, to ensure that it’s resistant to newly arising issues and attacks. First, you’ll need to employ a tool that prioritizes which vulnerabilities are most critical and should be addressed first. Prioritization optimizes the updating and remediation process, ensuring that you address dependencies that are most important to your code base, so that you don’t waste time on those that are unimportant or redundant.

Then you can move on to actively updating your dependencies, and you can do this most effectively with a tool that automatically applies updates when they are identified. Additionally, you can apply automated remediation to vulnerabilities that need to be fixed, using software composition analysis (SCA) for open source dependencies and static application security testing (SAST) for custom code. Automation slashes mean time to remediation, thereby making your dependency management as efficient as possible. Couple these tactics with a tool that prevents malicious open source packages from entering your codebase and the capability to apply governance and compliance policies, will redouble your security and your dependency management.

Ideally, all of these capabilities should be rolled into one comprehensive platform that brings all these processes together in a security package that operates seamlessly with your development workflow, maximizing security without sacrificing development speed or efficiency. 

That’s how you can ensure that dependency management plays the most effective role in securing your code base and meeting the requirements of increased due diligence that comes with more regulation and governance of the software supply chain.

Do you know what these vulnerabilities are? Have you got them covered?

With the help of some of the world’s leading cybersecurity authorities, you can be. To find out how, read on.

The Feds and the Five Eyes are looking out for you and your AppSec

The Five Eyes (FVEY) intelligence alliance has released a list of the top twelve most exploited vulnerabilities in 2022, in a new joint cybersecurity advisory published August 2023. The alliance involves the following federal and national cybersecurity agencies:

• United States: The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Federal Bureau of Investigation (FBI)
• Australia: Australian Signals Directorate’s Australian Cyber Security Centre (ACSC)
• Canada: Canadian Centre for Cyber Security (CCCS)
• New Zealand: New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team New Zealand (CERT NZ)
• United Kingdom: National Cyber Security Centre (NCSC-UK)

The list identifies Common Vulnerabilities and Exposures (CVEs) and Common Weakness Enumeration(s) (CWEs) that were most frequently used by malicious actors in 2022, plus thirty more vulnerabilities that were also routinely exploited.

What are the top 12 exploited vulnerabilities?

2022’s top 12 is dominated by vulnerabilities in Microsoft (4), VMWare (2), and Atlassian (2) software, plus software by Fortinet, Zoho, F5 Networks, and Apache. These include:

• Fortinet’s FortiOS and FortiProxy SSL VPN credential exposure critical (CVSS 9.1) vulnerability CVE-2018-13379, which has been on the list since 2018
• Microsoft’s Exchange Server Proxy Shell remote code execution (RCE) CVE-2021-34473, Security Feature Bypass CVE-2021-31207, privilege escalation CVE-2021-34523, and its RCE vulnerability CVE-2022-30190
• VMWare’s Workspace ONE Access and Identity Manager remote code execution (RCE) CVE-2022-22954 and Improper Privilege Management CVE-2022-22960 flaws
• F5 Networks’ BIG-IP Missing Authentication Vulnerability CVE-2022-1388.
• Atlassian’s Confluence Server and Data Center RCE flaw CVE-2022-26134, and arbitrary code execution CVE-2021-26084
• An RCE/authentication bypass CVE-2021-40539 in Zoho’s ADSelfServicePlus
• And last but by no means least, the infamous Log4Shell RCE in Apache’s Log4j2 product (CVE-2021-44228)

Details of these and the further thirty vulnerabilities are downloadable from the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

What can we learn from these findings?

This new list shows that hackers prefer to exploit older, unpatched security flaws more frequently than recently disclosed vulnerabilities. They prefer developing exploits for prevalent CVEs and they like to target unpatched, internet-facing systems, usually within the first two years of public disclosure, after which, the software is often patched or upgraded. And they prioritize vulnerabilities that are more prevalent in their specific targets’ networks.

What should you do to ensure you’re protected?

The most important action you can take is preventive: regularly update and patch your software components and dependencies. To that end, CISA advises that vendors and developers ensure that their software, its components, and dependencies are secure by design and default by doing the following:

• Identify repeatedly exploited classes of vulnerability, with an analysis of both CVEs and known exploited vulnerabilities
• Implement appropriate mitigations to eliminate those classes of vulnerability
• Ensure business leaders are responsible for security
• Follow the U.S. National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF), recommendations for mitigating the risk of software vulnerabilities, SP 800-218, and implement secure design practices into each stage of the software development lifecycle (SDLC)
• Prioritize secure-by-default configurations such as eliminating default passwords, implementing single sign-on (SSO) technology via modern open standards, and providing high-quality audit logs to customers with no additional configuration and at no extra charge
• Ensure published CVEs include the proper CWE field identifying the root cause of the vulnerability to enable industry-wide analysis of software security and design flaws.

CISA then advises end-user organizations to conduct the following

1. Vulnerability and configuration management

• Timely update software, operating systems, apps, and firmware on IT network assets
• Prioritize patching known exploited vulnerabilities, then critical and high vulnerabilities that allow for RCE or denial-of-service on internet-facing equipment.
• Replacing end-of-life software
• Routinely performing automated asset discovery to identify and catalog all systems, services, hardware, and software
• Implement a robust patch management process 
• Document secure baseline configurations for all IT/OT components, including cloud infrastructure
• Perform regular secure system backups and create known good copies of all device configurations for repairs and/or restoration.
• Maintain an updated cybersecurity incident response plan 

2. Identity and access management

• Enforce phishing-resistant multifactor authentication (MFA) for all users
• Enforce MFA on all VPN connections.
• Regularly review, validate, or remove privileged accounts
• Configure access control under the principle of least privilege

3. Protective controls and architecture

• Secure internet-facing network devices, disable unused or unnecessary network ports and protocols, encrypt network traffic, and disable unused network services and devices
• Harden commonly exploited enterprise network services
• Strictly control native scripting applications
• Implement zero-trust network architecture to limit or block lateral movement by controlling access to applications, devices, and databases
• Continuously monitor the attack surface and investigate abnormal activity that may indicate cyber actor or malware lateral movement
• Use security tools, such as vulnerability scanning and remediation solutions
• Use web application firewalls to monitor and filter web traffic, to detect and mitigate exploitation attempts when a malicious web request is sent to an unpatched device
• Implement an administrative policy and/or automated process to monitor unwanted hardware, software, or programs against an allowlist
• Use a network protocol analyzer to examine captured data, including packet-level data

4. Software supply chain security

When using third-party applications, ensure contracts require vendors and/or third-party service providers to:

• Provide notification of security incidents and vulnerabilities
• Supply a Software Bill of Materials (SBOM) with all products to enhance vulnerability monitoring and to help reduce time to respond to identified vulnerabilities
• Demonstrate how they are working to remove classes of vulnerabilities and to set secure default settings.

What tools can you use to protect yourself from these vulnerabilities?

You need to scan, detect, and fix vulnerabilities by using tools that can integrate into your development workflow, prioritize genuine threats, and automatically remediate issues, to make your AppSec and dependency management as simple and seamless as possible.

Ideally, use a platform that can perform all of these steps for both open source components and dependencies, and proprietary code, giving you the capability to:

• Automate your dependency updates
• Audit and secure your open source
• Identify, catalog, and account for everything in your software supply chain
• Defend your software supply chain from malicious packages
• Assure that your codebase meets compliance criteria

Initially, the choice might seem bewildering, but it helps to know that a great SAST tool possesses ten essential features that optimize its effectiveness in finding and mitigating security vulnerabilities in your software and applications. Identifying these characteristics will help you select a SAST tool that best aligns with your organization’s specific needs and they’ll enable you to best strengthen your security posture against attackers. So, what are the top ten qualities you should look out for when you’re choosing a new SAST tool? Let’s find out.

1. Repository integration for comprehensive coverage

Your SAST tool should be integrated with your repository to help you resolve security issues immediately and avoid long backlogs by hardening your application security posture throughout the development lifecycle. This enables your SAST tool to do the following:

• Gain direct access to the codebase, allowing it to analyze the code comprehensively and identify potential security vulnerabilities.
• Facilitate automated and continuous code scanning, which is essential in modern software development practices, such as DevOps and agile methodologies.
• Keep pace with code changes and updates, to detect any security weaknesses introduced during the development process.
• Identify vulnerabilities early in the development lifecycle, reducing the risk of security breaches in production environments.
• Understand contextual information, such as the structure, dependencies, and relationships within the codebase. This understanding enhances the accuracy of security analysis and reduces false positives.
• Promotes collaboration and communication between developers and security teams by providing developers with timely feedback on security issues directly within their development environment, thereby creating a proactive security mindset, enabling developers to address vulnerabilities early and incorporating secure coding practices.

2. One security solution, for all code

If you want to be sure that you have comprehensive security cover, then you need the capability to scan and fix both open source and custom code. Most individual tools do either, but not both, which means you have the challenge of choosing, integrating and operating separate tools into your workflow. That can get messy and it presents the possibility that certain vulnerabilities could slip through the cracks. Ideally you need a solution that solves this issue.

Look for a security platform that can detect and remediate issues in both your custom and open source code. A provider that offers both obviates the need to integrate separate, different tools, and overcomes the risk of inconsistencies that might arise from such an integration. At Mend, our SAST tool for custom code is complemented by our SCA tool for open source, so you can be confident that all of your code is secured by one security platform.

3. Integration with the development workflow

Your SAST tool should integrate seamlessly into your development workflow. It should offer integration options with popular development environments, build systems, version control systems, and continuous integration/continuous deployment (CI/CD) pipelines. CI/CD integration enables you to scan code at various stages, thereby encouraging both shift left and shift smart practices. And integration ensures that security scans are automated and conducted regularly as part of the development process.

In the event of security issues, a SAST tool integrated into the CI/CD pipeline can prevent build failures. Such integration empowers the tool to promptly alert developers when they commit code containing security vulnerabilities, providing detailed information on the vulnerability and instructions for remediation. This integration also helps mitigate the risk of insiders introducing backdoors into the source code.

4. Automated remediation

Traditional SAST tools only focused on the detection of vulnerabilities in custom code, not remediation. Although this was effective in identifying issues, it left developers and security teams with the challenge of what to do to fix the issues they found. At best, these SAST tools could only provide training materials and examples to support developers in researching fixes for each security issue they encountered. Often this meant implementing manual, time-consuming remediation methods, which couldn’t keep up with the pace of development. This inefficient process forced developers to choose between security and meeting deadlines.

When faced with escalating volumes of code, and increasing pressure on delivering software quickly, you need a SAST solution that can expedite the remediation of vulnerabilities. This is achieved with an automated process. Seek a next-generation SAST tool that provides automated remediation, presented directly in your developers’ repository, for easy integration into their workflow. As a result, the application security burden on your developers is reduced, while the security itself is improved and accelerated.  Then development teams don’t have to sacrifice security for speed and they can be more confident about delivering quality, secure code, faster, and with a better ROI.

5. End-to-end security: enabling shift left, with the flexibility to shift smart

Discovering coding flaws at an early stage significantly streamlines the process of fixing them. So, it is highly recommended to shift security testing from the later phases to the earlier stages of the software development lifecycle — the SDLC. A good SAST tool does this, by seamlessly integrating with your repo and existing developer workflows. Shifting left allows developers to identify and fix vulnerabilities early in the development process.

We advocate going further than this by deploying end-to-end security. Ideally, your security scanning program should be able to detect and remediate vulnerabilities at every step of the SDLC. This means that your tool does even more than shift security testing left. It also shifts smart, by finding and fixing issues wherever and whenever they occur in the development lifecycle, and it achieves this by iterating scanning and remediation repeatedly and continuously, thereby maximizing the strength of your application security.

Check that your chosen tool can shift security smart, additionally with the ability to enforce security policies across your entire organization throughout the SDLC, and monitor security violations.

6. Speed and accuracy

In fast-paced DevOps environments, scanning speed is paramount. When a SAST tool becomes a critical component of the pipeline, slow scans hinder developer productivity and may lead developers to commit code less frequently or attempt to bypass security tests. To address this, SAST tools can accelerate scanning by caching results, running multiple tests in parallel using multiple threads and delivering prompt results.

Accuracy is also vital. False positives pose a challenge for security-focused teams. Dealing with false positives consumes valuable time and can contribute to alert fatigue. Furthermore, they can divert the attention of security personnel from genuine security issues. A good SAST tool minimizes false positives, using sophisticated algorithms and heuristics to prioritize the issues that could impact your organization most severely, whilst maintaining high accuracy. This approach helps minimize false positives, accurately identifies real security vulnerabilities, and reduces the time and effort required to review and remediate the issues that could really affect you.

7. Language and platform support

Your SAST tool should support all of the programming languages and frameworks commonly used in your software and application development. It should be capable of analyzing the specific technologies, libraries, and frameworks your code relies on to identify vulnerabilities effectively. This ensures that it can effectively assess and detect vulnerabilities in applications written in multiple languages, such as Java, C#, Python, JavaScript, and more.

8. Reporting and analytics

Thorough reporting and analytics capabilities are crucial for understanding the security posture of an application. Your SAST tool should generate comprehensive, concise, and actionable reports that highlight vulnerabilities, and their severity, and recommend remediation steps. It should offer guidance on fixing vulnerabilities, including code snippets or links to additional resources that developers can use to address the identified security issues effectively. It may also offer trend analysis and metrics to track progress in addressing security issues over time.

9. Flexibility, customization, and configuration

Your SAST tool should have customization and configuration options. Different projects may have unique requirements and coding standards, so the tool should provide flexibility to adjust scanning rules, severity thresholds, and other settings to match configuration requirements. A flexible SAST tool allows customization to align with specific security policies and coding guidelines so that you can add custom rules and checks to address project-specific security concerns and meet your organization’s specific needs.

This can prove to be particularly important in certain industries where compliance with security regulations and standards is mandatory. A robust SAST tool should support compliance requirements and assist in auditing processes. It should include checks for common regulatory frameworks such as OWASP Top 10, PCI DSS, HIPAA, and more, and should have the capability to accommodate others as your codebase grows and diversifies.

10. Scalability, extensibility, and ease of deployment

The volume of components and dependencies within codebases continues to rise rapidly. As it does, the network of relationships between these components and dependencies becomes more complex, the attack surface grows, and the potential for vulnerabilities to proliferate escalates. Therefore, the scalability of a SAST tool is vital for large and increasingly sophisticated codebases, or projects with frequent code changes. Whatever SAST solution you choose must be capable of scaling up as your codebase expands with more components, updates, and the like. It must be able to handle complex applications efficiently and deliver results within a reasonable time frame. Scalability ensures that the tool can adapt to growing codebases and provide consistent performance.

These characteristics will keep your SAST strong

The cybersecurity landscape evolves rapidly, with new vulnerabilities and attack techniques emerging regularly. A SAST tool that demonstrates these ten qualities will serve you well now and, in the future, with the capability to keep up to date with the latest security standards and best practices. As such, it will be a valuable tool for assisting developers in their day-to-day activities, minimizing security risks, making the software and applications that you use and distribute safer and better for all users, and helping to ensure that your organization, your reputation, and your customers are protected from proliferating cybersecurity threats.

Brandjacking refers to the malicious act of using a brand’s identity to deceive or defraud customers. It usually involves impersonating a reputable brand to gain unauthorized access to sensitive information or exploit the trust associated with the brand. Attackers often leverage the reputation of well-known brands using social engineering techniques, phishing emails, fake websites, and malicious packages in open source repositories. Let’s look at how brandjacking works, the types of brandjacking attacks, the threat they pose to organizations’ and users’ security, notable examples of such attacks, and how application security tools and practices can help you overcome these risks.

How does brandjacking work?

Traditional brandjacking typically starts with the attacker creating a fraudulent website or social media account that mimics a legitimate brand. They may use similar domain names, logos, and content to deceive unsuspecting users. Then they use these means to collect personal information, distribute malware, or conduct phishing attacks by luring victims into sharing their credentials or financial details.

These attacks have also moved into open-source software repositories. Brandjacking is similar to typosquatting attacks, but in this method, threat actors name malicious packages in a way that fools people into thinking that they are associated with a well-known brand — in this case, a popular language library. This technique tricks developers into using fake packages, assuming they are the official ones. Once inside a code base the malware can spread their malicious payload, which can disrupt and disable systems and steal sensitive data. 

Different types of brandjacking attacks

• Domain spoofing: Domain names that resemble legitimate brands are used to host malicious content or trick users into providing sensitive information.
• Social media impersonation: Fake social media accounts mimic a brand’s official accounts, to engage with followers to harvest their data or redirect them to malicious websites.
• Phishing emails: Attackers send emails pretending to be from a trusted brand, requesting recipients click on malicious links, provide personal information, or download harmful attachments.
• Impersonation with malicious packages: Malicious packages are designed and named to resemble reliable open source packages, to exploit developers’ trust. When they’re downloaded, they infect and damage your code.
• Dependency attacks: Malicious code can be injected into existing, popular open-source packages by exploiting vulnerabilities or taking over abandoned packages. When other developers include these compromised packages as dependencies in their projects, they inadvertently introduce malware into their software.

What security threats does brandjacking pose?

Brandjacking poses three main security threats. The first is operational. The second is personal. The last is reputational. These threats are as follows:

• Operational: Attackers use brandjacked websites or email attachments to distribute malware, such as malicious packages, that can compromise or even completely disable an organization’s systems or networks.
• Personal/Financial: Brandjacking is an effective way of compromising users’ data. Attackers can steal sensitive user information such as login credentials, payment details, or personally identifiable information (PII), leading to financial theft and fraud.
• Reputational: When organizations fall victim to brandjacking, their reputation as a secure and reliable vendor or partner gets tarnished. Customer trust gets eroded, which can result in financial loss.

Examples of significant brandjacking attacks

In 2020, several high-profile Twitter accounts were compromised in a brandjacking attack. Attackers posted fraudulent messages promising to double users’ Bitcoin investments, resulting in financial loss and reputational damage.

In 2021, a sophisticated phishing attack targeted PayPal users, impersonating the brand through convincing emails and websites. The attackers stole login credentials and gained unauthorized access to users’ accounts, potentially compromising personal and financial information.

In 2022, a malicious npm package named “jquery-lh” successfully mimicked the popular open source JavaScript library jQuery. jQuery is downloaded over 4 million times per week from npm, because it’s versatile, and extensible, it works in a wide variety of browsers and its speed and richness of features significantly simplify numerous tasks such as HTML document traversal and manipulation, event handling, and animation. This offered potentially rich pickings for attackers.  Millions of users downloaded the malicious “jquery-lh” package, because it looked legitimate, with the potential to disrupt and damage a multitude of code bases and a wide array of software and applications.

How can you strengthen security against brandjacking attacks?

As with all types of security issues, protecting your organization and your users against brandjacking involves a combination of implementing best practices, establishing good procedures, and using the right tools to help identify and thwart them. Recommended procedures and best practices are:

• Continuous vigilance for brandjacking attempts, so that you can promptly take action. This includes monitoring for brand mentions on social media platforms and proactively taking down fake accounts.
• Conduct regular and frequent security audits to identify vulnerabilities in applications and networks, ensuring that all software is up to date and patched against known vulnerabilities.
• Leverage application security capabilities to reinforce these efforts.
• Education and training for employees regarding brandjacking attacks, emphasizing how to identify phishing attempts and suspicious websites.

Typically, the tools that you can employ to help you implement these procedures are:

• Secure authentication mechanisms, including two-factor authentication (2FA), to add an extra layer of security and mitigate the risk of unauthorized access.
• DNS monitoring identifies suspicious or fraudulent domain names.
• Social media account verification for official brand accounts to mitigate the risk of impersonation.
• Domain-based message authentication, reporting, and conformance (DMARC): Apply DMARC policies to prevent email spoofing and phishing attempts.
• Application security tools, like software composition analysis, Mend SCA, Static Application Security Testing (SAST), Mend Supply Chain Defender, and Software Bill of Materials (SBOM). More on these below.

How can application security tools help protect you from brandjacking?

AppSec tools are deployed to apply security at a different level than brandjacking. They are focused on the development level — safeguarding components and dependencies in the software supply chain. Nevertheless, a beneficial “by-product” of these tools is that they can play a role in protecting your organization from brandjacking. They do this by:

• Inculcating good practice. They promote a security-conscious culture that raises awareness of risks and ways to reduce them, by fostering vigilance for anomalous activity and encouraging organizations to take prompt action to mitigate any ill-effects. In particular, this manifests itself in the practice of continuous scanning undertaken by SCA and SAST, and keeping track of changes that can indicate vulnerabilities.  
• Improving visibility. This capability is primarily intended for identifying components used in a particular application or system. It includes details such as component names, versions, and sources. It helps organizations identify and validate trusted components, ensuring that only legitimate software is used. By maintaining control over the supply chain, you can reduce the risk of using fake, malicious software that may lead to brandjacking.
• Finding vulnerabilities helps prevent brandjacking attacks that exploit weaknesses in third-party components.
• Authenticating and authorizing issues and checking anomalies that may arise from brandjacking attempts could allow attackers to bypass authentication, gain unauthorized access, or manipulate user sessions. Mend SCA detects malicious packages in your projects and provides detailed information about the threats that they carry. Mend Supply Chain Defender prevents the installation of malicious packages from the earliest stages of the development cycle. These tools help reduce the chances of incorporating components from untrusted sources, thereby mitigating the risk of brandjacking.  And authentication practices can also extend to SBOMs’ vendor/supplier verification capabilities that assess the trustworthiness of vendors and their software. 
• Detecting code injection vulnerabilities. Brandjacking attacks often involve injecting malicious code into legitimate applications to exploit them for malicious purposes. These tools scan the source code for potential code injection vulnerabilities, such as SQL injection, cross-site scripting (XSS), or remote code execution, and they alert users to their presence.
• Uncovering insecure data handling and security exploits that could lead to brandjacking, including improper storage, transmission, or encryption of sensitive data, such as user credentials or personal information.
• Applying license compliance. SBOMs check and verify license compliance and keep an up-to-date inventory of all your company’s digital assets. Brandjacking may involve malicious actors distributing modified versions of your software that violate the licenses of the open source components you use. So, hand-in-hand with SCA, SBOMs help you document and monitor the licenses associated with the components used in your software. This way, you can avoid license violations and diminish the risk of brandjacking through license-related legal issues. 

By employing these AppSec practices and tools, you demonstrate a commitment to transparency, security, compliance, and accountability that builds trust with customers, partners, and regulators. You reduce the risk of brandjacking by proactively managing your digital assets, and your strong supply chain management can deter potential brandjackers from targeting your organization.

Beat brandjacking with a comprehensive security strategy

Brandjacking attacks pose a significant cybersecurity threat, potentially resulting in compromised user data, reputational damage, and financial loss for organizations. Preventing brandjacking requires a comprehensive security strategy that includes trademark protection, online brand monitoring, and proactive security measures. Organizations that prioritize employee education, implement strong authentication mechanisms, conduct regular security audits, and leverage the capabilities of a full suite of security tools and practices, are best placed to avoid the damaging consequences of brandjacking attacks.