-
changed-files
:octocat: Github action to retrieve all (added, copied, modified, deleted, renamed, type changed, unmerged, unknown) files and directories.
Yes. It was probably a maintainer's creds being compromised.
The [malicious commit is masquerading as a commit from Renovate](https://github.com/tj-actions/changed-files/commit/0e58ed867...)((https://github.com/apps/renovate) but it's not a `verified` commit (and so it's trivial for a bad actor to masquerade as them).
https://stackoverflow.com/questions/67609381/why-do-all-my-g...
-
Civic Auth
Auth in Less Than 5 Minutes. Civic Auth comes with multiple SSO options, optional embedded wallets, and user management — all implemented with just a few lines of code. Start building today.
-
heh, timing is everything https://github.com/chains-project/maven-lockfile/issues/1085...
> After some cleanup the changed-files (https://github.com/tj-actions/changed-files) action seems to be more work to remove. It would be awesome if it could be added to the allowlist
> Done. Allowed all versions of this action. Should I pin it to one version in the allowlist (won't be convenient if renovate updates this dependency)?
-
OpenSSF scorecard flags dependencies (including GitHub actions) which aren’t pinned by hash
https://scorecard.dev/
https://github.com/ossf/scorecard/blob/main/docs/checks.md#p...
-
But I quickly got tired of doing it manually so I put together this [0] quick and dirty script to handle it for me. It just updates all workflow files in a repo and can be also used as a pre-commit hook to catch any unpinned steps in the future. It’s nothing fancy (leveraging ls-remote), but it’s saved me some time, so I figured I’d share in case it helps someone else :)
[0] https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov...
-
In recent years, it's started to feel like you can't trust third-party dependencies and extensions at all anymore. I no longer install npm packages that have more than a few transitive dependencies, and I've started to refrain from installing vscode or chrome extensions altogether.
Time and time again, they either get hijacked and malicious code added, or the dev themselves suddenly decides to betray everyone's trust and inject malicious code (see: Moq), or they sell out to some company that changes the license to one where you have to pay hundreds of dollars to keep using it (e.g. the recent FluentAssertions debacle), or one of those happens to any of the packages' hundreds of dependencies.
Just take a look at eslint's dependency tree: https://npmgraph.js.org/?q=eslint
Can you really say you trust all of these?
-
gh-action-pypi-publish
The blessed :octocat: GitHub Action, for publishing your :package: distribution files to PyPI, the tokenless way: https://github.com/marketplace/actions/pypi-publish
I've always felt uncomfortable adding other people's actions to my GitHub workflows, and this is exactly the kind of thing I was worried about.
I tend to stick to the official GitHub ones (actions/setup-python etc) plus the https://github.com/pypa/gh-action-pypi-publish one because I trust the maintainers to have good security habits.
-
verify-changed-files
:octocat: Github action to verify file changes that occur during the workflow execution.
Does anyone know if https://github.com/tj-actions/verify-changed-files/ was compromised as well?
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
Don’t want to be alarmist but even if not using this action directly, I wonder what implications might be if this has leaked tokens from prominent public-facing project repos which might be used by several folks? I spotted an issue[1] to fix this in Expo EAS CLI and I’m guessing there are many more. The payload I saw from the report only seems to dump things to stdout but I guess analysis is still in progress and IDK if it’s the same payload for all the tags.
[1]: https://github.com/expo/eas-cli/pull/2948/files
-
Looks like a lot of them are pinning to tags (which are not guaranteed to change) or SHA (https://github.com/vitejs/vite/blob/8da04227d6f818a8ad9efc00...) which is more hermetic.
-
crxviewer
Add-on / web app to view the source code of Chrome / Firefox / Opera 15 extensions and zip files.
This is why I fork the extensions I use, with the exception of uBlock. Basically just copy the extension folder, if I can't find it on GitHub. That way I can audit the code and not have to worry about an auto-update sneaking in something nefarious. I've had two extensions in the past suddenly start asking for permissions they definitely did not need, and I suspect this is why.
Btw, here's a site where you can inspect an extension's source code before you install it: https://robwu.nl/crxviewer/
-
Yes. It was probably a maintainer's creds being compromised.
The [malicious commit is masquerading as a commit from Renovate](https://github.com/tj-actions/changed-files/commit/0e58ed867...)((https://github.com/apps/renovate) but it's not a `verified` commit (and so it's trivial for a bad actor to masquerade as them).
https://stackoverflow.com/questions/67609381/why-do-all-my-g...
-
I've found firejail to be a useful tool for this (https://github.com/netblue30/firejail), and additionally use opensnitch (https://github.com/evilsocket/opensnitch) to monitor for unexpected network requests.
For CI/CD using something like ArgoCD let's you avoid giving CI direct access to prod - it still needs write access to a git repo, and ideally some read access to Argo to check if deployment succeeded but it limits the surface area.
-
I've found firejail to be a useful tool for this (https://github.com/netblue30/firejail), and additionally use opensnitch (https://github.com/evilsocket/opensnitch) to monitor for unexpected network requests.
For CI/CD using something like ArgoCD let's you avoid giving CI direct access to prod - it still needs write access to a git repo, and ideally some read access to Argo to check if deployment succeeded but it limits the surface area.
-
harden-runner
Harden-Runner is a CI/CD security agent that works like an EDR for GitHub Actions runners. It monitors network egress, file integrity, and process activity on those runners, detecting threats in real-time.
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...
-
paths-filter
Conditionally run actions based on files modified by PR, feature branch or pushed commits
https://github.com/dorny/paths-filter ? looking into it.
Definitely going through and pinning all my 3rd party actions to specific commits e.g. party/package@.
-
-
I think a big part of the problem is the way one typically "installs" a GH action: by copy-pasting something from README of the action.
Let's have a look at a random official GH provided action:
https://github.com/actions/checkout
It lists the following snippet:
`uses: actions/checkout@v4`
Everyone will just copy paste this snippet and call it a day.
In case of npm/yarn deps, one would often do the same, and copy paste `yarn install foobar`, but then when installing, npm/yarn would create a lockfile and pin the version. Whereas there's no "installer" CLI for GH actions that would pin the version for you, you just copy-paste and git push.
To make things better, ideally, the owners of actions would update the workflows which release a new version of the GH action, to make it update README snippet with the sha256 of the most recent release.
-
-
We've recently released open-source tools that would have easily prevented this, before anything runs or added to any pipeline:
1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: https://github.com/apiiro/PRevent
2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevant CI/CD stages: https://github.com/apiiro/malicious-code-ruleset
3. For a better understanding of the detection, the malicious code falls precisely into the patterns presented in our research: https://apiiro.com/blog/guard-your-codebase-practical-steps-...
-
malicious-code-ruleset
Focused malicious code detection ruleset, with a high protection-to-noise ratio
We've recently released open-source tools that would have easily prevented this, before anything runs or added to any pipeline:
1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: https://github.com/apiiro/PRevent
2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevant CI/CD stages: https://github.com/apiiro/malicious-code-ruleset
3. For a better understanding of the detection, the malicious code falls precisely into the patterns presented in our research: https://apiiro.com/blog/guard-your-codebase-practical-steps-...
-
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
-
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
Related posts
-
Deploying a stateless container on cloud run
-
Call for action: Exploring vulnerabilities in Github Actions
-
Push code with GitHub Actions to Google Cloud’s Artifact Registry
-
How to publish on npm with `--provenance` using Lerna-Lite
-
you must have the "bigquery.datasets.create" permission on the selected project