Socket’s latest funding interview is less interesting as a startup milestone than as a marker for where software supply chain work is moving: away from simple dependency scanning, and toward operational control over what code enters an organization, who can publish it, and how fast maintainers can absorb new vulnerability reports.
Feross Aboukhadijeh, Socket’s CEO and a long-time open source maintainer, joined TBPN after Socket announced a $60 million Series C led by Thrive Capital at a reported $1 billion valuation. The Socket post also cites 500%+ ARR growth over the past 12 months. Those numbers are company-reported and should be treated as business context, not independent proof of market conditions.
The useful part is the threat model Feross describes. He points to three forces landing at once: AI-generated development pulling in more third-party code, AI systems surfacing large volumes of vulnerabilities in existing software, and attackers using open source components as a route into many organizations at once.
That framing is credible because it matches what security teams already feel in practice. The package registry is no longer a passive shelf. It is part of the deployment path.
What changed#
The Socket blog post says the company raised a $60 million Series C and uses the TBPN conversation to explain why software supply chain security has become a higher priority. Feross argues that AI has changed both sides of the equation.
On the builder side, developers and non-developers are pulling in more open source dependencies and third-party code. AI agents make that easier. They can write glue code, suggest libraries, and assemble working prototypes fast. The weak point is review. More code enters projects, but not always with more human understanding of what that code does or who controls it.
On the discovery side, Feross says frontier AI models are finding large numbers of high-severity vulnerabilities across operating systems and open source libraries. The source does not provide an independently verifiable count beyond that claim. Still, the direction matters. If automated discovery keeps improving, vulnerability volume can rise faster than maintainer review capacity.
The third point is attacker behavior. The post says attackers increasingly target open source components because one compromise can reach many downstream organizations. That is the core software supply chain problem: the attacker does not need to breach every company directly if they can influence a package those companies already trust.
This is why funding news belongs in a security operations conversation. Capital is not the story. The market is paying for controls around package selection, dependency behavior, maintainer access, and suspicious release activity because the old model — trust the package name and scan for known CVEs later — is too slow.
Why the software supply chain risk matters now#
Most organizations still treat open source risk as a list problem: find vulnerable packages, upgrade them, repeat. That remains necessary. It is not enough.
A package can be dangerous without having a known CVE. A maintainer account can be compromised. A new release can add install scripts, network calls, obfuscated code, protestware, credential theft, or dependency confusion behavior. A trusted package can become untrusted because the control plane around it changed.
Feross’s comments also point to a maintainer bottleneck that gets less attention than it deserves. Open source maintainers were already carrying critical infrastructure with thin support. AI-generated issues and low-quality pull requests added noise. Now, if AI-assisted vulnerability discovery creates more valid reports, maintainers still need to review patches, understand side effects, and carry the long-term maintenance burden of accepted changes.
That last part is operationally important. A patch is not free just because a model generated it. Accepting a pull request can mean owning future compatibility, breakage, security assumptions, and release management. For a small project, even a good patch can be a cost.
Downstream users then face a hard gap. If a vulnerability is real but upstream cannot review and release quickly, organizations may be stuck choosing between exposure, local patching, forking, or compensating controls. That is not a neat dashboard problem. It is an engineering capacity problem.
This connects to a broader open source security theme we have covered before: security artifacts only matter when teams operationalize them. See also: OpenSSF’s April signal: make security artifacts operational and Open Source Security Needs More Than Code.
What to check before acting#
The practical response is not “buy a tool” or “stop using open source.” It is to tighten the points where trust enters the build.
Start with package registry controls. Know which registries your developers and CI systems can pull from. Check whether private package names can be confused with public ones. Review whether builds use pinned versions, lockfiles, checksum verification, or reproducible inputs where possible.
Look at maintainer access signals. For critical dependencies, check how many maintainers can publish, whether the project uses two-factor authentication, whether publishing is tied to individual accounts, and whether the project has moved toward trusted publishing where the registry supports it. Trusted publishing is not magic, but it can reduce reliance on long-lived tokens and make provenance easier to reason about.
Review release behavior, not just vulnerability IDs. Security operations teams should ask:
- Did a dependency add a new install script?
- Did a minor or patch release introduce new network behavior?
- Did ownership or maintainer access change recently?
- Did the package add obfuscated code or unexpected binaries?
- Are transitive dependencies changing faster than the application team can review?
Treat AI-generated code as a multiplier for these checks. If an agent suggests a dependency, the review path should not become weaker because the code “works.” In many environments, the opposite should happen: AI-assisted dependency selection needs stricter default scrutiny because the person accepting the suggestion may not know the package history.
This is also where package test coverage matters. Tests do not prove a package is safe, but broad automated coverage can make patch review less blind and reduce the cost of accepting fixes. For more on that operational angle, see 100% package test coverage is the point, not the slogan.
What not to overclaim#
The Socket post is a company blog entry tied to a funding announcement and media appearance. It is not a neutral industry report. The growth figure, valuation, and market framing come from Socket’s own material. They are still useful, but they should not be read as independent measurement of the whole supply chain security market.
The post also refers to frontier AI models finding large volumes of vulnerabilities. That claim is plausible, and it fits current industry direction, but the source excerpt does not give enough detail to evaluate severity distribution, false positive rates, disclosure quality, or patch acceptance rates. Those details matter. A flood of findings can improve security, or it can bury maintainers under triage work.
There is another limit: supply chain attacks are not one class of event. Typosquatting, dependency confusion, token theft, malicious maintainer updates, compromised CI, protestware, and vulnerable code all require different controls. A single product category cannot erase that complexity.
The stronger conclusion is narrower. Software supply chain security is becoming a runtime operational discipline, not a quarterly audit task. Teams need visibility into packages before and after install, control over who can publish and consume code, and a plan for what happens when upstream cannot move fast enough.
If AI increases both code generation and vulnerability discovery, the scarce resource will not be alerts. It will be trusted review.