SecNews

10月8日周四

  1. GitHub Security Blog

    How one bug bounty researcher chooses the features they investigate

    bug-bountysecurity

    As we kick off Cybersecurity Awareness Month, the GitHub Bug Bounty team is excited to spotlight one of the top-performing security researchers participating in the GitHub Security Bug Bounty Program: @vaib25vicky! The security research community makes GitHub safer for everyone—that’s the simple idea behind GitHub’s Bug Bounty Program. For more than a decade, researchers from around the world have helped us identify and fix vulnerabilities before they could be exploited, helping protect the code that powers millions of development projects. As AI-powered experiences such as GitHub Copilot and the Copilot coding agent reshape how software is built, partnering with skilled researchers across both traditional and emerging attack surfaces matters more than ever. This year marked a new chapter for our program. We restructured our bounty tables around a core shift in what we incentivize: you don’t earn more by submitting more—you earn more by submitting better. As part of this change, we formalized a permanent, invite-only VIP program for researchers who consistently deliver high-quality, high-impact work. VIP researchers receive: Significantly higher payouts—up to $30,000 or more for critical findings Faster response times on their submissions Early previews of beta products and features before public launch The path to the VIP program is based on demonstrated, consistent quality. Researchers who have one critical, two high, four medium, or seve

9月28日周一

  1. GitHub Security Blog

    How we found 24 Android vulnerabilities using our open source AI security agent

    github-security-labsecurity

    With the rise of AI in the security space, our team created the GitHub Security Lab Taskflow Agent as a way for security researchers to easily automate, package, and share the AI prompts and workflows that they find effective for their work. In this blog post, I’ll share how I created auditing taskflows to find vulnerabilities in Android applications. While new models are getting better at understanding code, custom taskflow prompts let security researchers guide them—splitting research into incremental steps to help the LLM find complex vulnerabilities faster, or that it would have missed entirely. Using these taskflows, I’ve reported more than 20 vulnerabilities in Android applications. You can check out our advisories page to see when new vulnerabilities are disclosed. Otherwise, keep reading for a few concrete examples of high-impact vulnerabilities that these taskflows found. How to run the taskflows on your own project Want to get started right away? The taskflows are open source and easy to run yourself. Please note: A GitHub Copilot license is required, and the prompts will use premium model requests. Running the taskflows can result in many tool calls, which can easily consume a large amount of tokens. Go to the seclab-taskflows repository and start a codespace. Wait a few minutes for the codespace to initialize. In the terminal, run ./scripts/audit/run_mobile.sh myorg/myrepo It might take an hour or two to finish on a medium-sized repository. When

9月24日周四

  1. GitHub Security Blog

    AI-powered fuzzing with the GitHub Security Lab Taskflow Agent

    ai--mlapplication-security

    If you’re new to fuzzing and want to learn the fundamentals first, check out our Fuzzing 101 course at gh.io/fuzzing101. Continuous fuzzing is not a magic solution that solves all your problems . Even projects that have been enrolled in OSS-Fuzz for years can still hide critical bugs, and the reason is almost always the same: someone needs to keep an eye on coverage, write new harnesses for the code that nobody is reaching, and triage the crashes that come out the other end. In other words, fuzzing still needs a human in the loop. So the natural question I kept asking myself was: how much of that human work can we actually hand over to an LLM agent? That is what led me to build the Fuzzing Taskflow, an autonomous fuzzing pipeline for C/C++ projects. You only need to point it at a GitHub repository, and it does the rest: it identifies the suitable entrypoints, analyzes the build system, writes the harnesses, runs AFL++, reads the coverage reports, improves the harnesses, triages every crash, and writes a vulnerability report for each unique bug, all without a human babysitting it. The Fuzzing Taskflow is built on top of the GitHub Security Lab Taskflow Agent, our framework for writing LLM-driven security automation, so the pipeline is expressed as a set of taskflows that an agent runs end to end. In this post, I’ll walk you through how it works and the design decisions behind it. Let’s get going! How to run it The simplest way to run it’s just to go to

8月27日周四

  1. GitHub Security Blog

    OpenClaw went viral. Meet the maintainers building and securing it.

    maintainersopen-source

    What began as a personal experiment quickly became a global open source project with extraordinary momentum. OpenClaw is a personal AI assistant that runs on users’ devices and connects with the messaging channels they already use. Started by Peter Steinberger as a weekend project in November 2025, its GitHub repository has grown to approximately 388,000 stars, 81,000 forks, and more than 80,000 commits by August 26, 2026. In this video interview, filmed just six months into the project, creator Peter Steinberger and several OpenClaw maintainers discuss managing a surge of pull requests, rethinking contributor trust and code review, addressing software supply chain risks, and balancing powerful agent capabilities with security. They also share security lessons from the GitHub Secure Open Source Fund and the value of connecting with maintainers facing similar challenges. Watch the full video above, then explore the key lessons below. People in this video The following maintainers shared their experiences maintaining and securing OpenClaw. Peter Steinberger, Creator of OpenClaw Brad Groux, CEO, Digital Meld Josh Avant, Member of technical staff, OpenClaw Foundation Josh Lehman, Martian Engineering Sally O’Malley, Principal software engineer at Red Hat Val Alexander, OpenCoven Vincent Koc, Chief architect, OpenClaw Foundation Here are the top 10 lessons that we took away from the conversation. Lessons 1–3: How AI changed contributions and community 1. Pull requ

8月13日周四

  1. GitHub Security Blog

    What 50 open source projects taught us about security in the AI era

    maintainersopen-source

    AI is changing the pace of open source development and the security challenges that come with it. Maintainers are reviewing unfamiliar contributions, managing new attack surfaces, and responding to vulnerabilities with limited time and resources. Session 4 of the GitHub Secure Open Source Fund tested a practical response. The Secure Fund invested more than $500,000 across 50 projects, pairing maintainers with GitHub Security Lab experts, GitHub security tools, AI-assisted workflows, and a peer community. One lesson emerged consistently: AI can help maintainers investigate, prioritize, and respond faster. Maintainers still provide the context, judgement, and accountability required to decide what ships. OpenClaw was invited to participate in Session 4 because it is GitHub’s fastest-growing open source project, and its maintainers wanted to strengthen its security posture. By the end of Session 4, OpenClaw developed an incident response plan, expanded its use of GitHub security tooling, audited its GitHub Actions workflows, and strengthened its processes for identifying and responding to security issues. The maintainers shared: OpenClaw’s experience reflects the broader story of Session 4. While the specific risks varied across the cohort, maintainers shared a consistent need: the knowledge, tools, and expert support to secure software as AI changed how they built it. Across the program, maintainers turned that support into concrete security improvements. Projects s

8月6日周四

  1. GitHub Security Blog

    How we took malware advisories beyond npm

    securitysupply-chain-security

    A compromised package can steal credentials the moment you install it, and until recently, GitHub could only flag those in npm. Not anymore. This is the story of how the supply chain engineering team behind Dependabot expanded malware advisories to eight ecosystems by building on OpenSSF’s shared malicious packages data. Here’s where things stand: earlier this year, Dependabot started flagging malware in your npm dependencies. Great news if you write JavaScript. Now we’re bringing that same functionality to PyPI. We’ve enhanced the GitHub Advisory Database to ingest malware reports from OpenSSF’s malicious-packages repository, which means malware advisories and the Dependabot alerts they power cover all eight major package ecosystems: npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io, and PHP Composer. I lead the Dependabot team in GitHub’s supply chain security organization, and in this post, I’ll show you how this pipeline works. From one ecosystem to eight The Advisory Database has imported vulnerability data from external sources for years. RubySec for gems, RustSec for crates, PyPA for Python. Each one is an importer that reads a public advisory repo and maps records into our database. Malware was the odd one out: it flowed through a separate, internal, npm-only path, built around GitHub’s own detection of malicious npm packages. Expanding the existing detection from one to eight supported ecosystems would have taken us year

7月29日周三

  1. GitHub Security Blog

    Tame Dependabot: Group your updates, slow the cadence, keep security fast

    engineeringsecurity

    If you maintain an active repository, you know the feeling. You open your notifications on a Monday morning and there they are: five, 10, sometimes a dozen Dependabot pull requests, each bumping a single dependency by a single patch version. Individually, every one of them is helpful. Collectively, they’re noise. And noise is how important updates get ignored. We looked at Microsoft’s GCToolkit, an open source Java library for analyzing garbage collection logs. As of July 2026, a git log of the repository showed that 92 of its 578 commits, roughly one in six, were Dependabot version bumps, with 61 in the previous 12 months alone, sometimes several in a single day. That’s a lot of review, merge, and CI cycles spent on routine maintenance. The good news: Dependabot already ships with the features to fix this. In a recent pull request, the project changed its dependabot.yml in three small but meaningful ways, turning a daily drip of single-dependency pull requests into a predictable, grouped, monthly batch per ecosystem. Here’s what changed, why it works, and how to apply the same pattern to your own repositories, following the GCToolkit example. The problem: Good defaults, wrong cadence Here’s what GCToolkit’s configuration looked like before: version: 2 updates: - package-ecosystem: github-actions directory: "/" schedule: interval: daily open-pull-requests-limit: 10 This is a common starting point, but the daily interval here was a deliberat

7月28日周二

  1. GitHub Security Blog

    Disrupting supply chain attacks on npm and GitHub Actions

    securitysupply-chain-security

    In the past year, there’s been a pattern of supply chain attacks that target weaknesses in package repositories and CI/CD systems to quickly spread malware to hundreds of open source projects. This malware seeks to exfiltrate credentials both to broadly spread the attack, as well as for later exploitation. We’ve written a few times about our plans for hardening the supply chain: Our plan for a more secure npm supply chain in September 2025, Strengthening supply chain security: Preparing for the next malware campaign in December 2025, and What’s coming to our GitHub Actions 2026 security roadmap in March 2026. In this post, we’re updating you on changes we’ve implemented that directly disrupt some of the most common and impactful supply chain attack techniques. Anatomy of supply chain attacks Supply chain attacks chain together several weaknesses, and there is no single security capability that can stop them. Addressing them takes a holistic approach, prioritizing the mitigations that break the most impactful links in the attack chain. Our teams have been studying these attacks to deploy several improvements that disrupt them and limit their impact. This is possible thanks to collaboration with the security research and developer communities. The attacks vary in how they spread across the software ecosystem. However, most of these attacks follow similar techniques to gain initial access to a project, escalate privileges, and distribute across user