Software supply chain security is bigger than SBOMs and package dependencies. It includes the producer writing first-party code, the consumer combining libraries and services into new software, and the end user who installs, deploys, or depends on the finished product. It also includes the systems that shape trust along the way: developer desktops, repositories, CI/CD pipelines, SAST tooling, package ecosystems, artifacts, deployment tooling, containers, and cloud environments.
Cyfinoid’s research in this area focuses on how software trust breaks in practice. We study the places where convenience, automation, weak governance, and implicit trust intersect, and where attackers can turn that into repository access, dependency abuse, artifact tampering, release compromise, or broader organizational impact.
Our goal is to help teams understand software supply chain security as a full lifecycle problem rather than a compliance checkbox. That means looking beyond inventories and scans to the actual workflows, credentials, controls, and trust relationships that determine whether software can be trusted.
This also means our research naturally extends into adjacent areas such as CI/CD pipeline abuse and hardening, static analysis and SAST tooling, and desktop security for the systems where software is authored and trusted.
What We Study
- Developer workstation, desktop, and identity-related supply chain risk
- Repository access, token exposure, and source control trust
- CI/CD abuse, pipeline security, build integrity, and release automation compromise
- Static analysis, SAST tooling, and where security tooling itself can create blind spots or misplaced trust
- Malicious dependencies, package ecosystem attacks, and third-party risk
- Inventory, SBOM, provenance, and trust verification beyond checkbox compliance
- Deployment, cloud, and runtime considerations that shape end-user trust
Why This Matters
Attackers increasingly target the systems around the code rather than the code alone. A stolen developer key, an over-permissioned token, an unsafe workflow, or a compromised dependency can have far more impact than a single application bug.
Defenders need a broader model. Producers need to secure how software is authored and shipped. Consumers need to understand what external components and services are being pulled into their products. End users need better signals to judge what software they can trust. Our research is built around that full picture.
Community Contributions
How This Research Gets Used
- Building tools that make supply chain visibility and review easier
- Turning recurring attack paths into practical training, labs, and case studies
- Helping teams move from dependency-only thinking to lifecycle-wide trust analysis
- Translating offensive lessons into better governance, hardening, and detection decisions
Who This Research Helps
- Developers and platform teams building first-party software
- Security teams reviewing repositories, pipelines, and release processes
- Organizations consuming third-party software, packages, and SaaS components
- Leaders who need clearer language for software trust, provenance, and operational risk
This research directly informs Cyfinoid’s software supply chain and CI/CD trainings, as well as our broader work on cloud and software trust.
Upcoming Trainings
Blogs
SBOMPlay v0.0.7
GH Navigator Released: Full Coverage of GitHub’s Data and Control Planes
Automating a Known Weakness: Introducing keychecker
Introducing 3P-Tracer: third-party mapping in your browser
Introducing SBOM Play: A Privacy-First SBOM Explorer with Vulnerability & License Insights
Enhancing Open Source Security for Startups with Automated Scanning
