There has been a recent uptick in leaks, most notably Mercedes-Benz and Football Australia, who found themselves as victims in incidents that highlight the need for robust data protection strategies. 

The Mercedes-Benz Source Code Exposure

Mercedes-Benz faced a significant breach when an employee inadvertently published a private authentication token on a public GitHub repository, granting unfettered access to the company’s source code. This error was discovered by RedHunt Labs during a routine scan in January, revealing that the exposed token provided complete access to Mercedes’s GitHub Enterprise Server. This access level meant that anyone with the token could download private repositories containing sensitive data, including intellectual property, cloud access keys for Microsoft Azure and Amazon Web Services (AWS), database connection strings, and other critical internal information.

The Incident at Football Australia

Cybernews researchers reported a significant data leak at Football Australia, where personal information of Australian soccer players (including passports and contracts), as well as customer purchase details, were exposed online. The security breach lasted for at least 681 days and could potentially impact many local customers, with over 100 buckets of data exposed. The exposed data poses a severe threat, with potential for identity theft and fraud.

This cybersecurity incident, attributed to human error, resulted from a leak of secrets from plain-text Amazon Web Services (AWS) keys. This allowed public access to 127 digital storage containers containing sensitive data. 

Sample of the exposed data. Image by Cybernews.

Lessons Learned

These incidents serve as potent reminders of the vulnerabilities inherent in digital infrastructures across all sectors. They highlight the need for:

• Enhanced Secret Management: Employing tools and practices that ensure the secure handling of keys and tokens is non-negotiable.
• Regular Security Audits: Proactively scanning for vulnerabilities and exposures can prevent potential breaches.
• Education and Awareness: Human error being a common factor in both cases, underscores the importance of continuous education on best practices for all personnel involved in handling sensitive information.
• Incident Response Planning: Both organizations acted swiftly upon discovery, a testament to the importance of having an effective incident response strategy in place.

The cybersecurity incidents faced by Football Australia and Mercedes-Benz illuminate the critical need for heightened security measures and vigilant management of digital assets. Let these stories be a rallying cry for a unified approach to protecting our digital world—from the pitch to the pavement.

Maintaining the Sanctity of Secrets

To avert the leakage of secrets, consider implementing these strategies:

1. Environment Variables for Secrets: Store secrets in environment variables rather than embedding them directly in code to facilitate easier management and prevent their accidental inclusion in version control.
2. .gitignore for Sensitive Files: Utilize a .gitignore file to exclude files containing secrets from Git tracking. This ensures that these details do not inadvertently enter version control systems. If using environment variables for secrets, ensure their associated files are also ignored.
3. Secrets Management Tools: Employ secrets management tools for the secure handling and storage of system or application secrets. This guarantees encryption and access solely to authorized individuals.
4. Encryption of Secrets: Encrypt secrets prior to their storage in code repositories to add a security layer, making it challenging for attackers to obtain sensitive information.
5. Two-Factor Authentication (2FA): Activate 2FA for access to code repositories, enhancing security and complicating unauthorized repository access efforts.

These practices can significantly mitigate the risk of inadvertently exposing sensitive information across various platforms, including code repositories, content management systems, emails, and other digital assets not contained within a repository.

Preventing secrets from leaking on external tools with Secrets Detection by Checkmarx

Secrets Detection integrates and expands deeper scanning capabilities of Too many secrets 2MS, a command line tool written in Go language and built over gitleaks, directly into Checkmarx One. 2MS is one of the most popular open-source tools for secret detection, with over 2 million downloads. Secrets Detection in Checkmarx One finds secrets such as login credentials, API keys, SSH keys and more hidden in code, content systems, chat applications and more.

• Supported tools include Confluence, Discord, filesystem, git, paligo, Slack, Git Hooks, GitHub Actions
• Scan history to ensure secrets are not leaked in any previous versions   
• Detect secrets that are specific to your company with secret customization 

Learn more about reducing the risk of leaked secrets across the supply chain

• North Korea used public open-source and private package poisoning via the GitHub platform to infiltrate organizations and compromise their software supply chains (report)

• Attackers published malicious packages to PyPl, using various tactics, including combining obfuscation with encryption/decryption methods to hide their malicious intent, employing fileless malware to avoid detection, and leveraging the reputation of an extremely popular project (report)

• The Ledger Connect Kit suffered a significant supply chain attack resulting in the theft of over $700,000 from users’ wallets. The attack was facilitated by the takeover of a former Ledger employee’s npmjs account, which led to the release of compromised versions. This incident highlights the limitations of relying solely on Software Bill of Materials (SBOMs) to detect such attacks. (report)

We all hoped the start of a new year would bring new tidings. Unfortunately, NPM user account gdi2290, aka PatrickJS, published a troll campaign to the NPM registry by uploading a package named “everything,” which relies on every other public NPM package, resulting in millions of transitive dependencies. (report).

Jerry Gamblin, vulnerability researcher at Cisco, recently pointed out on LinkedIn that for the first time ever we have hit over 30,000 CVE’s published in a single year.

These developments, among the many others that preceded, emphasize the limited capacity of traditional security measures and the need for complementing them with advanced and dynamic approaches.

4 lessons learned in 2023

1. Attackers are ingeniously stitching together diverse tactics.​
2. Deceptive maneuvers, exemplified by social engineering and bogus contributions, have become a staple in attackers’ arsenals.​
3. Abandoned digital assets are not relics ​of the past; they are ticking time bombs.​
4. The threat landscape’s relentless evolution emphasizes the importance of predictive threat hunting.​

NSA’s recommended practices for securing the software supply chain

December was also a month for renewed guidance from the US Government. The National Security Agency (NSA), Office of the Director of National Intelligence (ODNI), the Cybersecurity and Infrastructure Security Agency (CISA), and industry partners have released a cybersecurity technical report (CTR), “Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials,” which builds on the “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” paper released by the Office of Management and Budget (OMB).  

Even with this in-depth guidance, most customers we talk to are under the assumption that having a well-defined SBOM (Software Bill of Materials) is the only tangible approach to a software supply chain security strategy.

Checkmarx’ end-to-end software supply chain security to facilitate SLSA attestation

Our vision is to bring together the idea of understanding what goes through the process, such as dependencies and software artifacts, with the development environment itself, all under the Supply-chain Levels for Software Artifacts (SLSA) framework. This first-to-market approach creates true visibility beyond what an SBOM can offer and helps get closer to providing attestation for SLSA compliance. 

Preventing secrets from leaking on external tools with Secrets Detection

Secrets, such as passwords, API keys, cryptographic keys, and other confidential data, are a frequent target of a distributed supply-chain attack.  

Threat actors are mining for secrets by scrapping public documentation, public repositories, and compromised private software repositories, and compromised build systems.

Each hard coded secret is now a new attack vector.

Secret Detection will help you remove hard coded passwords from your software supply chain by checking developer communication, shared tools, and components used across the supply chain.

Secrets Detection integrates and expands deeper scanning capabilities of 2MS, one of the most popular open-source tools for secret detection with over 2 million downloads, directly into Checkmarx One. 

Expanded capabilities include:

• Support for Confluence, Slack and Discord
• The ability to customizable rules and policies

Creating a streamlined level of accountability with automated SBOM

SBOMs can be generated automatically directly from the UI, in SPDX and CycloneDX formats. This saves you time and a headache, and ensures you have an up-to-date inventory of third-party packages being used within your software supply chain. 

Since Checkmarx maintains a historical record of all scans performed, we can retrieve a point-in-time SBOM from previous scans or code checking events. This eliminates the need for us to build maintain and back up a catalog of SBOM files in a file share, saving time and effort while ensuring you can be compliant with historical SBOM requests. 

Checkmarx supports a wide array of languages and package managers so there’s no need to implement maintain or update multiple SBOM solutions on a per project, or per language, level. 

Tackling the most vulnerable internal projects first with Security Scorecard Engine

Checkmarx Scorecard enables organizations to check their own projects quickly and see the most vulnerable or at-risk projects, allowing enterprises to prioritize which to tackle first.

Scorecard leverages the format from a popular tool, the OSSF Scorecard, which assesses open-source projects for security risks through a series of automated checks. 

These checks cover various parts of the software supply chain including source code, build, and dependencies, and assigns each check a score of 1-10. An auto-generated “security score” helps users as they decide the trust, risk, and security posture for their specific application. 

With Scorecard, users can auto-generate a security score for their own projects based on a series of checks, including: 

• Binary Artifacts – Is the project free of checked-in binaries? 
• Branch Protection – Does the project use branch protection? 
• CI (Continuous Integration) Tests – Does the project run tests in CI, e.g., GitHub Actions, Prow? 
• Code review – Does the project practice code review before code is merged? 
• Dangerous workflow – Does the project avoid dangerous coding patterns? 
• Vulnerabilities – Does the project have unfixed vulnerabilities? 

Integrating new tools is a frictionless, one-click integration. Once you select a new tool, it gets scanned, and the results are displayed in a dedicated view within Checkmarx One.

Gaining threat intelligence and eliminating manual analysis with Malware Detection

In the SLSA framework, malicious packages are a form of dependency attack where attackers inject or contribute malicious code into open-source projects that your developers download and then build into your applications. Once downloaded, the attacker’s malicious code is running within your applications, with whatever unknown intent the package carries. 

Our research team has inspected over 8 million open-source packages for all kinds of threats, finding 200,000+ malicious packages. We make that threat intelligence available to you, either in the UI, directly in developers’ IDE, or through an API-based threat intelligence feed.

Securing containerized applications throughout the supply chain

Securing your containers is a key part in preventing third parties from exploiting vulnerabilities that can lead to the impairment of your infrastructure, data leaks, and other types of attack. 87% of container images in production have critical or high-severity vulnerabilities. 

The Checkmarx Container Security Solution simplifies image scanning, monitors Docker environments, and helps swiftly resolve vulnerabilities. Identify, prioritize, and address security flaws across the SDLC to preempt issues in production workloads.

• Container Image Scanning – Scan static container images to identify vulnerable code in open-source software and remediate issues before they are deployed.

• Runtime Insights Correlation – Correlate pre-production and runtime data to identify exploitable vulnerabilities in running container images, reduce noise by up to 95%, and prioritize remediation efforts.

Software supply chain security is a journey, and it is important to take steps to secure your software supply chain today; detecting supply chain attacks in code packages, securing your developer’s evolving workstations supports rapid development while reducing risk.