Keeping Up with the Changing Pace of Development

In the past, software development mainly followed a waterfall approach- releasing software only once or twice a year. But the world has changed. Nowadays, cloud-native development often means releasing updates multiple times a day. This change in pace of application development has made speed a more important consideration. Sometimes, this comes at the expense of security. In Checkmarx’s upcoming survey on the state of application security, 91% of respondents even admitted to deploying vulnerable code to production. It’s no longer about finding everything but finding and fixing what matters most.

Up until now, companies had to choose — a developer-oriented SAST tool that risked false negatives – vulnerable code never being identified and unknowingly released into production – or security-oriented solutions which found everything, but often at the expense of speed and had false positives, making it difficult for developers to know what to fix before the next sprint.

Either/Or. Not both.

This led to further solution sprawl, as companies sometimes used an array of tools for their team – a “good enough” solution for less mature teams and enterprise-grade solution for their enterprise teams.

Until now. 

We are pleased to announce that our new SAST scanning engine will further improve an individual’s ability to customize their scanning capabilities, and experience speed, accuracy, and security.

Risk Reduction vs Ease of Use – Do I Have To Choose One?

Traditional SAST offerings force customers to choose between maximum risk reduction and ease of use (which finds less risk). 

With this new release, Checkmarx is the only solution that offers both in a single package, providing enterprises with the power and flexibility to secure their entire application footprint, and enabling a better developer experience

The new engine offers both in-depth security (to find maximum risk) and fast scanning (to cover every application with minimum overhead and noise). Users can choose the most appropriate configuration for each application based on that application’s requirements:

• Fast scanning to cover more applications to showcase relevant results faster
• In-depth scanning to find the maximum risk in critical applications with high business risk

I Already Have Checkmarx SAST. How do I Take Advantage of This?

If you already use Checkmarx’s SAST (whether on-prem or Checkmarx One), you can take advantage of these new capabilities today. It’s very easy to set this up (here’s how on the account and project level in Checkmarx One /  project level on CxSAST) Contact your account manager for more help or to have them walk through this with you.

The Best of Both Worlds: Development and Security Approved

This fast scan mode allows developers more flexibility in their fast-paced environment where they are constantly writing and updating code. They need scanning capabilities that can keep up with short sprints and continuous deployment by providing scanning that is exceptionally fast and provides only the most relevant results. Different apps have different risk-levels and criticality. Our new fast scan mode allows developers the ability to scan more frequently while highlighting the most relevant results so that they can focus on remediating the most important vulnerabilities. But, for mission critical apps, organizations can pick in-depth scan mode and get deeper scans and stronger correlation.

To further increase alert fidelity and reduce false positives, the Checkmarx team has developed another enhanced component: a base preset . The base preset focuses on the highest priority vulnerability queries to provide high fidelity results with reduced noise. As a result, it reduces total findings by up to 70%. The base preset was designed to boost scanning efficiency, prioritizing the swift retrieval of results with pertinent and impactful vulnerabilities. The preset can also be used as a starting point and customized to meet your specific requirements. It is available regardless of which mode – fast or in-depth – you use. 

The newly released scanning engine is used to optimize the SAST scans that are being executed to reduce overall scan time. This scanning engine further reduces scan times by tuning query parameters. 

The new scanning engine provides results that will support developers in their fast-paced development lifecycle. Through development and testing we have been able to provide up to a 90% reduction in scan time. This time saved is valuable and provides results that have shown to be higher fidelity. 

The Bottom Line

Up until now, users have had to choose – speed or security. This often led to sprawl, with multiple tools being used throughout an organization to meet the need of teams’ varied goals. Now, they can have both all in a single package – one vendor to deal with, one tool to learn, full transparency between security and development, and the flexibility to adapt as needs change. Checkmarx is the only solution that offers both in a single package.

Providing an application security solution that focuses on flexibility and high-fidelity results is what we are striving for at Checkmarx. This new release will provide reduced scan times with high quality results so that all members of your team can be successful – from the developers to the CISOs.

Key Points

• Abandoned digital assets are not relics of the past; they are ticking time bombs and attackers have been increasingly taking advantage of them, transforming them into trojan horses within the open-source ecosystems.
• MavenGate and CocoaPods case studies highlight how abandoned domains and subdomains could be hijacked to mislead users and spread malicious intent.
• Hijacking abandoned Rubygems package name case study emphasizes how abandoned package names could be hijacked and potentially used for malicious activities.
• Hijacking abandoned S3 buckets case study: The NPM package “bignum” is compromised through an abandoned S3 bucket, illustrating how attackers can stealthily replace necessary binaries with malicious ones.
• Email domain hijacking case study: Details the popular ‘ctx’ and ‘PHPass’ packages’ compromise due to reclaimed expired email domains.
• RepoJacking attack: Highlights a GitHub vulnerability where attackers hijack repositories by exploiting renamed usernames.

Mavengate: Hacker’s Ability to Leverage Abandoned Libraries to Hijack Java and Android Applications

An attack vector called MavenGate, revealed in January 2024, revealed a critical flaw in the way Maven-based technologies, including Gradle, manage dependencies.

This method enables attackers to hijack abandoned Java and Android libraries by acquiring expired domain names linked to these libraries.

Through those hijacked abandoned libraries, attackers could inject malicious code and potentially compromise the entire build process of projects that use those abandoned libraries as dependencies. This threat extended to all Maven-based technologies, including Gradle, affects a broad range of applications and services. And since the default build configurations of many projects do not account for this possibility. It leaves them open to undetected attacks.

Many Android and Java projects were found to be affected by the described problem including Companies like Google, Facebook, Amazon, Microsoft, Adobe, LinkedIn, Netflix, and over two hundred other companies.

Upon being notified of the issue, Sonatype, the owner of the mavenCentral repository, took action to address the problem. They blocked vulnerable dependencies and improved security in the Java ecosystem by implementing public key verification for uploaded artifacts. These actions will contribute to making the Java ecosystem a safer place.

Subdomain Hijacking: The CocoaPods Incident

In a notable cybersecurity incident, CocoaPods, a widely used dependency manager for iOS and Mac projects, faced a subdomain hijacking attack in 2023. In the CocoaPods incident, the attackers took control of the abandoned subdomain ‘cdn2[.]cocoapods[.]org,’ which still had DNS records pointing to GitHub Pages, and used it to host malicious content. This type of hijacking exploits forgotten settings on hosting platforms, with attackers using the reputation of legitimate domains to mislead users.

The following short demo video demonstrates this incident in action:

Hijacking Abandoned S3 Buckets

In a recent case of the NPM package “bignum,” in mid-2023, a significant security breach occurred through the hijacking of an S3 bucket. The attackers took control of an abandoned AWS S3 bucket previously used by the npm package, “bignum,” for storing binaries. They then replaced these binaries with malicious ones, effectively poisoning the package.

When users installed or re-installed “bignum,” they unknowingly downloaded these malicious binaries, which would ultimately steal the user IDs, passwords, local machine environment variables, and local hostname and then exfiltrate the stolen data to the hijacked S3 bucket.

Hijacking Abandoned Email Domains: The Case of ‘cox’ and ‘PHPass’

In May of 2022, the Python package ‘ctx’ and the PHP package ‘PHPass’ were compromised in a sophisticated cyber attack, leveraging a vulnerability in repository maintenance. Attackers identified popular open-source repositories managed through email addresses linked to expired domains. By re-registering these domains, they gained control over the email accounts, enabling them to reset passwords and assume ownership of the repositories. They then injected malicious code designed to steal environment variables, particularly targeting AWS credentials. This strategy led to a significant breach, with roughly 2,000 daily downloads of these packages for days before their removal.

RepoJacking: Hijacking Retired GitHub Namespaces

RepoJacking is a cybersecurity threat exploiting GitHub’s repository management system. This attack targets repositories whose usernames have been changed, a common occurrence when maintainers update their GitHub profiles. Attackers seize this opportunity by claiming the old, popular usernames and creating repositories with the same names. Users unknowingly download from these hijacked repositories, thinking they’re accessing trusted sources. This vulnerability allows attackers to distribute malicious code through seemingly reputable repositories.

The following short video demonstrates this case in more detail:

Hijacking Abandoned Open-Source Package Names: A RubyGems Package Takeover

A recent case in the RubyGems ecosystem highlights the risk of attackers exploiting abandoned open-source package names to inject malicious content into software projects that depend on them.

The ‘gemnasium-gitlab-service’ gem package, which was initially created and maintained by Gemnasium and later by GitLab, was eventually abandoned. An unknown entity noticed this abandonment and claimed the name of the gem. This act posed a serious threat because projects that were using the gem, without updating their dependencies, might unknowingly incorporate this new version, mistaking it for a legitimate update from the original gem.

So, What Can Be Done About All This?

To address the risks associated with abandoned digital assets, it is essential for all stakeholders in the open-source community to take proactive steps to protect the integrity of software supply chains.

Developers and organizations are encouraged to remain vigilant and regularly monitor their projects for abandoned dependencies, both direct and transitive, especially within open-source ecosystems.

For maintainers, practicing diligent domain and email management in software maintenance is crucial to prevent similar attacks within the open-source community.

Conclusion

These case studies highlight the risks associated with abandoned digital assets and illustrate not only the creativity of attackers but also the fragility of our software supply chains.

For developers and organizations, these incidents underscore the critical need for vigilant monitoring and stringent security practices in dependency management.

As the open-source ecosystem continues to grow, so does the responsibility to safeguard it from such insidious threats.

Abandoned digital assets are not just dormant pieces of our digital past but ticking time bombs that could detonate with far-reaching consequences. The collective effort in the cybersecurity community towards awareness, proactive measures, and robust defensive strategies is the key to mitigating these hidden dangers and maintaining the integrity of the open-source ecosystem.

In particular, the regulations that will impact cyber and application security teams in 2024 are the EU Cyber Resilience Act (CRA), the Digital Operational Resilience Act (DORA), and the Network and Information Security Directive (NIS2).

• The CRA introduces mandatory cybersecurity requirements for hardware and software products, throughout their whole lifecycle, and is expected to come into force in 2024; manufacturers will have to apply the rules no later than 36 months afterwards.  

• DORA is a crucial legislative framework that mandates operational resilience for financial institutions within the EU. DORA comes into force in January 2025, and it requires organizations to prepare for and withstand operational disruptions, including cyberattacks and technology failures.

• The NIS2 Directive is the most comprehensive European cybersecurity directive to date. It has stricter requirements for risk management and incident reporting, wider coverage of sectors, and more hard-hitting penalties for non-compliance. This will impact hundreds of thousands of organizations who will need to reassess their cybersecurity posture. The EU introduced the NIS2 Directive in January 2023, and it becomes law in October 2024.

Like any new legislation, understanding the precise language used can be daunting. Here I examine what NIS2, the most imminent new regulation, means for application security teams.

NIS2 Explained 

The NIS2 Directive is an updated EU cybersecurity law that builds on the original NIS Directive (NISD). The goals of NIS2 are to boost cybersecurity, simplify reporting, and create consistent rules and penalties across the EU. By expanding its scope, NIS2 requires more businesses and sectors to take cybersecurity measures, with the goal of raising the standard of Europe’s cybersecurity performance in the long run. With stricter rules to overcome previous limitations, NIS2 impacts a wider range of industries. Entities under NIS2 are classified as essential or important, and the directive outlines security requirements as well as a process for incident reporting. It is estimated that 160K+ companies will be affected by NIS2, with a €10 million maximum fine for non-compliance. 

There were several factors that necessitated the replacement of the previous NISD. These factors primarily revolved around the consensus that the legislation needed to be more stringent, and that its implementation required a greater level of uniformity across the EU. This was based on evidence in a 2020 study by ENISA which found that EU organizations allocated 41% fewer resources to information security than their US counterparts, despite NISD being in place for four years.  The report also highlighted that there was unclear guidance around how to apply the Directive. Layer onto this a significant rise in cyberattacks, with organizations across Europe increasingly affected by ransomware and other types of cyberattacks. Additionally, there was a perceived lack of transparency in the reporting of cyberattacks.

Reporting Obligations and Risk Management

To this point, the NIS2 Directive mandates the reporting of “significant incidents” within 24 hours and less significant incidents within 72 hours. Effectively, if you are hacked and the impact will affect your customers and partners, disrupting the products or services you deliver, you must tell the relevant authorities through prescribed channels. If you fail to do this correctly, your organization and its directors can be publicly named as being non-compliant, and fines or other sanctions may be issued.

The directive requires organizations to take a risk management approach to cyber security. Organizations must identify and reduce risk as far as possible, then implement robust procedures to manage incidents. AppSec plays a critical role in risk reduction by providing visibility over vulnerabilities so they can be remediated before they are exploited. An effective AppSec program will contribute significantly to minimizing the number of incidents that have to be reported. In contrast, if you are regularly reporting incidents, you can expect to find your AppSec program under investigation by authorities.    

Therefore, AppSec managers must take appropriate technical, operational, and organizational measures to manage the risks posed to the security of their systems, and to prevent or minimize the impact of incidents on recipients of their services. Additionally, AppSec managers are responsible for making sure their developers are properly trained and that the quality of software development is being maintained. AppSec managers must be able to prove to authorities that they have robust processes for software development and that they deploy secure applications into production.

Every company is part of someone’s supply chain 

Today the regulatory environment is increasingly focused on supply chains, with Biden’s Executive Order 14028 introduced in 2021 now joined by NIS2. Even organizations that aren’t directly in the scope of these regulations will find they are affected if they want to sell to companies that are. Every company is part of someone’s supply chain. 

In part, that’s because open source software (OSS) has become integral to software development. Its use is widespread, making up on average 80% of a typical code base. However, open source packages bring inherent risks such as vulnerabilities and license non-compliance. So, having clear visibility over your open source libraries as well as knowing how your suppliers are protected will be paramount. A sobering thought: the US Securities and Exchange Commission (SEC) recently charged SolarWinds and its CISO with fraudulent internal controls for failing to disclose known material cybersecurity risks and vulnerabilities. While these were risks that were known but not disclosed, organizations are also liable for risks that they fail to identify due to monitoring and due diligence failures. 

NIS2 addresses supply chains in Article 22 and AppSec managers will need to pay close attention to this. Here at Checkmarx our Checkmarx One platform enables AppSec teams to better manage open source and software supply chain risk. It integrates a comprehensive suite of AppSec solutions including SAST, SCA, SCS, API Security, DAST, Container and IaC Security. We believe it’s not just about complying with this new Directive and finding risk but remediating it across the entire application footprint and software supply chain with one seamless process that simplifies compliance for everyone. 

So, what steps should AppSec managers take to get ready for NIS2 compliance?  If you want to learn more, register for our NIS2 webinar here.

For AppSec managers and CISOs it’s important to take reasonable action so that they and their board of directors can sleep well at night without having to worry about cyber incidents. Incidents will continue to happen – we all know that, and it’s part of the reason why regulations like NIS2 exist. The focus should be on doing what you can to prevent them, and preparing our environment so we can follow the rules if an incident happens.