Stories with Tag Software Supply Chain Security

• Public secrets exposure leads to supply chain attack on GitHub CodeQL

  permalink

  Posted: 2025-03-30 19:54:46

  Verbose tl;dr

  Researchers at Praetorian discovered a vulnerability in GitHub's CodeQL system that allowed attackers to execute arbitrary code during the build process of CodeQL queries. This was possible because CodeQL inadvertently exposed secrets within its build environment, which a malicious actor could exploit by submitting a specially crafted query. This constituted a supply chain attack, as any repository using the compromised query would unknowingly execute the malicious code. Praetorian responsibly disclosed the vulnerability to GitHub, who promptly patched the issue and implemented additional security measures to prevent similar attacks in the future.

  Praetorian's blog post, "Public Secrets Exposure Leads to Supply Chain Attack on GitHub CodeQL," details a sophisticated supply chain attack targeting GitHub's CodeQL feature. CodeQL, a powerful semantic code analysis engine used for identifying vulnerabilities within software, relies on community-contributed queries to enhance its functionality. These queries are packaged and distributed as CodeQL packs, allowing users to easily integrate them into their workflows.

  The core vulnerability stemmed from the method by which CodeQL packs are built and published. Praetorian researchers discovered that during the build process, sensitive environment variables, specifically GitHub Personal Access Tokens (PATs) and other secrets like AWS credentials, were inadvertently incorporated into the final CodeQL pack. This occurred because the build process used a setup-go action which automatically included all environment variables, including these secrets, in the produced artifact.

  An attacker exploiting this vulnerability could craft a malicious CodeQL query, embed it within a seemingly innocuous CodeQL pack, and then submit it to the CodeQL marketplace. When a user or organization downloaded and executed this malicious pack, the embedded secrets would be exposed, giving the attacker access to the victim’s GitHub repositories and potentially connected cloud resources, depending on the specific secrets leaked. This is particularly concerning because CodeQL is often used in sensitive environments and by security-conscious developers, making it a high-value target.

  Praetorian researchers successfully demonstrated the feasibility of this attack by creating a proof-of-concept CodeQL pack containing a seemingly benign query. They then injected their own PAT into the build environment, which was subsequently embedded within the distributed pack. Upon execution of the pack, their proof-of-concept successfully exfiltrated the embedded PAT, proving that an attacker could gain unauthorized access.

  The researchers responsibly disclosed this vulnerability to GitHub, who acknowledged and addressed the issue by implementing several mitigations. These mitigations included implementing stricter controls on environment variables accessible during the CodeQL pack build process, revoking potentially compromised PATs, and providing guidance to CodeQL pack developers on secure development practices to prevent similar issues in the future. Furthermore, GitHub enhanced their security scanning procedures to detect and prevent the inclusion of secrets within CodeQL packs.

  The incident highlights the potential risks associated with community-contributed code and the importance of securing the software supply chain. It underscores the need for robust security measures throughout the entire development lifecycle, from code creation to distribution and execution, especially in widely used platforms like GitHub and with powerful tools like CodeQL. The vulnerability also emphasizes the critical role of responsible disclosure in addressing security vulnerabilities and protecting the broader software ecosystem.

  • GitHub
  • CodeQL
  • Security
  • Supply Chain Attack
  • Secret Exposure
  • Vulnerability
  • Software Security
  • Cybersecurity
  • Code Analysis
  • static analysis
  • Praetorian
  • Cloud Security
  • DevSecOps
  • Software Supply Chain Security

  Summary of Comments ( 8 )
  https://news.ycombinator.com/item?id=43527044

  Verbose tl;dr

  Hacker News users discussed the implications of the CodeQL vulnerability, with some focusing on the ease with which the researcher found and exploited the flaw. Several commenters highlighted the irony of a security analysis tool itself being insecure and the potential for widespread impact given CodeQL's popularity. Others questioned the severity and prevalence of secret leakage in CI/CD environments generally, suggesting the issue isn't as widespread as the blog post implies. Some debated the responsible disclosure timeline, with some arguing Praetorian waited too long to report the vulnerability. A few commenters also pointed out the potential for similar vulnerabilities in other security scanning tools. Overall, the discussion centered around the significance of the vulnerability, the practices that led to it, and the broader implications for supply chain security.

  The Hacker News post discussing Praetorian's blog post about a supply chain attack on GitHub CodeQL has generated a significant number of comments (over 100 at the time of this summary). Several compelling threads of discussion emerge from the comments section.

  A major point of discussion revolves around the responsibility and vulnerability disclosure process. Some commenters criticize GitHub for the perceived slow response and lack of transparency in addressing the reported vulnerability. Others defend GitHub, highlighting the complexity of validating and patching such vulnerabilities while minimizing disruption. The discussion delves into the nuances of responsible disclosure, balancing the need for timely patching with preventing exploitation by malicious actors. Some users question the severity of the vulnerability, arguing that exploiting it required significant effort and access.

  Another key discussion thread focuses on the technical details of the vulnerability and the attack vector. Commenters dissect the methods used by the researchers to identify and exploit the vulnerability, sharing their own insights and expertise. This includes discussion of the CodeQL query evaluation process and the potential impact of injecting malicious code. Some users express concern about the broader implications for software supply chain security, given the increasing reliance on third-party code and tools.

  Several comments analyze the specific scenario involving the use of private keys within CodeQL queries. The debate touches upon best practices for managing secrets and the potential risks of exposing sensitive information within code. Some commenters suggest alternative approaches for handling secrets in such scenarios, emphasizing the importance of secure coding practices.

  Another recurring theme is the potential impact of this vulnerability on open-source projects and the broader developer community. Commenters discuss the challenges of securing the software supply chain in the context of open-source development, where code contributions come from various sources with varying levels of security expertise. Some users express concern about the potential for similar vulnerabilities in other code analysis tools and the broader implications for software security.

  Finally, a number of comments offer practical advice and recommendations for developers and security professionals. These include tips for securing CodeQL queries, managing secrets effectively, and implementing robust security practices within the software development lifecycle. Some commenters also share resources and tools for vulnerability scanning and code analysis, highlighting the importance of proactive security measures.

  Overall, the comments section on Hacker News provides a valuable platform for discussion and analysis of the CodeQL supply chain vulnerability. The diverse range of perspectives and expertise represented in the comments contribute to a deeper understanding of the technical details, security implications, and potential solutions related to this vulnerability.

• Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

  permalink

  Posted: 2025-03-14 22:29:46

  Verbose tl;dr

  The popular GitHub Action tj-actions/changed-files was compromised and used to inject malicious code into projects that utilized it. The attacker gained access to the action's repository and added code that exfiltrated environment variables, secrets, and other sensitive information during workflow runs. This action, used by over 23,000 repositories, became a supply chain vulnerability, potentially affecting numerous downstream projects. The maintainers have since regained control and removed the malicious code, but users are urged to review their workflows and rotate any potentially compromised secrets.

  The blog post "Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos" by Step Security details a security incident involving a popular GitHub Action, tj-actions/changed-files, which was compromised and used to inject malicious code into the build processes of repositories that depended on it. This action, utilized by over 23,000 repositories, provided a convenient way to identify files changed in a given commit, a common requirement for optimizing workflows.

  The attacker gained control of the tj-actions/changed-files repository by compromising the maintainer's account. They then introduced a malicious commit, specifically version 3.6.0, that included a backdoor. This backdoor injected a malicious script, ./setup.sh, disguised as a harmless setup script. When the compromised action was executed, this script would download and execute a second-stage payload from a remote server controlled by the attacker. This second payload was capable of exfiltrating sensitive information, such as environment variables, secrets, and repository contents, from the affected workflows.

  The blog post emphasizes the severe security implications of this type of supply chain attack, where a compromised dependency can affect a large number of downstream users. It highlights the importance of verifying the integrity and provenance of third-party actions before incorporating them into CI/CD pipelines.

  The post outlines several mitigation strategies for those who may have used the compromised version. These include immediately reviewing workflow logs for suspicious activity, rotating any potentially exposed secrets, and pinning the action to a known safe version (such as 3.5.1 or earlier) or migrating to an alternative solution. The post specifically suggests the dorny/paths-filter action as a secure replacement.

  Furthermore, the article discusses broader best practices for securing GitHub Actions workflows. It recommends using OpenID Connect (OIDC) to limit the need for long-lived secrets, enabling branch protection rules to prevent unauthorized modifications to workflows, and adopting least-privilege access for GitHub Actions tokens. It also advocates for the development of mechanisms to detect anomalous behavior in workflows and alert administrators to potential compromises, such as unexpected network connections or the execution of unfamiliar scripts. The incident underlines the critical need for continuous vigilance and proactive security measures in the software supply chain.

  • GitHub
  • GitHub Actions
  • Security
  • Software Supply Chain Security
  • Supply Chain Attack
  • Compromised Action
  • tj-actions/changed-files
  • Software Security
  • Cybersecurity
  • Open Source Security
  • Dependency Security
  • Vulnerability
  • malicious code
  • code injection
  • Security Best Practices
  • Security Alert

  Summary of Comments ( 205 )
  https://news.ycombinator.com/item?id=43367987

  Verbose tl;dr

  Hacker News users discussed the implications of the tj-actions/changed-files compromise, focusing on the surprising longevity of the vulnerability (2 years) and the potential impact on the 23,000+ repositories using it. Several commenters questioned the security practices of relying on third-party GitHub Actions without thorough vetting, emphasizing the need for auditing dependencies and using pinned versions. The ease with which a seemingly innocuous action could be compromised highlighted the broader security risks within the software supply chain. Some users pointed out the irony of a security-focused action being the source of vulnerability, while others discussed the challenges of maintaining open-source projects and the pressure to keep dependencies updated. A few commenters also suggested alternative approaches for achieving similar functionality without relying on third-party actions.

  The Hacker News post discussing the compromise of the tj-actions/changed-files GitHub Action has a substantial number of comments exploring various facets of the incident and its implications.

  Several commenters discuss the nature of the vulnerability and the attacker's approach. Some point out the seemingly unsophisticated nature of the attack, highlighting the injected code's straightforward execution of a malicious payload without much obfuscation or stealth. Others analyze the specific mechanism of the compromise, noting how the attacker gained access to the maintainer's account and modified the action to include the malicious script. The relative ease with which this popular action was compromised raises concerns about the security of the software supply chain and the potential for similar attacks in the future.

  A significant thread of discussion revolves around the responsibilities of open-source maintainers and the challenges they face. Commenters acknowledge the substantial workload often borne by maintainers who volunteer their time and expertise. The incident underscores the difficulty of securing open-source projects, particularly those with a large user base, and the potential consequences of compromised dependencies. Some suggest potential solutions, including increased scrutiny of third-party actions, improved security practices for maintainers, and the development of tools to detect malicious code in actions. The discussion also touches upon the financial aspect of open-source maintenance and the need for better support and resources for maintainers.

  Several users express frustration with GitHub's handling of the situation, particularly the perceived lack of communication and transparency. Some commenters criticize the platform's security measures and suggest improvements, such as stricter verification processes for actions and more robust mechanisms for detecting and responding to compromises. Others point out the difficulty of verifying the integrity of third-party code and the need for better tools and practices to address this challenge.

  The impact of the compromise on the broader software ecosystem is also a topic of discussion. Commenters speculate on the potential consequences for the thousands of repositories that rely on the affected action, including the possibility of data breaches and other security incidents. The incident highlights the interconnected nature of the software supply chain and the potential for widespread damage from a single compromised component. Some users share their experiences dealing with the fallout from the incident, including the steps they took to mitigate the risk and ensure the security of their projects.

  Finally, there's a thread discussing the importance of supply chain security in general and the need for increased vigilance and proactive measures to protect against similar attacks in the future. Commenters suggest various strategies, including code signing, multi-factor authentication, and regular security audits. The incident serves as a wake-up call for the software development community, emphasizing the need for a more robust and secure approach to managing dependencies and protecting the software supply chain.

• A tale of several distros joining forces for a common goal: reproducible builds

  permalink

  Posted: 2025-02-08 11:38:33

  Verbose tl;dr

  Several Linux distributions, including Arch Linux, Debian, Fedora, and NixOS, are collaborating to improve reproducible builds. This means ensuring that compiling source code results in identical binary packages, regardless of the build environment or timing. This joint effort aims to increase security by allowing independent verification that binaries haven't been tampered with and simplifies debugging by guaranteeing consistent build outputs. The project involves sharing tools and best practices across distributions, improving build reproducibility across different architectures, and working upstream with software developers to address issues that hinder reproducibility.

  This FOSDEM 2025 presentation, titled "A Tale of Several Distros Joining Forces for a Common Goal: Reproducible Builds," delves into the collaborative efforts undertaken by various Linux distributions to achieve the shared objective of reproducible builds. Reproducible builds, as explained in the presentation, ensure that identical source code, when compiled on different systems or at different times, produces bit-for-bit identical binary outputs. This property is crucial for verifying the integrity and trustworthiness of software, as it allows users to independently confirm that a distributed binary corresponds precisely to the intended source code, mitigating risks associated with malicious code injection or accidental errors during the build process.

  The talk highlights the significant challenges inherent in achieving reproducible builds across diverse distribution ecosystems. These challenges stem from variations in build environments, including differences in compiler versions, system libraries, timestamps embedded in binaries, and even seemingly minor details like the order in which files are processed during the build. The presentation meticulously outlines the strategies employed by participating distributions to overcome these obstacles. This includes the development and adoption of standardized build tools and processes, the implementation of rigorous testing methodologies to identify and address reproducibility issues, and the ongoing collaborative efforts between distribution developers to share best practices and solutions.

  The presentation underscores the importance of cross-distribution collaboration, emphasizing how the shared pursuit of reproducible builds has fostered communication and cooperation among developers from different projects. This collaborative spirit has led to the development of shared tools and infrastructure, accelerating progress towards the common goal. The speakers detail specific examples of successful collaborations, showcasing how the combined expertise of multiple distributions has enabled the resolution of complex reproducibility issues that would have been difficult to address in isolation.

  Furthermore, the presentation elucidates the long-term benefits of reproducible builds for the broader open-source community. Beyond enhanced security and trustworthiness, reproducible builds facilitate easier auditing of software, simplify debugging processes, and contribute to a more transparent and reliable software development ecosystem. The speakers articulate the vision of a future where reproducible builds become the standard practice across the open-source landscape, enabling users to confidently verify the integrity of the software they rely on. They conclude by encouraging broader community involvement in the ongoing effort to achieve this crucial goal, emphasizing the collective responsibility of the open-source community to prioritize software security and trustworthiness.

  • reproducible builds
  • Software Supply Chain Security
  • linux distributions
  • distros
  • FOSDEM
  • Open Source
  • Software Development
  • Security
  • deterministic builds
  • Build Systems
  • package management
  • Software Integrity
  • AV1
  • WebM
  • video recording
  • conference talk

  Summary of Comments ( 40 )
  https://news.ycombinator.com/item?id=42982270

  Verbose tl;dr

  Hacker News commenters generally expressed support for the reproducible builds initiative, viewing it as a crucial step towards improved security and trustworthiness. Some highlighted the potential to identify malicious code injections, while others emphasized the benefits for debugging and verifying software integrity. A few commenters discussed the practical challenges of achieving reproducible builds across different distributions, citing variations in build environments and dependencies as potential obstacles. One commenter questioned the feasibility of guaranteeing bit-for-bit reproducibility across all architectures, prompting a discussion about the nuances of the goal and the acceptability of minor, non-functional differences. There was also some discussion of existing tooling and the importance of community involvement in driving the project forward.

  The Hacker News post titled "A tale of several distros joining forces for a common goal: reproducible builds" (linking to a FOSDEM 2025 video) has generated several comments discussing the merits and challenges of reproducible builds.

  Several commenters express strong support for the initiative. One highlights the critical importance of reproducible builds for security, arguing that it allows independent verification of binaries and helps prevent malicious code injection. They further emphasize that this becomes even more crucial in a world increasingly reliant on third-party dependencies. Another commenter points out the significant time and effort saved by not having to rebuild everything from source to verify integrity. This commenter also appreciates the transparency and trust it fosters.

  Some commenters delve into the practical complexities of achieving reproducible builds. One notes the difficulty of managing timestamps and build paths, suggesting potential solutions like using deterministic timestamps and containerized build environments. Another commenter brings up the challenges posed by differing build environments across various distributions, advocating for standardized build tools and procedures. They acknowledge the herculean effort required for full reproducibility but stress its ultimate worth.

  A more skeptical commenter questions the feasibility of achieving perfect reproducibility across all software, citing the inherent variability in some build processes. They suggest that while striving for reproducibility is laudable, aiming for "mostly reproducible" might be a more pragmatic goal. This commenter prompts a discussion about the acceptable level of deviation and the trade-offs between perfect reproducibility and practicality.

  One commenter draws parallels to the reproducible builds efforts in the Debian project, praising their progress and hoping that other distributions can learn from their experience. They also suggest that tools developed by the Debian project could be leveraged by other distributions to streamline their own reproducible builds efforts.

  Another thread of discussion focuses on the role of containerization technologies like Docker in facilitating reproducible builds. Commenters discuss the benefits of using containers to isolate build environments and ensure consistency across different machines. However, some also caution against relying solely on containers, emphasizing the importance of addressing reproducibility issues within the build process itself.

  Overall, the comments reflect a general enthusiasm for reproducible builds, acknowledging the inherent challenges while emphasizing the significant security and trust benefits. The discussion highlights the various technical and practical aspects involved, including build environment standardization, timestamp management, and the potential role of containerization. While some express skepticism about achieving perfect reproducibility, the overall sentiment is one of cautious optimism and a commitment to pursuing this important goal.

• Sigstore: Making sure your software is what it claims to be

  permalink

  Posted: 2025-01-21 20:34:14

  Verbose tl;dr

  Sigstore aims to solve the problem of software supply chain security by making it easy to sign software artifacts and verify those signatures. It provides free tooling and a public good transparency log, enabling developers to sign releases with short-lived certificates tied to their identities (e.g., GitHub and email). This allows users to easily verify the provenance and integrity of software, ensuring that it hasn't been tampered with and genuinely originates from the claimed source. Sigstore simplifies the complex process of code signing, removing the need for managing long-lived keys and complicated infrastructure. This makes it significantly more practical for developers to secure their software supply chains and builds trust with end users.

  Sigstore is a free and open-source service designed to dramatically improve the security of the software supply chain. It addresses the critical problem of ensuring that software you download and run is genuinely what it claims to be, originating from the expected source and not tampered with along the way. This is achieved through a novel combination of transparency, automation, and cryptographic verification using digital signatures, similar to how HTTPS secures web browsing, but applied specifically to software artifacts.

  Traditionally, verifying the provenance and integrity of software has been complex, often relying on manual processes and cumbersome key management practices. Sigstore streamlines this process by automating the generation and management of short-lived cryptographic keys, eliminating the need for developers to maintain their own long-term signing keys, which can be a significant security vulnerability if compromised. These ephemeral keys are tied to identities through OpenID Connect (OIDC), a widely adopted authentication standard used by many major identity providers. This allows developers to leverage their existing organizational identities to sign their software, simplifying the authentication process and making it more secure.

  The signed attestations, along with the software artifacts themselves, are then stored in a tamper-proof public transparency log called Rekor. This log provides a permanent and auditable record of all signed software releases, allowing anyone to independently verify the integrity and authenticity of a particular software artifact. This significantly enhances transparency within the software supply chain, making it easier to detect malicious attempts to introduce compromised software. Because the log is publicly searchable, users can verify a signature even if they don't trust the publisher directly.

  Fulcio, Sigstore's free certificate authority, issues short-lived certificates linking the signing identity and the ephemeral key. This eliminates the need for developers to manage and secure their own code signing certificates, further streamlining the signing process and minimizing the attack surface. The integration with OIDC allows developers to use their existing identity provider, making the process seamless and easily integrated into existing workflows.

  By combining keyless signing, transparency logs, and a free certificate authority, Sigstore provides a powerful and comprehensive solution for securing the software supply chain. It empowers developers to sign and verify software easily and securely, while providing end-users with the assurance that the software they are using is trustworthy and has not been tampered with. This contributes significantly to improving the overall security posture of the software ecosystem by making it more difficult for attackers to distribute malicious code disguised as legitimate software. The open-source nature of the project fosters community involvement and allows for independent audits and scrutiny, further strengthening trust in the system.

  • Software Supply Chain Security
  • Sigstore
  • Software Signing
  • Digital Signatures
  • Open Source Security
  • software verification
  • Supply Chain Attacks
  • Code Signing
  • Security
  • DevOps
  • SLSA
  • Software Integrity
  • Provenance

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=42784892

  Verbose tl;dr

  Hacker News commenters generally expressed strong support for Sigstore and its mission of improving software supply chain security. Several praised its ease of use and integration with existing tools, noting the significantly lowered barrier to entry for signing releases compared to traditional methods. Some highlighted the importance of key transparency and the clever use of OpenID Connect for identity verification. A few commenters discussed the potential impact on various ecosystems like Debian and Python, expressing hope for wider adoption and speculating on the future development of the project. Concerns were raised about the reliance on centralized services and potential single points of failure, but these were often met with counter-arguments about the federated nature of OpenID and the transparency of the log. Some users questioned the long-term viability of free certificate issuance, and others debated the nuances of different signing models and their relative security implications.

  The Hacker News post titled "Sigstore: Making sure your software is what it claims to be" (linking to sigstore.dev) generated a moderate amount of discussion with a mix of praise for the project, inquiries about its practical application, and comparisons to other security initiatives.

  Several commenters expressed enthusiasm for Sigstore, emphasizing its potential to significantly improve software supply chain security. One user highlighted the ease of use and integration with existing tools as major advantages, particularly for open-source projects where maintaining complex security infrastructure can be challenging. Another lauded the transparency and auditability provided by the public log, making it easier to track the provenance of software artifacts. The simplicity of key management using OpenID Connect was also mentioned favorably, eliminating the need for developers to manage their own private keys.

  Some commenters focused on practical considerations and sought clarification on specific aspects of Sigstore. One user questioned how Sigstore handles dependencies, asking whether it verifies the signatures of all dependencies recursively. Another raised concerns about the revocation process, wondering how compromised keys would be handled and what impact that would have on the integrity of signed artifacts. There was also a discussion about the reliance on certificate transparency logs, with some users expressing concerns about the potential for log manipulation or censorship.

  Comparisons were drawn to other security initiatives like The Update Framework (TUF) and in-toto. One commenter pointed out that while TUF addresses similar security concerns, Sigstore simplifies key management and signature verification, potentially making it more accessible to a wider range of developers. Another user noted the similarities between Sigstore and in-toto, particularly in their use of transparency logs, but highlighted Sigstore's focus on code signing as a differentiating factor.

  A few commenters expressed skepticism about the project's long-term viability, questioning whether it would gain widespread adoption and whether it truly addressed the complex challenges of software supply chain security. One user raised concerns about the potential for "security theater," suggesting that Sigstore might provide a false sense of security without addressing the root causes of vulnerabilities.

  Overall, the comments reflect a general interest in Sigstore and its potential to improve software security, but also reveal some valid concerns and questions about its practical implementation and long-term effectiveness. The discussion highlights the complexity of the software supply chain security problem and the need for multifaceted solutions.