In this post, we drill down into the critical security and maintenance best practices required to ensure that your code repositories do not provide threat actors with an unprotected attack surface. 

Essential Practices for Healthy Repositories 

A robust repository health solution automatically and continuously tracks the security and quality practices in place for your code repositories. Each repository should be assessed against a set of established security policies and best practices, and remediated as necessary.  

 To build strong, secure repositories, your teams should consistently implement the following best practices; each one addresses a key aspect of repository health and risk mitigation. And to make sure that best practices remain in place, ongoing repository health monitoring is critical. 

Perform Code Review Before Merge 

Code review before merge ensures that all changes are examined by at least one other qualified developer before being incorporated into the main codebase. This practice is crucial because it helps catch security vulnerabilities, logical errors, and design flaws early in the development process, substantially reducing the risk of introducing security gaps or unstable code. 

By enforcing this “second set of eyes” approach, organizations not only improve code quality but also facilitate knowledge sharing and collective ownership across development teams, ultimately producing more secure and maintainable applications. 

Ensure Branch Protection 

Branch protection implements guardrails that prevent unauthorized or unreviewed changes from being directly pushed to critical branches like main or master. This protective measure is vital because it maintains the integrity of production-ready code by enforcing required reviews, passing status checks, and preventing history rewrites that could introduce security vulnerabilities. 

Proper branch protection rules serve as a fundamental security control that ensures all code meets quality standards before deployment, significantly reducing the risk of both accidental mistakes and malicious code injections that could compromise your entire application. 

Enforce Pinned Dependencies 

Pinning dependencies involves explicitly specifying exact versions of the libraries and packages your application relies on, rather than using version ranges or latest versions. This precision is essential because it creates reproducible builds and prevents “dependency confusion” attacks where malicious packages could be automatically introduced during builds. 

When dependencies are pinned, teams gain complete control over when updates occur, allowing for proper security review of new versions before adoption and ensuring that supply chain attacks targeting dependencies are less likely to affect your application without deliberate action. 

Use Actively Maintained Dependencies 

Using actively maintained dependencies means incorporating libraries and frameworks that receive regular updates, security patches, and have an engaged developer community. This factor is critical because abandoned dependencies quickly become security liabilities as new vulnerabilities are discovered but never patched, creating permanent weak points in your application. 

Projects relying on well-maintained dependencies benefit from rapid security fixes, performance improvements, and compatibility updates, significantly reducing the “security debt” that accumulates when using outdated software components that may contain known but unfixed vulnerabilities. 

Minimize the Presence of Executable/Binary Artifacts 

The presence of executable or binary artifacts in repositories represents a significant security risk because these opaque files can contain malware, backdoors, or vulnerable components that cannot be easily inspected through normal code review processes. Unlike source code, binary artifacts lack transparency and can execute arbitrary commands when deployed, potentially compromising entire systems. 

Minimizing or eliminating binary artifacts from repositories is important because it ensures all components can be properly audited, reduces the attack surface for supply chain attacks, and enforces the security principle of maintaining complete visibility into all software components deployed to production environments. 

Require Fuzzing Tests 

Fuzzing required means mandating automated testing that bombards your application with random, unexpected, or malformed inputs to discover vulnerabilities that standard testing might miss. Many critical security issues, such as buffer overflows, SQL injections, and format string vulnerabilities, often only emerge under unusual input conditions that developers rarely anticipate. 

By systematically implementing fuzzing in your development pipeline, you can proactively discover and remediate potential security issues before attackers can exploit them, significantly enhancing your application’s resilience against both known attack patterns and novel exploitation techniques. 

Establish and Enforce a Detailed Security Policy 

A detailed security policy provides clear guidance on vulnerability reporting, patching timelines, security support periods, and responsible disclosure practices for your project. This documentation is essential because it establishes trust with users, sets expectations for security response, and creates clear processes for handling discovered vulnerabilities. 

Organizations with well-defined security policies demonstrate their commitment to security, improve coordination during incidents, and provide crucial information that helps security researchers responsibly report issues rather than leaving vulnerabilities undisclosed or, worse, publicly exposed without allowing time for remediation. 

Test the CI Pipeline  

Continuous integration (CI) pipeline tests automatically verify that code changes don’t break functionality or introduce vulnerabilities before they are merged into the main codebase. This automation is crucial because it provides consistent, repeatable validation that catches issues early when they are least expensive to fix, regardless of developer oversight or time constraints. 

By incorporating security-focused tests like SAST (Static Application Security Testing), SCA (Software Composition Analysis), malicious package detection, secrets detection, and container security scanning directly into CI workflows, organizations create a security safety net that prevents vulnerable code from progressing toward production, establishing security as a non-negotiable quality gate rather than an afterthought. 

Avoid Dangerous GitHub Action Workflows 

Dangerous GitHub Action workflows represent configurations that grant excessive permissions, use untrusted third-party actions, or handle secrets insecurely within your CI/CD pipeline. Identifying and remediating these risky patterns is critical because compromised workflows can lead to supply chain attacks, credential theft, or unauthorized code modifications that affect all downstream consumers of your software. 

By enforcing least-privilege principles in CI/CD configurations and carefully vetting all third-party actions, organizations prevent their automation infrastructure from becoming an attack vector, protecting not only their own environment but also all users and systems that depend on their code. 

Implement Signed Releases 

Signed releases cryptographically verify the authenticity and integrity of published software packages, confirming they were created by trusted maintainers and haven’t been tampered with. This verification is increasingly important in an era of sophisticated supply chain attacks because it allows you to validate that the libraries your developers are implementing are legitimate, rather than blindly trusting package repositories. 

By consistently signing releases with secure keys and documenting verification procedures, projects create a chain of trust that makes it significantly harder for attackers to inject malicious code into your software components, even if package repositories or distribution channels are compromised. 

Use Secure Packaging 

Secure packaging encompasses the practices that ensure software is bundled, distributed, and installed in ways that maintain security throughout the delivery process. This comprehensive approach matters because even perfectly secure code can be compromised during distribution if packaging methods introduce vulnerabilities, include unnecessary components, or fail to validate integrity. 

By implementing proper package signing, minimizing attack surface through careful inclusion of dependencies, providing clean installation methods, and ensuring that packages can be verified before use, organizations extend their security posture beyond code development to protect the entire software supply chain from source repository all the way to deployment in the cloud. 

Taken together, these practices form a comprehensive blueprint for securing your code repositories against modern supply chain threats. 

Begin Securing Your Code Repositories Today 

As supply chain attacks continue to increase, securing your code repositories is no longer optional—it’s a business imperative. Comprehensive repository health monitoring gives you the visibility and control needed to protect your software supply chain from its earliest stages. 

Click here to learn more or request a personalized demo to see how Checkmarx Repository Health – a part of the comprehensive Checkmarx One application security platform – can strengthen your organization’s software supply chain security and overall AppSec posture. 

How Strong is Your (Software Supply) Chain? 

As the old saying goes, a chain is only as strong as its weakest link. 

CISOs, application security (AppSec) managers, software architects, and development managers already know that it has become a high priority to protect their software supply chains from cyberattacks. However, when even one link in the software supply chain is overlooked, the entire supply chain remains a clear and present danger to enterprise security. 

A commonly overlooked weak link in software supply chains is the code repository. Let’s  explore why repository health monitoring is critical for securing the modern software supply chain. 

The Growing Challenge of Securing Your Code Repositories 

Modern code repositories have evolved far beyond simple code storage. They house application source code, CI/CD configurations, infrastructure-as-code (IaC) files, and other sensitive data. Because code repos form the backbone of how your applications are written, assembled, and deployed, they are an attractive target for attackers.  

Industry analysts predict that 45% of organizations will experience a software supply chain attack this year, with poorly managed internal code repositories posing a significant vulnerability in enterprise security posture. 

For large enterprises maintaining thousands of repositories, manually tracking that effective security configurations and proper maintenance practices are in place across all repos is practically impossible. Without automated repository health monitoring, your organization faces substantial risks, including: 

• Unauthorized code changes 

• Dangerous or low-quality code entering production 

• Regulatory non-compliance 

• Supply chain compromises 

• Security vulnerabilities 

The humble, often-overlooked code repository can be a very weak link in your security chain and may need your urgent attention. 

Protecting Your Repos is About Protecting Your Software Factory 

While most AppSec tools focus on evaluating an application’s code, dependencies, and the final product—like QA inspections on incoming car components and the completed vehicle in an automotive factory—repository health monitoring helps secure the “factory” where your software is built. Just as a car manufacturing facility needs physical security, proper machinery maintenance, and operational safeguards, your code repositories require comprehensive health monitoring to prevent supply chain attacks and other vulnerabilities. 

To fully secure your development environments from the inside out, you need to comprehensively monitor and maintain the health of your repositories. 

Essential Practices for Healthy Repositories 

A robust repository health solution automatically and continuously tracks the security and quality practices in place for your code repositories. Each repository should be assessed against a set of established security policies and best practices, and remediated as necessary.  

The following is a list of essential repository best practices to implement and monitor. More technical readers can learn about each of the following critical factors in Part 2 of this blog post. 

• Code Review Before Merge 

• Branch Protection 

• Pinned Dependencies 

• Dependencies Actively Maintained 

• Presence of Executable (Binary) Artifacts 

• Fuzzing Required 

• Presence of a Detailed Security Policy 

• CI Pipeline Tests 

• Dangerous GitHub Action Workflows 

• Signed Releases 

• Secure Packaging 

The Benefits of Repository Health Monitoring 

Implementing effective repository health monitoring helps protect the entire software supply chain, from source repository all the way to deployment in the cloud, by delivering an extensive list of important benefits. These benefits, explained in more detail in Part 2 of this post, include: 

• More secure applications and automation infrastructure, against both vulnerabilities and malicious code 

• Faster discovery and remediation of potential security issues before attackers can exploit them 

• Reduced “security debt” 

• Improved code quality 

• More maintainable applications  

• Improved coordination during security incidents  

• Improved knowledge sharing and collective ownership across development teams 

Strengthen Your Software Supply Chain with Repository Health Monitoring 

Achieving these benefits requires a solution that can: 

1. Scale across thousands of repositories to provide enterprise-wide visibility 

2. Integrate seamlessly with your development workflow to minimize disruption 

3. Automate continuous assessment to eliminate manual tracking 

4. Provide actionable recommendations that drive tangible security improvements 

Checkmarx offers an advanced repository health monitoring solution as part of the Checkmarx One cloud-native application security platform to comprehensively and continuously assess the security and quality of all code repositories used in your applications. Key capabilities include: 

• Continuous Repo Health Tracking – Maintain awareness of the security and quality posture of all repositories included in your applications based on security practices, testing procedures, dependency management, CI/CD best practices, and project maintenance. 

• Automatic SCM-Triggered Scans – Integration with SCM platforms enables scans to run automatically upon repository updates, ensuring up-to-date repo health metrics with no manual effort required. 

• Flexible On-Demand Scanning – In addition to automatic SCM-triggered scans, developers and security teams can manually run repo health scans at any time via API, CLI, or the Checkmarx One UI. 

• Unified Risk Reporting – Repository health evaluations are included in Checkmarx One reports, providing visibility into—and efficient prioritization of—security vulnerabilities, code quality issues, and repository health risks, all in one centralized view.  

As supply chain attacks continue to increase, securing your code repositories is no longer optional—it is a business imperative. Repository health monitoring gives you the visibility and control needed to protect your software supply chain from its earliest stages. 

Click here to learn more or request a personalized demo to see how Checkmarx Repository Health – a part of the comprehensive Checkmarx One application security platform – can strengthen your organization’s software supply chain security and overall AppSec posture. 

For a deeper, hands-on technical guide on keeping your repositories secure and maintainable, check out Part 2: Essential Practices for Secure Repositories.

Malicious Open-Source Attacks: Meet the Usual Suspects

Here’s a look into three sneaky types of attacks targeting open-source software vulnerabilities that might ruin your day if you’re not careful.

1. Dependency Confusion: Internal vs. External Chaos

Dependency confusion is when your automated build fetches a public version instead of your trusted internal one, and it’s exactly as messy as it sounds.

Attackers exploit packages of the same name between private (internal) repositories and public ones, tricking package managers into downloading malicious packages that masquerade as legitimate internal packages. Here’s how it typically goes down:

• Internal Package Spoofing: Say you have an internal package called company-infra. An attacker might publish a malicious package with that same name on a public repository, but with a suspiciously high version number, like v999.999.999. Because many package managers default to fetching the highest version, you’re suddenly pulling malicious code instead of your trusted internal package.
  
• Version Inflation Attacks: Attackers don’t even need to guess blindly. Sometimes they’ll scrape public GitHub repositories for dependency files (package.json, requirements.txt) to discover the names of your internal packages. Once discovered, they upload malicious packages using these exact names but higher version numbers to public repositories, baiting your build servers into downloading their payloads.
  

Pro tip for protection: Register placeholder packages with the same names as your internal ones on public repositories with intentionally low version numbers. This prevents attackers from claiming the package names and tricking your build tools. Other defensive options are namespace prefixing, version pinning, and configuring package managers to prioritize private repositories.

2. Typosquatting: When One Letter Costs You Everything

Imagine you’re exhausted, on your fourth coffee, and accidentally type “electorn” instead of “electron.” That tiny slip-up? It just downloaded a malicious package onto your dev machine. Welcome to the sneaky world of typosquatting where attackers bank on human mistakes.

Common typosquatting techniques include:

• Combosquatting: Appending common words or letters to legitimate packages, e.g., “lodash” becomes “lodashs.” Sounds legit, right?
• Omission: Leaving out a letter or hyphen, turning “cross-env” into “crossenv.” Harmless typo? Think again.
• Repetition: Sneaking in extra letters, like typing “jquerry” instead of “jquery.” Because who hasn’t held a key down too long?
• Transposition: Swapping adjacent letters, like the classic “electron” vs. “electorn”.

Typosquatting is tough to spot because it preys on developer fatigue and multitasking. Attackers count on developers’ busy schedules and tired eyes to overlook tiny naming discrepancies.

Pro tip for protection: Leverage advanced Software Composition Analysis (SCA) tools capable of detecting suspicious OSS packages, rather than relying solely on specific names and human vigilance.

3. RepoJacking: Hijacking Repositories One Rename at a Time

Picture this: your favorite GitHub repo suddenly renames itself. No big deal, right? Wrong. It’s actually the first domino falling in a potential attack called Repository Jacking, or RepoJacking. Here’s the sneaky trick attackers pull:

GitHub has a nifty feature called “Repository Redirects,” which automatically redirects users when repos or usernames are changed. Handy? Yes. Safe? Not always.

• Let’s say GitHub user Annastacia publishes a popular Go package at github.com/Annastacia/useful.
• Later, Annastacia shortens her username to Anna. GitHub automatically redirects requests from the old username (Annastacia) to the new one (Anna). So far, so good.
• But here’s the kicker: GitHub frees up the old username (Annastacia) for anyone to claim. Attackers jump at the chance, registering that abandoned username and setting up a malicious repo with the same original repository name (useful).
• Suddenly, anyone relying on the original URL downloads the malicious version instead. Chaos ensues.

The simplicity of username changes on GitHub means attackers don’t have to break in. They just wait for usernames to free up and jump in to exploit trust built over time.

Pro tip for protection: Use automated scanning tools like Checkmarx SCA to proactively identify vulnerable dependencies.

Detecting and Preventing Malicious Packages and Code: Your Tactical Game Plan

Let’s talk about solutions. Here’s a step-by-step guide to locking down your OSS supply chain:

Step 1: Visibility First

Know exactly what OSS you’re using. If you don’t know your stack, you can’t protect it. Use SBOMs and SCA tools that don’t just scan for known vulnerabilities, but also detect anomalies indicative of typosquatting or dependency confusion.

Step 2: Secure Internal Repositories

Minimize dependency confusion by locking down your package manager configurations. Ensure your internal repositories take precedence, and register placeholder packages in public repositories to block attackers from using your package names.

Step 3: Double-check Versions

Malicious actors love inflating version numbers. Configure your build environment to strictly manage and approve version updates. Better yet, create checksums or lock files to verify package integrity explicitly.

Step 4: Automation Is Your Friend

Automate vulnerability and malicious code detection in your CI/CD pipelines. Tools like Checkmarx SCA can spot typosquatting packages and other suspicious anomalies before they reach production.

Step 5: Protect Against RepoJacking

Avoid using retired namespaces to minimize the attack surface, and use SBOMs and SCA tools to regularly audit your repositories.

Wrapping Up: Vigilance Plus Checkmarx, the Ultimate Defense Combo

Look, nobody wants to be “that manager” whose codebase becomes the cautionary tale at conferences. OSS isn’t going anywhere, and neither are the attackers, so it’s best to stay sharp and stay informed on the risks of malicious code. Explore how Checkmarx One can mitigate the risk of OSS with its unified, end-to-end approach to software supply chain security.

Introducing Secret Sprawl

Tech sprawl in all forms poses serious issues for companies and their efficiency and productivity. With secret sprawl, the uncontrolled proliferation of secrets across various parts of an organization’s infrastructure, including code repositories, configuration files, automation scripts, and shared documents, opens up serious security risks.

This dispersion often results from practices like hardcoding credentials into code or embedding them within configuration files or automation scripts for convenience. As organizations scale and their infrastructure becomes more complex, keeping track of all these secrets becomes increasingly challenging.

The dangers of secret sprawl are significant:

• Security Breaches: Exposed secrets can be discovered and exploited by attackers, leading to unauthorized access to systems and data breaches.
  
• Operational Disruptions: Attackers use exposed secrets to take control or vandalize systems, leading to catastrophic operational failures and can also cause lasting damage to a company’s infrastructure, reputation, and customer trust
  
• Compliance Issues: Many regulatory frameworks require stringent controls over sensitive data (e.g., GDPR, CCPA, PCI-DSS, HIPAA). Secret sprawl can lead to non-compliance and hefty fines.

The Cure for Secrets Sprawl: Manage, Detect, Prevent

The good news is that there are strategies to manage secret sprawl. Through developer training, secrets management tools, continuous secrets detection, and proactive prevention of secrets reaching repositories, preventing secrets sprawl becomes part of a holistic DevSecOps framework. To mitigate secret sprawl, you have to implement both secrets management and secrets detection. The two are related, but they serve different purposes.

Secrets management is all about providing developers with a secure method of storing and using secrets. It focuses primarily on preventing secrets sprawl by managing secrets in one secure, centralized tool. Robust secrets management tools tailored to your environment can include cloud-based solutions like AWS Secrets Manager and Azure Key Vault, self-hosted vaults like HashiCorp Vault, CI/CD-integrated managers like GitHub Actions Secrets, and identity-based solutions like AWS IAM Roles.

Developer training on secure coding practices should emphasize the dangers of secret sprawl in cybersecurity. Clearly communicate best practices and company policies for preventing secrets sprawl, highlighting how sensitive credentials should never be hardcoded in source code or configuration files.

On the other hand, secrets detection focuses on finding hardcoded secrets that have made their way into code. Even if an organization has a robust secrets management tool and clear policies, mistakes still happen, like developers accidentally hardcoding passwords into code, configuration files, and automation scripts. Secrets detection solutions automatically identify these mistakes, catching secrets that slipped through the cracks. They can also proactively block code commits so that these exposed secrets do not make their way into more widely accessible code repositories. By automatically scanning for exposed secrets before commits, blocking repository pushes containing secrets, and integrating these preventive controls into integrated development environments (IDEs) and CI/CD pipeline security checks, you can ensure that hardcoded secrets do not make their way into code repos.

Secrets scanning can be initiated manually or automatically at specific stages in the software development life cycle (SDLC) via source control management (SCM) integrations. Use automated secrets detection solutions capable of accurately identifying various secret types, validating their exploitability (for remediation prioritization), and providing developers with remediation guidance directly within their IDEs.

You can quickly remediate exposed secrets by scanning current and historical versions of code commits across all your repositories, discovering hardcoded secrets within them. When found, promptly revoke and replace the discovered credentials to ensure that their exposure can not lead to cyberattacks.

Incorporate Advanced Secrets Detection within a Unified AppSec Platform

Checkmarx Secrets Detection reduces risk by quickly identifying hardcoded credentials and blocking them from reaching code repositories. Part of the Checkmarx One platform, Secrets Detection identifies more than 170 types of secrets and automatically validates them to determine if they are still in effect and thus potentially exploitable.

Secrets Detection lowers supply chain risk, improves regulatory compliance, and increases developer efficiency, all within a developer-friendly workflow.

Learn more about Checkmarx Secrets Detection here.

Modern enterprise software relies on authentication tokens, API keys, encryption keys, certificates, and other sensitive credentials to enable secure communication between applications, microservices, APIs, and DevOps pipelines. However, these secrets often end up hardcoded in source code during the development process, whether unintentionally or as a shortcut for quick development (because hardcoding access credentials is simply the fastest and easiest way to write and test code). 

When exposed in public or internal repositories, these credentials become prime targets for attackers, who can exploit them to gain unauthorized access to critical systems, sensitive data, or cloud infrastructure. Even private repositories aren’t immune – compromised developer accounts, insider threats, or misconfigured access controls can all lead to unintended exposure.  

Examples of Known Cyberattacks Enabled by Exposed Secrets 

Exposed secrets have been at the center of numerous high-profile cyberattacks, underscoring the critical need to secure the software supply chain against this threat. Here are some notable examples: 

• Uber (2016) – Hackers exploited leaked AWS credentials to steal the personal data of 57 million users. 

• Slack (2017) – Tokens exposed on GitHub exposed the sensitive private messages of hundreds of companies. 

• Capital One (2019) – A hacker used a leaked access token to extract the personal data of over 100 million customers. 

• Microsoft (2020) – Attackers used exposed account credentials to access private Microsoft repositories. 

• GitHub (2022) – Stolen OAuth tokens allowed attackers to access private source code and exfiltrate data. 

• Mercedes-Benz (2023) – An employee inadvertently uploaded a GitHub access token to a public repository, exposing source code, API keys, cloud access credentials, and design documents. 

• Football Australia (2024) – Leaked credentials enabled unauthorized access to 127 storage repositories holding customer purchase details, player contracts, and passport data. 

• Schneider Electric (2024) – Hackers used exposed credentials to steal 40GB of sensitive data, including the names and email addresses of 75,000 employees and customers. 

How to Prevent the Leakage of Exposed Secrets 

Traditional security tools aren’t designed to detect or prevent leaks of secret credentials. To mitigate this risk, enterprises must enforce secure coding practices, adopt automated secrets detection, and integrate preventive controls into their software development lifecycle. Without these measures, a single leaked credential could lead to a catastrophic security incident. 

To minimize the risks of exposed secrets, enterprises should implement a four-pronged approach: 

1. Developer Training 

The first line of defense is developer awareness. Companies should invest in security training that educates developers about how dangerous hardcoded secrets are—even within internal repositories—emphasizing that sensitive credentials should never appear in source code, configuration files, or documentation. The training should convey clear guidance regarding company policies and best practices. 

However, time pressure and development shortcuts often lead to mistakes. Even with first-rate training, secrets will occasionally end up in code. That’s why additional safeguards are essential. 

2. Secrets Management Tools 

Organizations should adopt secrets management solutions to securely store and handle credentials. Each enterprise needs to evaluate the various types of solutions available and adopt the most relevant ones for their environment. Common examples include: 

• Cloud-based secrets management services integrate seamlessly with development environments and offer automated secrets rotation. Examples: AWS Secrets Manager, Azure Key Vault, Google Secret Manager. 

• Self-hosted secrets vaults are on-premises or private cloud deployments that provide enterprises with advanced access controls and audit logging. Examples: HashiCorp Vault, CyberArk Conjur, Doppler.

• CI/CD and DevOps-integrated secrets managers integrate with CI/CD pipelines to securely inject secrets into applications, keeping them out of repositories. Examples: GitHub Actions Secrets, GitLab CI/CD Secrets, Kubernetes Secrets. 

• API gateway & identity-based secrets management solutions secure authentication credentials at the network layer instead of within applications. Examples: AWS IAM Roles, Google Workload Identity, HashiCorp Boundary. 

3. Continuous Secrets Scanning 

Even with secrets management tools, enterprises must continuously scan their repositories to detect and remediate exposed secrets. An effective scanning tool should: 

• Accurately identify hundreds of different types of secrets (e.g., authentication tokens, certificates, encryption keys, API keys), while minimizing false positives (to reduce noise and prevent alert fatigue). 

• Automatically verify whether discovered secrets are still valid (and thus potentially exploitable) to help prioritize remediation efforts. 

• Allow developers to initiate their own scans from within the IDE before pushing code, to ensure that hardcoded secrets don’t reach the repository. 

• Provide developers with remediation guidance within the IDE, pinpointing exactly where secrets were found. 

• Enable managers to trigger automatic scans at critical stages in the development, build, and deploy lifecycle. 

4. Preventing Secrets from Reaching Repositories 

Once secrets are pushed to a shared repository, the risk skyrockets. Enterprises must prevent exposure by implementing pre-commit and pre-push hooks that: 

• Scan for secrets before commits are made. 

• Block repository pushes if secrets are detected. 

• Integrate with CI/CD pipeline security checks to enforce policies automatically. 
   

By combining developer training, robust secrets management, continuous scanning, and proactive blocking, enterprises can dramatically reduce the risk of exposed secrets and protect their software supply chain. 

Keep Your Secrets Secret with Checkmarx Secrets Detection 

Checkmarx Secrets Detection proactively prevents the exposure of sensitive credentials by blocking any Git commit containing hardcoded secrets, ensuring that they never reach shared repositories. Automatic secrets identification and validation help developers quickly locate and remove exploitable secrets from their code, preventing leakage. 

A part of the Checkmarx One enterprise application security platform, Secrets Detection accurately identifies 170+ types of secrets. Scans can be initiated on demand or triggered via source control integrations (e.g., upon pull requests or builds), ensuring continuous protection throughout the development lifecycle, helping you: 

• Keep your secrets secret – Prevent the unintended exposure of sensitive credentials, tokens, keys, certificates, or URLs that can endanger your organization. 

• Secure your software supply chain – Make secrets leakage prevention a core component of your comprehensive software supply chain security (SSCS) strategy. 

• Improve regulatory compliance – Avoid fines and reputational damage by fully meeting regulations that require organizations to safeguard sensitive data (e.g., GDPR, HIPAA, PCI DSS, SOX, FISMA, CCPA). 

To learn more about Checkmarx Secrets Detection, read the solution brief. 

In fact, according to Infoworld, “we are in the midst of a rapid surge in software supply chain attacks,” with a staggering 742% annual increase, resulting in costs exceeding $4 million. Gartner predicted that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.

The growing number of high-profile SSCS attacks and data breaches (such as SolarWinds, NotPetya, CCleaner, Target, Equifax and Kaseya VSA) have increased awareness of SSCS vulnerabilities. This alarming trend emphasizes the need for enterprises to allocate more resources into securing their software development and deployment processes, from code to cloud.

But how did we get here? Fifteen years ago, most enterprises exclusively relied on internally developed code. Today, however, most modern code bases are largely built with open source packages and third-party code. While this shift accelerates development and fosters more innovative code, it also introduces more vulnerabilities – whether from human error, careless exposure of secret keys (passwords, encryption keys, and access tokens), or malicious third-party code. Additionally, the recent uptick in AI-generated code from digital assistants like ChatGPT, GitHub Copilot, and Codestral has further increased the risk of insecure code finding its way into enterprise applications.

Like it or not, modern development requires the use of third-party codebases, despite the risks they may bring. That’s why enterprises need a solution to effectively manage and mitigate the risks associated with these third-party libraries.

AppSec Has Traditionally Focused on Internally Developed Code

Figure 1 – Traditional application security focused only on finding vulnerabilities in proprietary code.

Until recently, application security (AppSec) primarily focused on the code developed by the enterprise in-house. This made it easier to detect and remediate security vulnerabilities, because the code was exclusively written by their own developers. Vulnerability detection for these code bases generally relied on static application security testing (SAST) and dynamic application security testing (DAST).

In fact, when Checkmarx was founded 18 years ago, we also focused on this traditional AppSec model, concentrating on securing the code developed internally by enterprises.

Why Software Supply Chain Security Now? 

What changed? In recent years, the importance of securing the software supply chain from code to cloud has grown steadily among enterprise CISOs, AppSec managers, DevOps teams, and developers.

This shift is driven by four key factors:

1. Extensive use of open source packages and other third-party code
2. Migration of applications to the cloud (cloud-native applications)
3. Incorporation of automated compile/deploy workflows (CI/CD)
4. Proliferation of attacks on the software supply chain

These changes in modern development have introduced greater risks to software security than ever before. Securing applications now requires involvement from every stage of the software development lifecycle (SDLC), from code to cloud. To address these new threat vectors, Checkmarx developed a comprehensive, integrated solution that protects the entire software supply chain.

SSCS Begins With SCA and Malicious Package Protection

Surveys indicate a dramatic increase in the use of open source libraries, with up to 97% of applications now incorporating open-source code. This statistic is not surprising, considering how open-source libraries significantly speed up development and reduce business costs.

However, this new, increased use of open source code has also exposed enterprises to a massive new threat vector: both unintentional vulnerabilities and intentionally malicious code – both of which can be exploited.

Checkmarx has adapted to the evolving risks in the software supply chain and has become a leader in addressing these open-source risks. How? Our Software Composition Analysis (SCA) solution provides enterprises with a strong protection against these types of malicious packages. Checkmarx’ SCA solution:

• Comprehensively discovers and itemizes all open-source packages used in applications (including transitive open-source dependencies)
• Identifies open-source packages containing vulnerable code, malicious code, or suspicious behavior (such as typosquatting, starjacking, and repojacking)
• Prioritizes remediation efforts using multiple analyses (e.g., reachability/exploitable path analysis and SAST correlation)
• Provides AppSec teams and developers with specific and actionable remediation guidance
• Integrates with CI/CD and IDE tools to smoothly integrate security testing and remediation workflows into existing deployment and development platforms
• Generates an industry-standard software bill of materials (SBOM)
• Detects legal and compliance risks associated with open source licensing issues
• Enforces policy rules to automatically send alerts and prevent builds based on a range of factors

Figure 2 – The first step to expanding application security into software supply chain security is adding advanced SCA with malicious package protection.

Checkmarx One: Advanced AppSec Including SSCS

Unfortunately, even advanced SCA solutions are no longer enough to protect against SSCS attacks. To fully protect the software supply chain, Checkmarx now offers a complete suite of industry-leading solutions to secure both internally developed code and the software supply chain components that they consume.

Checkmarx One is a code- to -cloud platform that provides an integrated SSCS solution that no enterprise can afford to be without. In addition to our SAST, DAST, SCA, and malicious package protection capabilities, Checkmarx One covers the entire software supply chain with the following capabilities:

• Container Security – Identify and mitigate risks in container images, container infrastructure, and runtime code.
• AI Security – Automatically scan AI-generated source code and referenced open-source libraries for vulnerable or malicious code.
• IaC Security – Secure cloud infrastructure with proactive vulnerability identification and misconfiguration detection.
• API Security – Discover and remediate every API vulnerability.
• Secrets Detection – Automatically discover the presence of sensitive credentials.
• Repository Health – Get comprehensive health scorecards for software repositories.

Figure 3 – Checkmarx One delivers comprehensive code-to-cloud application security, including coverage for critical software supply chain dangers.

More About Our Newest Capabilities

Secrets Detection and Repository Health are the newest additions to the Checkmarx One suite aimed at protecting against software supply chain risks. Let’s take a closer look at these new offerings:

Secrets Detection

Figure 4 – Secrets Detection minimizes risk by identifying sensitive credentials that are at risk of being unintentionally exposed.

Enterprises unintentionally expose thousands of secret credentials in GitHub and other publicly accessible or insecure locations every day. This exposure can enable unauthorized access to your systems, potentially resulting in cyber-attacks, financial loss, and reputational damage. Once credentials are compromised, attackers can move laterally within systems to extract data, deploy malware, or launch further attacks on infrastructure, customers, and partners.

Checkmarx’ Secrets Detection minimizes risk by quickly identifying sensitive credentials that may be unintentionally exposed – and pinpoints which ones are still valid. With this insight, your development and security teams can quickly remediate issues by removing exposed secrets and updating them to prevent any unauthorized usage.

Scanning for exposed secrets can be initiated on demand or manually with automatic triggers via SCM integration (e.g., pull request, build). Discovered secrets are automatically validated to determine if they are still in effect and thus potentially exploitable.

This provides three key benefits:

• Minimize supply chain risk by preventing the exposure of secret credentials, reducing the chance of attackers accessing your systems or stealing data.
• Improve regulatory compliance by meeting data protection requirements (e.g., GDPR, HIPAA, PCI DSS, SOX, FISMA, CCPA) and avoiding fines and reputational damage.
• Increase developer efficiency by allowing developers to initiate scans, review discovered secrets, and receive remediation guidance directly within their IDE.

Repository Health

Figure 5 – Repository Health provides ongoing visibility into the security and maintenance health of the code repositories used in enterprise applications.

Enterprises also need a reliable way to continuously evaluate the riskiness of the open-source code used in their applications, as well as a method to monitor the quality and security of the repositories containing their internally written code.

Checkmarx’ Repository Health maximizes the security posture of your software supply chain by continuously tracking health scores for all repositories in your applications. Scoring is based on more than a dozen key factors in areas, such as code quality, dependency management, CI/CD best practices, and project maintenance.

Repository Health can automatically scan repositories upon repository updates, ensuring up-to-date repo health metrics with no manual effort. Developers and security teams can also run on-demand repo health scans at any time via API, CLI, or the Checkmarx One UI.

Additionally, repository health scores are included in Checkmarx One reports, providing visibility into – and efficient prioritization of – security vulnerabilities, code quality issues, and repository health risks, all in one place.

The three key benefits this provides include:

• Minimize supply chain risk – Visibility into the security health of open source components and your own code repositories that closes an important gap in software supply chain security.
• Efficient holistic risk prioritization – Identifying and prioritizing high-risk areas across the software supply chain that allows developers and security teams to focus their efforts on the most critical security issues.
• Enhanced transparency and communication – Clear, quantifiable metrics on the security posture of open source dependencies and first-party repositories that improve transparency and communication among stakeholders.

Learn More

Given the wide range of threat vectors facing enterprise applications and the software supply chain, deploying the most comprehensive and effective security solutions is essential. And these solutions must also cultivate an excellent developer experience to encourage adoption and support seamless, efficient workflows.

Relying on a hodge-podge of different tools to protect your supply chain is no longer viable – it is expensive, inefficient, and difficult to maintain. To protect your enterprise from data breaches or other system infiltrations unified platform that covers all your bases. And that’s where Checkmarx comes in.

Contact us for a free demo of Checkmarx One and discover the industry’s best solution for securing your enterprise’s applications and the software supply chain.