vet VS harden-runner

I am working on a next-gen software composition analysis tool that can identify malicious open source packages through code analysis. Adopts a policy as code (CEL) approach to build security guardrails against risky OSS components using opinionated policies.

GitHub: https://github.com/safedep/vet

Our free and open source tool vet is integrated with the SafeDep Cloud Package Scanning Service and can be used to detect malicious packages before they are installed. vet-action is a GitHub Action that can be used to establish proactive guardrails against malicious open source packages in your GitHub Actions workflows.

Explore about SafeDep on GitHub - https://github.com/safedep/vet

Not sure if it’s relevant because you specifically mentioned about B2C.

For cyber security product, we took the open source route. We build our core technology in public as open source project.

https://github.com/safedep/vet

The commercial SaaS is for scaling and management. Our entire funnel is based on OSS. Folks who have already found value and is looking to scale their deployment.

This model works for us especially at our current stage where we are 100% engineering led.

May be try out vet as well: https://github.com/safedep/vet

vet is backed by a code analysis engine that performs malicious package (npm, pypi etc.) scanning. We recently extended it to support GitHub repository scanning as well.

It found the malicious behaviour in mcp-servers-example/bad-mcp-server.js

➡️ https://github.com/safedep/vet

Malicious code in open sources is real and people get hacked due to it as we have seen with changed-files incident, ultralytics hack and multiple such incidents. vet now supports identification of malicious OSS packages through active code analysis.

I think the conventional approach of checking for vulnerabilities in 3rd party dependencies by querying CVE or some other database has set the current behaviour i.e. if its not vulnerable it must be safe. This implicit trust on vulnerability databases has been exploited in the wild to push malicious code to downstream users.

I think we will see security tools shifting towards "code" as the source of truth when making safety and security decision about 3rd party packages instead of relying only on known vulnerability databases.

Take a look at vet, we are working on active code analysis of OSS packages (+ transitive dependencies) to look for malicious code: https://github.com/safedep/vet

Great points! Harden-Runner (https://github.com/step-security/harden-runner) is similar to Firejail and OpenSnitch but purpose-built for CI/CD context. Harden-Runner detected this compromise due to an anomalous outbound network request to gist.githubusercontent.com.

Interestingly, Firejail itself uses Harden-Runner in its GitHub Actions workflows! https://github.com/search?q=repo%3Anetblue30%2Ffirejail%20ha...

Disclaimer: I am a co-founder of StepSecurity.

StepSecurity Harden-Runner detected this security incident by continuously monitoring outbound network calls from GitHub Actions workflows and generating a baseline of expected behaviors. When the compromised tj-actions/changed-files Action was executed, Harden-Runner flagged it due to an unexpected endpoint appearing in the network traffic—an anomaly that deviated from the established baseline. You can checkout the project here: https://github.com/step-security/harden-runner

There’s also a hardening tool by step-security/harden-runner designed to be the first step in any job in a workflow. A word of caution - hardening RCE-as-a-service solutions is not an easy task to accomplish so using this might not be without risk.

Fortunately there is a great free online tool that help you by doing all the hard work (it will open a pull-request and automatically fix issues).

If using GitHub Actions for CI/ CD, Harden Runner (https://github.com/step-security/harden-runner) can be used to audit and block DNS exfiltration. Outbound calls from CI are predictable (to source repo, artifact registry, etc.) and don't change often.

As part of writing tests for Harden Runner GitHub Action, which prevents such attacks, there was a need to write attack simulator for these attacks.

I am not too familiar with GitLab, to be honest, but: - Commit/PR linting (to be in tandem with semantic versioning) is implemented via third-party GitHub Actions (https://github.com/amannn/action-semantic-pull-request and https://github.com/wagoid/commitlint-github-action), these might be hard to transfer - Blocking egress to mitigate supply chain attacks is performed by step security’s Harden Runner (https://github.com/step-security/harden-runner), you may raise a question there about GitLab support - CodeQL support is GitHub only AFAIK (but you would have to verify it)

I've found StepSecurity's tooling helpful in getting my repos secured.

* https://app.stepsecurity.io/securerepo