harden-runner VS secure-repo

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

I agree. There are projects such as https://github.com/ossf/package-analysis and https://github.com/step-security/harden-runner that do behavior analysis. Disclaimer: I’m maintainer of the second one.

So if you are concerned about this, I'd suggest looking at the following:

* OpenSSF Scorecard Action - https://github.com/ossf/scorecard#scorecards-github-action

* Step Security Harden Action - https://github.com/step-security/harden-runner

I realize that this means trusting these providers but they seem at least tacitly blessed by GitHub. https://docs.github.com/en/actions/security-guides/security-...

Few hours back several malicious packages were released on npm registry. This video shows how some of these packages are making outbound calls as part of the preinstall step when executed in a GitHub Actions workflow. DNS Exfiltration and network calls detected by Harden-Runner GitHub Action https://github.com/step-security/harden-runner

I am excited to share Secure-Repo, an open-source project that can easily secure your GitHub repository through automated security fixes. The project aims to automate common security fixes, so developers do not have to wade through documentation.

It does not require any App installation or onboarding steps, you can just enter your public repository and click on a button to improve security through automated pull requests.

I invite you to try Secure-Repo on your public repository using the hosted version at http://app.stepsecurity.io/securerepo and share your feedback.

Important open-source repositories have adopted the tool. Here are a few example pull requests created by the maintainers of Electron, Ruby, and GoogleCloudPlatform using this project.

Electron: https://github.com/electron/electron/pull/36363

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

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

The problem we are trying to solve is to automatically calculate what the minimum GITHUB_TOKEN permissions should be for a given workflow. We are solving this problem by building a knowledge base of permissions needed by each GitHub Action. If you own a GitHub Action, contribute to the SecureWorkflows project by adding a YAML file describing the permissions your Action needs.

List of merged pull requests for the 30 critical projects can be found here: https://github.com/step-security/secure-workflows/issues/462