# supply chain attacks Cybersecurity attacks in which an adversary exploits vulnerabilities in a product or service supply network to access, disrupt, manipulate, or exfiltrate data from the intended target. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## We Will Not Sabotage Your Code DevFeed: [We Will Not Sabotage Your Code]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-03T00:00:00Z Content type: opinion Language: en Sources: [CodeName One]() Topics: [prompt injection](), [Open Source](), [supply chain attacks](), [Maintainers](), [Artificial Intelligence]() Tags: [agents](), [ai](), [maintainers](), [open-source](), [prompt-injection](), [supply-chain-attacks](), [trust]() ### AI overview This opinion argues that embedding a destructive prompt-injection payload targeting AI agents in an open-source framework is sabotage and a serious breach of maintainer trust. It rejects weaponizing dependencies against downstream users while acknowledging fears about AI's effects on developers and expressing optimism about AI's potential for open source. ### Source excerpt A maintainer hid a destructive prompt-injection payload aimed at AI agents inside his own framework. That is a betrayal of the trust open source runs on. Here is where we stand, and why I think AI is the biggest opportunity small OSS players have ever had. ## Stytch & Latacora: A Security Partnership Retrospective DevFeed: [Stytch & Latacora: A Security Partnership Retrospective]() Original publisher: [Read original article]() Published: 2026-05-22T16:00:00Z Content type: article Language: en Sources: [Latacora]() Topics: [Security](), [Authentication](), [Incident response](), [SIEM, Security, Observability](), [supply chain attacks](), [MFA]() Tags: [2025](), [acquisition](), [authentication](), [incident-response](), [integration](), [partnership](), [retrospective](), [security](), [siem](), [supply-chain-attacks]() ### AI overview A retrospective on Stytch and Latacora's security partnership from 2021 through Stytch's acquisition by Twilio. It describes building security into passwordless authentication infrastructure, scaling detection and response, addressing SAML vulnerabilities and supply chain attacks, and maintaining monitoring during the acquisition. ### Source excerpt From growing startup to Twilio integration # Stytch and Latacora worked side by side to ensure that the developers and end users relying on Stytch's platform benefited from a security program built for the sensitivity and criticality of the data involved. This journey, which began in February 2021, saw Stytch grow from an ambitious startup building passwordless authentication infrastructure into a mature platform, ultimately acquired by Twilio. ## Cyber resiliency in practice: Lessons from recent supply chain attacks DevFeed: [Cyber resiliency in practice: Lessons from recent supply chain attacks]() Original publisher: [Read original article]() Published: 2026-05-08T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [resiliency](), [supply chain attacks](), [supply-chain-security](), [axios](), [GitHub Actions](), [litellm](), [trivy](), [npm](), [PyPI](), [Python](), [Large Language Model]() Tags: [axios](), [chainguard-libraries](), [cyber-resiliency](), [cybersecurity](), [github-actions](), [litellm](), [malware](), [npm](), [pypi](), [python](), [security](), [security-attacks](), [social-engineering](), [software-supply-chain-security](), [supply-chain-attacks](), [trivy](), [worm]() ### AI overview The article defines cyber resiliency as an integrated ability to anticipate, withstand, recover from, and adapt to attacks across the full Protect, Detect, Respond, and Recover lifecycle. It examines recent supply chain attacks involving Trivy, Axios, and LiteLLM, highlighting risks such as GitHub Actions misconfiguration, long-lived tokens, incomplete credential rotation, mutable Git tags, maintainer-account compromise, and malicious package releases. ### Source excerpt Learn how modern cyber resiliency helps organizations prevent, detect, and recover from supply chain attacks like Trivy, Axios, and LiteLLM. ## Docusaurus 3.10 DevFeed: [Docusaurus 3.10]() Original publisher: [Read original article]() Author: Sébastien Lorber Published: 2026-04-07T00:00:00Z Content type: release Language: en Sources: [Docusaurus Blog]() Topics: [releases](), [Documentation](), [Security](), [supply chain attacks](), [GitHub Actions](), [MDX](), [npm](), [OpenID connect (OIDC)](), [upgrade](), [monorepo](), [pnpm]() Tags: [github-actions](), [mdx](), [monorepo](), [npm](), [oidc](), [pnpm](), [release](), [security](), [supply-chain-attacks](), [upgrade]() ### AI overview Docusaurus 3.10 is the final release in the v3.x line and prepares sites for Docusaurus v4. It introduces future flags for upcoming breaking changes, makes Docusaurus Faster stable, and adds supply-chain security measures including npm Trusted Publishing, OIDC-based GitHub Actions releases, provenance records, and dependency checks. ### Source excerpt We are happy to announce Docusaurus 3.10. ## Pinning GitHub Actions DevFeed: [Pinning GitHub Actions]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2025-11-17T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [GitHub Actions](), [Security](), [supply chain attacks](), [CI/CD](), [Dependabot]() Tags: [also](), [ci-cd](), [commit](), [dependabot](), [github-actions](), [security](), [supply-chain-attacks](), [workflow]() ### AI overview This tutorial explains why GitHub Actions should be pinned to full commit SHAs instead of mutable tags or branches. It describes the security and auditability benefits and introduces caarlos0/pinata, a tool that automates pinning and creates pull requests for review. ### Source excerpt If you're using GitHub Actions in your projects, you should be pinning your actions to specific commit SHAs instead of using tags or branches. ## Google introduces OSS Rebuild for reproducible open-source package artifacts DevFeed: [Google introduces OSS Rebuild for reproducible open-source package artifacts]() Original publisher: [Read original article]() Author: Kimberly Samra (noreply@blogger.com) Published: 2025-07-21T21:34:00Z Content type: release Language: en Sources: [Google Online Security]() Topics: [open-source-security](), [Open Source](), [supply chain attacks](), [npm](), [PyPI](), [Rust]() Tags: [announce](), [none](), [npm](), [open-source](), [open-source-security](), [pypi](), [rust](), [slsa](), [supply-chain-attacks]() ### AI overview Google announced OSS Rebuild, a project that reproduces upstream package artifacts to provide build definitions, SLSA provenance, and verification tools for PyPI, npm, and Crates.io packages. ### Source excerpt Posted by Matthew Suozzo, Google Open Source Security Team (GOSST) Today we're excited to announce OSS Rebuild, a new project to strengthen trust in open source package ecosystems by reproducing upstream artifacts. As supply chain attacks continue to target widely-used dependencies, OSS Rebuild gives security teams powerful data to avoid compromise without burden on upstream maintainers. The project comprises: Automation to derive declarative build definitions for existing PyPI (Python), npm (JS/TS), and Crates.io (Rust) packages. SLSA Provenance for thousands of packages across our supported ecosystems, meeting SLSA Build Level 3 requirements with no publisher intervention. Build observability and verification tools that security teams can integrate into their existing vulnerability management workflows. Infrastructure definitions to allow organizations to easily run their own instances of OSS Rebuild to rebuild, generate, sign, and distribute provenance. Challenges Open source software has become the foundation of our digital world. From critical infrastructure to everyday applications, OSS components now account for 77% of modern applications. With an estimated value exceeding $12 trillion, open source software has never been more integral to the global economy. Yet this very ubiquity makes open source an attractive target: Recent high-profile supply chain attacks have demonstrated sophisticated methods for compromising widely-used packages. Each incident erodes trust in open ecosystems, creating hesitation among both contributors and consumers. The security community has responded with initiatives like OpenSSF Scorecard, pypi's Trusted Publishers, and npm's native SLSA support. However, there is no panacea: Each effort targets a certain aspect of the problem, often making tradeoffs like shifting work onto publishers and maintainers. Our Aim Our aim with OSS Rebuild is to empower the security community to deeply understand and control their supply chains by makin ## Blog: Detecting Supply Chain Attacks with Falco Actions DevFeed: [Blog: Detecting Supply Chain Attacks with Falco Actions]() Original publisher: [Read original article]() Published: 2025-03-19T00:00:00Z Content type: tutorial Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [supply chain attacks](), [GitHub Actions](), [Security](), [GitHub](), [Containers](), [Kubernetes](), [Linux Kernel]() Tags: [cicd](), [falco](), [github-action](), [github-actions](), [kubernetes](), [linux](), [linux-kernel](), [pull-request](), [runtime-security](), [security](), [software-supply-chain](), [supply-chain-attacks](), [supplychain]() ### AI overview This tutorial explains how to use Falco Actions in GitHub Actions workflows to detect suspicious behavior and software supply chain attacks in CI/CD pipelines. It covers runtime monitoring, custom rules, workflow setup, findings, and generated reports. ### Source excerpt The recently discovered CVE for the GitHub action tj-actions/changed-files brought to light a topic that is really critical for companies: supply chain attacks. With that, we want to discuss and show a bit about how Falco can help your organization detect this kind of attack and other suspect behaviors inside your CI/CD pipeline. What is Falco? Falco is a cloud native security tool that provides runtime security across hosts, containers, Kubernetes, and cloud environments. It leverages custom rules on Linux kernel events and other data sources through plugins, enriching event data with contextual metadata to deliver real-time alerts. Falco enables the detection of abnormal behavior, potential security threats, and compliance violations. What is Falco Actions? Falco Actions enable you to run Falco in GitHub Actions to detect suspicious behavior in your CI/CD workflows. If you run it in a pull request, the action will create a comment with the findings. Thanks to ad-hoc Falco rules specific to this use case, these GitHub actions can monitor your GitHub runner and detect software supply chain attacks. Using Falco Actions To have Falco inside your pipeline, you need to add these two actions: falcosecurity/falco-actions/start falcosecurity/falco-actions/stop Below you can see an example: name: CI on: push: pull_request: jobs: build: runs-on: ubuntu-latest permissions: contents: read actions: read steps: - uses: actions/checkout@v4 - name: Start Falco uses: falcosecurity/falco-actions/start@main with: mode: live falco-version: '0.40.0' verbose: true - name: My Custom Step run: | echo "This is my custom step" - name: Stop Falco uses: falcosecurity/falco-actions/start@main with: mode: live verbose: true OBS: main is being used here only to simplify how it works, you should always pin your dependencies to a specific commit SHA. After the execution, you will be able to see the results at the github action summary. If you want a more detailed report, you can use the action fal ## Mitigating software supply chain risks through faster vulnerability response and verified software images DevFeed: [Mitigating software supply chain risks through faster vulnerability response and verified software images]() Original publisher: [Read original article]() Published: 2024-04-16T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [supply-chain-security](), [Vulnerabilities](), [open-source-security](), [chainguard images](), [supply chain attacks]() Tags: [auditability](), [chainguard-images](), [cve-2024-3094](), [golang](), [liblzma](), [sbom](), [software-bill-of-materials](), [software-supply-chain](), [supply-chain-attacks](), [supply-chain-integrity](), [supply-chain-security](), [vulnerabilities](), [xz](), [xz-backdoor](), [zero-trust]() ### AI overview The article discusses the xz vulnerability, the risk of future software supply chain attacks, and the importance of rapid patch propagation and software inventory auditability. It presents Chainguard Images as a continuously verified and auditable approach to mitigating these risks. ### Source excerpt Software backdoors are a threat. Learn how to mitigate supply chain security risks by responding faster to vulnerabilities like the xz flaw. ## Securing Open Source Infrastructure DevFeed: [Securing Open Source Infrastructure]() Original publisher: [Read original article]() Author: ben@goteleport.com (Ben Arent) Published: 2021-05-25T00:00:00Z Content type: opinion Language: en Sources: [Teleport]() Topics: [Open Source](), [Cybersecurity](), [open-source-security](), [supply chain attacks](), [GitHub](), [GitLab](), [CI/CD](), [Kubernetes](), [dashboards](), [Databases]() Tags: [ci-cd](), [cybersecurity](), [databases](), [github](), [gitlab](), [kubernetes](), [monitoring](), [open-source](), [servers](), [supply-chain-attacks]() ### AI overview Teleport describes how open source projects can secure infrastructure access, including CI/CD systems, monitoring dashboards, databases, servers, and Kubernetes clusters. It promotes free Teleport Pro accounts, security audits, and collaboration features for open source projects. ### Source excerpt Teleport is offering a free Teleport Pro account for Open Source Projects. Helping teams and projects secure and collaborate at scale. ## How I gained commit access to Homebrew in 30 minutes DevFeed: [How I gained commit access to Homebrew in 30 minutes]() Original publisher: [Read original article]() Author: Remind Published: 2018-08-07T00:00:00Z Content type: article Language: en Sources: [Remind]() Topics: [Homebrew](), [Security](), [supply chain attacks](), [Jenkins](), [GitHub](), [Environment Variables](), [OAuth](), [GitHub API](), [incident]() Tags: [backdoor](), [credential-theft](), [curl](), [environment-variables](), [github](), [homebrew](), [incident](), [jenkins](), [npm](), [permissions](), [rubygems](), [security](), [supply-chain-attacks]() ### AI overview A security researcher describes gaining commit access to Homebrew repositories through a GitHub API token exposed in a publicly accessible Jenkins environment. The access was tested and then reported to Homebrew maintainers, highlighting risks to package-manager infrastructure and software supply chains. ### Source excerpt This issue was publicly disclosed on the Homebrew blog at https://brew.sh/2018/08/05/security-incident-disclosure/ Since the recent NPM, RubyGems, and Gentoo incidents, I've become increasingly interested, and concerned, with the potential for package managers to be used in supply chain attacks to distribute malicious software. Specifically with how the maintainers and infrastructure of these projects can be targeted as an attack vector. On Jun 31st, I went in with the intention of seeing if I could gain access to Homebrew's GitHub repositories. About 30 minutes later, I made my first commit to Homebrew/homebrew-core. Let's get leaky My initial strategy going in was based on credential theft; find if there were any credentials leaked by members of the Homebrew GitHub org. An OSSINT tool from Michael Henriksen called gitrob makes automating this search really easy. I ran it across the Homebrew organization, but ultimately didn't come up with anything interesting. Next, I took a look at previously disclosed issues on https://hackerone.com/Homebrew. From there, I found that Homebrew runs a Jenkins instance that's (intentionally) publicly exposed at https://jenkins.brew.sh. After some digging, I noticed something interesting; builds in the "Homebrew Bottles" project were making authenticated pushes to the BrewTestBot/homebrew-core repo: This got me thinking, "where are the credentials stored?". I noticed the "Environment Variables" link on the left, which led to an exposed GitHub API token: I tested it locally to see what scopes the token had: $ curl https://api.github.com/user/repos -u $GITHUB_API_TOKEN:x-oauth-basic | jq '.[] | {repo: .full_name, permissions: .permissions}' { "repo": "BrewTestBot/homebrew-core", "permissions": { "admin": true, "push": true, "pull": true } } { "repo": "Homebrew/brew", "permissions": { "admin": false, "push": true, "pull": true } } { "repo": "Homebrew/formulae.brew.sh", "permissions": { "admin": false, "push": true, "pull": true } } { "