Listen to this Post
Introduction:
The software supply chain has become the Achilles’ heel of modern enterprises, with attacks like SolarWinds proving that front-door defenses are no longer enough. Modern breaches are increasingly staged in the upstream layers of the codebase—hidden within open-source libraries, CI/CD pipelines, and third‑party dependencies. From this battleground, French startup Depi (formerly Lupin & Holmes) has emerged, armed with an offensive security platform that maps and stress‑tests real attack paths before criminals can exploit them.
Learning Objectives:
- Understand the core mechanics of software supply chain attacks and why upstream security is critical.
- Learn how to enumerate dependencies and detect dependency confusion vulnerabilities using open‑source tools.
- Implement practical hardening techniques for GitHub Actions, npm, and Python ecosystems.
You Should Know:
- Mapping the Attack Surface: Dependency Confusion & Enumeration
At the heart of Depi’s offensive strategy lies the ability to uncover hidden relationships between your code, its dependencies, and the upstream maintainers. A key technique in this space is dependency confusion, where an attacker uploads a malicious package with the same name as an internal private package to a public registry, tricking the build system into pulling the attacker‑controlled version.
Step‑by‑step guide: Enumerating packages and detecting confusion risks
Step 1: Enumerate all dependencies used by a target application.
– Linux / macOS: Use `grep` and `jq` to extract package names from lockfiles.
Extract npm package names from package-lock.json cat package-lock.json | jq -r '.packages | keys[]' > npm_packages.txt Extract Python dependencies from requirements.txt grep -oP '^[a-zA-Z0-9_-]+' requirements.txt > python_packages.txt
– Windows (PowerShell):
Extract npm package names using ConvertFrom-Json
(Get-Content package-lock.json | ConvertFrom-Json).packages.PSObject.Properties.Name > npm_packages.txt
Extract Python dependencies
Select-String -Path requirements.txt -Pattern '^[a-zA-Z0-9_-]+' | ForEach-Object { $_.Matches.Value } > python_packages.txt
Step 2: Check for publicly accessible package manifests.
Fuzz common endpoints to find exposed `package.json` or `requirements.txt` files:
ffuf -u https://target.com/FUZZ -w /path/to/wordlist.txt -e .json,.txt -c -ac
Step 3: Hunt through Git history for forgotten dependencies.
Dump all files from all commits (using tomnomnom's git-dump) git clone https://github.com/tomnomnom/dotfiles.git cp dotfiles/scripts/git-dump /usr/local/bin/ chmod +x /usr/local/bin/git-dump cd /path/to/target/repo git-dump | grep -E '(package.json|requirements.txt|pom.xml)'
Step 4: Verify if a dependency is vulnerable to confusion.
Search for the package name on public registries (npm, PyPI, RubyGems) and check if a public version with a higher version number exists. Depi automates this across thousands of dependencies, but you can manually test with:
Check npm for a package named 'internal-auth' npm view internal-auth versions Check PyPI pip index versions internal-auth
2. Defending the CI/CD Pipeline: Hardening GitHub Actions
A compromised CI/CD pipeline can lead to catastrophic supply chain breaches. Depi’s platform continuously monitors pipeline definitions and registry interactions to detect misconfigurations before they are exploited.
Step‑by‑step guide: Hardening GitHub Actions workflows
Step 1: Audit existing workflows for over‑privileged tokens.
Find all workflow files find .github/workflows -name '.yml' -o -name '.yaml' Check for GITHUB_TOKEN permissions grep -n 'permissions:' .github/workflows/.yml
Set the minimal required permissions explicitly:
permissions: contents: read Only read code, never write pull-requests: write If needed for comments
Step 2: Pin actions to full‑length SHAs instead of version tags.
This prevents tag‑poisoning attacks. Example:
Instead of: - uses: actions/checkout@v3 Use: - uses: actions/checkout@c85c95e3d7251b7c2adf5f6d68c6e4b7e4e5a6c8
Step 3: Restrict which branches can trigger workflows.
on: push: branches: - main - develop
Step 4: Enable GitHub’s dependency review and supply chain features.
– Navigate to Settings → Code security and analysis and enable Dependency graph, Dependency review, and Secret scanning.
– Use `actions/dependency-review-action` in your workflow:
- name: Dependency Review uses: actions/dependency-review-action@v4
Step 5: Scan your own container images before deployment.
Using Trivy (open‑source) trivy image your-app:latest --severity CRITICAL Using Grype grype your-app:latest
3. OS-Level Security for Build Servers
Build servers (Jenkins, GitLab Runners) are prime targets for upstream compromise. The following commands help lock down Linux and Windows build agents.
Linux (Ubuntu/Debian)
Restrict package installations to only signed packages apt-get install --allow-unauthenticated Never use this flag Harden SSH configuration echo "PermitRootLogin no" >> /etc/ssh/sshd_config echo "PasswordAuthentication no" >> /etc/ssh/sshd_config systemctl restart sshd Set immutable flag on critical build scripts chattr +i /usr/local/bin/build-script.sh Monitor file integrity with AIDE apt-get install aide aideinit mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db aide --check
Windows (PowerShell as Admin)
Restrict execution policy for build scripts Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope LocalMachine Enable Windows Defender application guard for build processes Add-WindowsCapability -Name "AppGuard" -Online Monitor file changes with Sysmon Install Sysmon from Microsoft .\Sysmon64.exe -accepteula -i sysmon-config.xml Block unsigned executables from running in build directories $rule = New-Object -TypeName Microsoft.PowerShell.ExecutionPolicy -ArgumentList "Restricted" Set-ExecutionPolicy -ExecutionPolicy $rule -Scope Process
4. Registry Hardening: npm and PyPI
Attackers often compromise internal registries or trick builds into pulling from public registries. Depi validates registry authenticity and package provenance.
Step‑by‑step guide: Hardening npm and PyPI configurations
npm
Force scoped packages to come only from your private registry echo "@mycompany:registry=https://npm.pkg.github.com/" >> .npmrc Enable package provenance (npm 9.5+) npm publish --provenance Disable `npm install` from running pre/post install scripts automatically (except for trusted packages) npm install --ignore-scripts
PyPI (Python)
Use a private index URL pip config set global.index-url https://pypi.yourcompany.com/simple/ And use the public index only as a fallback pip config set global.extra-index-url https://pypi.org/simple/ Verify package integrity using hashes Download a package and compare its hash to the official one pip download requests==2.28.1 --no-deps sha256sum requests-2.28.1-py3-none-any.whl Compare with the hash from PyPI
5. Upstream Maintainer Security Analysis
Depi goes beyond code scanning by assessing the security posture of the maintainers who control the libraries you depend on.
Step‑by‑step guide: Manual maintainer security assessment
Step 1: Identify maintainers of critical dependencies.
For npm, use `npm view` to list maintainers npm view lodash maintainers For PyPI, scrape the project page or use `pip show` pip show requests | grep -i maintainer
Step 2: Check if maintainers use 2FA on their accounts.
– On GitHub, visit `https://github.com/
` and look for the “Two‑factor authentication” badge. - On GitLab, check user profile → Security. Step 3: Use `curl` and `jq` to query GitHub API for maintainer activity and 2FA status. [bash] Get user's 2FA status (requires OAuth token) curl -H "Authorization: token YOUR_GITHUB_TOKEN" \ https://api.github.com/users/[bash] | jq '.two_factor_authentication'
Step 4: Monitor for anomalous package updates.
Set up a simple cron job that checks for new versions and logs the maintainer:
!/bin/bash Check for new versions of a specific package on npm current_version=$(npm view lodash version) if [ "$current_version" != "$last_known_version" ]; then echo "New version $current_version published by $(npm view lodash maintainers[bash].name)" >> maintainer_changes.log fi
What Undercode Say:
- Key Takeaway 1: Upstream security is not just about scanning dependencies; it requires mapping the entire attack surface—from source to build to package—and continuously stress‑testing those paths from an offensive perspective. Depi’s approach of “thinking like a hacker” is the only way to catch vulnerabilities that traditional SBOM and SCA tools miss.
- Key Takeaway 2: The best defense is a layered, proactive one. Hardening your CI/CD pipelines, pinning dependencies, and auditing maintainer security are all critical steps, but they must be combined with real‑time, attacker‑simulated validation. Depi’s ability to find a critical Rollup vulnerability days before it became public and alert Ledger in time to contain the blast radius proves that upstream security is no longer optional—it’s a business imperative.
Prediction:
The software supply chain attack surface will continue to expand as organizations accelerate adoption of AI‑generated code and third‑party components. In the next 24 months, we will see a new wave of “dependency confusion 2.0” attacks targeting not just package names but also AI model dependencies and configuration as code (CaC) repositories. Platforms like Depi, which combine real‑world bug bounty intelligence with automated attack path mapping, will become as essential as traditional firewalls. Expect upstream security to evolve into a dedicated product category, with acquisitions from major cloud providers (AWS, Azure, GCP) and a focus on real‑time, AI‑driven threat correlation. The shift from reactive patching to proactive, offensive security will redefine how enterprises build and deploy software, making “shifting left” a reality rather than a slogan.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Grateful To – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
