Ever come across a Common Vulnerabilities and Exposures (CVE) ID affecting software you use or maintain and thought the information could be better? CVE IDs are a widely-used system for tracking software vulnerabilities. When a vulnerable dependency affects your software, you can create a repository security advisory to alert others. But if you want your insight to reach the most upstream data source possible, you’ll need to contact the CVE Numbering Authority (CNA) that issued the vulnerability’s CVE ID. GitHub, as part of a community of over 400 CNAs, can help in cases when GitHub issued the CVE (such as with this community contribution). And with just a few key details, you can identify the right CNA and reach out with the necessary context. This guide shows you how. Step 1: Find the CNA that issued the CVE Every CVE record contains an entry that includes the name of the CNA that issued the CVE ID. The CNA is responsible for updating the CVE record after its initial publication, so any requests should be directed to them. On cve.org, the CNA is listed as the first piece of information under the “Required CVE Record Information” header. The information is also available on the right side of the page. On nvd.nist.gov, information about the issuing CNA is available in the “QUICK INFO” box. The issuing CNA is called “Source”. Step 2: Find the contact information for the CNA After identifying the CNA from the CVE record, locate their official contact information to request updates or changes. That information is available on the CNA partners website at https://www.cve.org/PartnerInformation/ListofPartners. Search for the CNA’s name in the search bar. Some organizations may have more than one CNA, so make sure that the CVE you want corresponds to the correct CNA. The left column, under “Partner,” has the name of the CNA that links to a profile page with its scope and contact information. Step 3: Contact the CNA Most CNAs have an email address for CVE-related communications. Click the link under “Step 2: Contact” that says Email to find the CNA’s email address. The most notable exception to the general preference for email communication among CNAs is the MITRE Corporation, the world’s most prolific CVE Numbering Authority. MITRE uses a webform at https://cveform.mitre.org/ for submitting requests to create, update, dispute, or reject CVEs. What to include in your communication to the CNA The CVE ID you want to discuss The information you want to add, remove, or change within the CVE record Why you want to change the information Supporting evidence, usually in the form of a reference link Including publicly available reference links is important, as they justify the changes. Examples of reference links include: A publicly available vulnerability report, advisory, or proof-of-concept A fix commit or release notes that describe a patch An issue in the affected repository in which the maintainer discusses the vulnerability in their software with the community A community contribution pull request that suggests a change to the CVE’s corresponding GitHub Security Advisory When submitting changes, keep in mind that the CNA isn’t your only audience. Clear context around disclosure decisions and vulnerability details helps the broader developer and security community understand the risks and make informed decisions about mitigation. The time it takes for a CNA to respond may vary. Rules 3.2.4.1 and 3.2.4.2 of the CVE CNA rules state: “3.2.4.1 Subject to their respective CNA Scope Definitions, CNAs MUST respond in a timely manner to CVE ID assignment requests submitted through the CNA’s public POC. 3.2.4.2 CNAs SHOULD document their expected response times, including those for the public POC.” The CNA rules establish firm timelines for assignment of CVE IDs to vulnerabilities that are already public knowledge. For CVE ID assignment or record publication in particular, section 4.2 and section 4.5 of the CVE CNA rules establish 72 hours as the time limit in which CNAs should issue CVE IDs or publish CVE records for publicly-known vulnerabilities. However, no such guidance exists for changing a CVE record. What if the CNA doesn’t respond or disagrees with me? If the CNA doesn’t respond or you cannot reach an agreement about the content of the CVE record, the next step is to engage in the dispute process. The CVE Program Policy and Procedure for Disputing a CVE Record provides details on how you may go about disputing a CVE record and escalating a dispute. The details of that process are beyond the scope of this post. However, if you end up disputing a CVE record, it’s good to know who the root or top-level root of the CNA is that reviews the dispute. When viewing a CNA’s partner page linked from https://www.cve.org/PartnerInformation/ListofPartners, you can find the CNA’s root under the column “Top-Level Root.” For most CNAs, their root is the Top-Level Root, MITRE. Want to improve a CVE record and a CVE record’s corresponding security advisory? Learn more about editing security advisories in the GitHub Advisory Database. The post How to request a change to a CVE record appeared first on The GitHub Blog. ​ Maintainers, Open Source, Security, Vulnerability research, CNA, Community Contribution, CVE, CVE Numbering Authority, CVE quality, GitHub Security Lab, open source security The GitHub Blog

We get it: you’d rather spend your time shipping features than chasing security alerts. That’s why we’ve built tools like Copilot Autofix directly into pull requests, enabling teams to remediate security issues up to 60% faster, significantly reducing Mean Time to Remediation (MTTR) compared to manual fixes. Autofix helps you catch vulnerabilities before they ever make it into production, so you spend less time fixing bugs and more time coding. But what about the vulnerabilities already lurking in your existing code? Every unresolved security finding adds to your security debt—a growing risk you can’t afford to ignore. In fact, our data shows that teams typically address only 10% of their security debt, leaving 90% of vulnerabilities unprioritized and unresolved. Our data shows that security debt is the biggest unaddressed risk that customers face: historically, only 10% of lingering security debt in merged code gets addressed, meaning until today, 90% of risks did not get prioritized. Now, our data shows that 55% of security debt included in security campaigns is fixed. Security campaigns bridge this gap by bringing security experts and developers together, streamlining the vulnerability remediation process right within your workflow, and at scale. Using Copilot Autofix to generate code suggestions for up to 1,000 code scanning alerts at a time, security campaigns help security teams take care of triage and prioritization, while you can quickly resolve issues using Autofix—without breaking your development momentum. Security campaigns in action Since security campaigns were launched in public preview at GitHub Universe last year, we have seen organizations at all different stages of their security journey try them out. Whether they’ve been used to reduce security debt across an entire organization or to target alerts in critical repositories, security campaigns have delivered value for both developers and security teams in their efforts to tackle security debt. Security campaigns simplify life for our developers. They can easily group alerts from multiple repositories, reducing time spent on triage and prioritization while quickly remediating the most critical issues with the help of Copilot Autofix. – Jose Antonio Moreno, DevSecOps engineer, Lumen GitHub security campaigns is a game-changer for our development teams. It’s educated us about existing vulnerabilities, brought our engineers together to collaboratively tackle fixes, and significantly improved our remediation time. – GP, security engineer, Alchemy In a sample of early customers, we found that 55% of alerts included in security campaigns were fixed, compared to around only 10% of security debt outside security campaigns, a 5.5x improvement. This shows that when alerts are included in a campaign, you can spend more time fixing the security debt, since the prioritization of which alerts to work on has already been taken care of by your security team. In fact, our data shows that alerts in campaigns get roughly twice as much developer engagement than those outside of campaigns. Security campaigns: how they work Triaging and prioritizing security problems already present in a codebase has to happen as part of the normal software development lifecycle. Unfortunately, when product teams are under pressure to ship faster, they often don’t have enough time to dig through their security alerts to decide which ones to address first. Luckily, in most software organizations, there is already a group of people who are experts in understanding these risks: the security team. With security campaigns, we play to the different strengths of developers and security teams in a new collaborative approach to addressing security debt. Security teams prioritize which risks need to be addressed across their repositories in a security campaign. Security campaigns come with predefined templates based on commonly used themes (such as the MITRE top 10 known exploited vulnerabilities) to help scope the campaign. GitHub’s security overview also provides statistics and metrics summarizing the overall risk landscape. Once the campaign alerts are selected and a timeline is specified, the campaign is communicated to any developers who are impacted by the campaign. The work defined in a campaign is brought to developers where they work on GitHub, so that it can be planned and managed just like any other feature work. Copilot Autofix immediately starts suggesting automatic remediations for all alerts in a campaign, as well as custom help text to explain the problems. Fixing an alert becomes as easy as reviewing a diff and creating a pull request. Crucially, security campaigns are not just lists of alerts. Alongside the alerts, campaigns are complemented with notifications to ensure that developers are aware of which alert they (or their team) are responsible for. To foster stronger collaboration between developers and the security team, campaigns also have an appointed manager to oversee the campaign progress and be on hand to assist developers. And of course: security managers have an organization-level view on GitHub to track progress and collaborate with developers as needed. Starting today, you can also access several new features to plan and manage campaign-related work more effectively: Draft security campaigns: security managers can now iterate on the scope of campaigns and save them as draft campaigns before making them available to developers. With draft campaigns, security managers can ensure that the highest priority alerts are included before the work goes live. Automated GitHub Issues: security managers can optionally create GitHub Issues in repositories that have alerts included in the campaign. These issues are created and updated automatically as the campaign progresses and can be used by teams to track, manage and discuss campaign-related work. Organization-level security campaign statistics: security managers can now view aggregated statistics showing the progress across all currently-active and past campaigns. For more information about using security campaigns, see About security campaigns in the GitHub documentation. Try security campaigns today If your organization is already using GitHub Advanced Security or GitHub Code Security you can take advantage of security campaigns today. If you want to learn more about how GitHub Code Security can help secure your code at scale, then request a demo. The post Found means fixed: Reduce security debt at scale with GitHub security campaigns appeared first

New PowerEdge Rack Portfolio now shipping! PowerEdge XE9680 with Intel® Gaudi® 3 AI accelerators shipping!   ​  ​New PowerEdge Rack Portfolio now shipping! PowerEdge XE9680 with Intel® Gaudi® 3 AI accelerators shipping! Data Center Blog | Dell

Innovate with the new generation of Dell ObjectScale—the industry’s highest-performing object platform.   ​  ​Innovate with the new generation of Dell ObjectScale—the industry’s highest-performing object platform. ObjectScale Blog | Dell

How PowerStore’s latest release prepares you for what’s next.   ​  ​How PowerStore’s latest release prepares you for what’s next. PowerStore Blog | Dell

Unlocking new levels of flexibility, efficiency and scale to meet the demands of the modern AI data center.   ​  ​Unlocking new levels of flexibility, efficiency and scale to meet the demands of the modern AI data center. Storage Blog | Dell

Strengthening infrastructure to safeguard innovation and enable growth.   ​  ​Strengthening infrastructure to safeguard innovation and enable growth. PowerProtect Blog | Dell

IR Kinetics revolutionized real-time tracking with advanced AI technology and expert guidance from Dell Professional Services.   ​  ​IR Kinetics revolutionized real-time tracking with advanced AI technology and expert guidance from Dell Professional Services. Customer Blog | Dell

Allow us to reintroduce ourselves: GitHub Copilot is getting a whole lot more agentic with increased context of your tools and services, powered by the world’s leading models, starting today. 👏 We are excited to roll out agent mode in Visual Studio Code to all users, now complete with MCP support that unlocks access to any context or capabilities you want. What’s more, we are thrilled to release a new open source and local GitHub MCP server, giving you the ability to add GitHub functionality to any LLM tool that supports MCP. 🤖 In keeping with our commitment to offer multi-model choice, we’re making Anthropic Claude 3.5, 3.7 Sonnet, 3.7 Sonnet Thinking, Google Gemini 2.0 Flash, and OpenAI o3-mini generally available via premium requests, included in all paid Copilot tiers. These premium requests are in addition to unlimited requests for agent mode, context-driven chat, and code completions that all paid plans have when using our base model (👀 more below). With the new Pro+ tier, individual developers get the most out of the latest models with Copilot. The agent awakening doesn’t stop there. We are also announcing the general availability of the Copilot code review agent, which in just over a month in preview has been used by over 1 million developers on GitHub. Plus, the general availability of next edit suggestions so you can tab tab tab your way to coding glory. 🏆 Agent mode in VS Code Agent mode is progressively rolling out to VS Code users in stable, as we aim for full availability to all users in the coming weeks. You can also manually enable it now. Compared to chat or multi-file edits, which allow you to propose code changes across multiple files in your workspace, agent mode is fundamentally capable of taking action to translate your ideas into code. With simple prompts, agent mode takes Copilot beyond answering a question, instead completing all necessary subtasks across automatically identified or generated files to ensure your primary goal is achieved. Agent mode can suggest terminal commands or tool calls and ask you to execute them. It also analyzes run-time errors with self-healing capabilities. Since the launch to VS Code Insiders in February, developers have been using agent mode for a variety of tasks: from autofixing code gen errors, to building webapps, to yeeting commits – whatever that means. 🙂 https://x.com/xthree/status/1902748372022264142 Agent mode is powered by your choice of Claude 3.5 and 3.7 Sonnet, Google Gemini 2.0 Flash, and OpenAI GPT-4o. Currently, agent mode achieves a pass rate of 56.0% on SWE-bench Verified with Claude 3.7 Sonnet. We anticipate agent mode to grow more capable as chain of thought reasoning models continue to advance. To activate agent mode, upgrade to the latest VS Code and enable in settings. Model Context Protocol (MCP) is now available in public preview Developers spend their days conducting a wide array of tasks to get the job done, from research, to navigating telemetry, to infrastructure management, to coding and debugging. And they use many tools for this, the so-called engineering stack. MCP allows you to equip agent mode with the context and capabilities it needs to help you, like a USB port for intelligence. When you enter a chat prompt in agent mode within VS Code, the model can use different tools to handle tasks like understanding database schema or querying the web. This setup allows for more interactive and context-sensitive coding support. For example, with a prompt to “Update my GitHub profile to include the title of the PR that was assigned to me yesterday,” agent mode would take that request, combined with the list of all available MCP tools, and ask an LLM what to do next. Over time, the agent would continue calling tools iteratively, until the task is complete. Already, GitHub is home to a massive and growing MCP ecosystem that you can discover and use today. Here is a great repository that acts as a community inventory with some of the best MCP servers to use. The GitHub local MCP server equips agent mode with compelling capabilities such as searching across repositories and code, managing issues and creating PRs – turning agent mode into a powerful user of the GitHub platform. Get started by setting up local and remote MCP servers and using tools with agent mode in Visual Studio Code. To get started with the GitHub local MCP server, visit the repository, now supported natively in VS Code. Premium model requests Since GitHub Universe, we introduced a number of new models for chat, multi-file edits, and now agent mode. With the general availability of these models, we are introducing a new premium request type. Premium requests are in addition to the unlimited requests for agent mode, context-driven chat, and code completions in all paid plans for our base model (currently: OpenAI GPT-4o). Customers with Copilot Pro will receive 300 monthly premium requests, beginning on May 5, 2025. Customers with Copilot Business and Copilot Enterprise will receive 300 and 1000 monthly premium requests respectively, starting between May 12 and May 19, 2025. Until then, use of these premium models is unlimited. We are also introducing a new Pro+ plan for individuals with 1500 monthly premium requests and access to the best models, like GPT-4.5, for $39 per month. Copilot paid users1 will also have the ability to pay-as-you-go for additional premium request usage. Individuals and organizations can choose to opt-in to use additional requests beyond their included amount, in addition to setting spending limits on requests to control costs with ease. GitHub Copilot Business and Enterprise administrators can manage requests via their Copilot Admin Billing Settings. Additional premium requests start at $0.04 per request. Each premium model will consume a specific number of premium requests, allowing you to use a more powerful or efficient model when you need it, all while you have continued, unlimited access to Copilot’s base model. You can learn more about how seat-based premium requests will work in our documentation. Happy 50th birthday,

Discover how the City of Durham, NC is using AI to revolutionize city planning, safety and sustainability for its residents.   ​  ​Discover how the City of Durham, NC is using AI to revolutionize city planning, safety and sustainability for its residents. AI Solutions Blog | Dell

At GitHub Security Lab, one of the most common vulnerability types we find relates to the cross-origin resource sharing (CORS) mechanism. CORS allows a server to instruct a browser to permit loading resources from specified origins other than its own, such as a different domain or port. Many developers change their CORS rules because users want to connect to third party sites, such as payment or social media sites. However, developers often don’t fully understand the dangers of changing the same-origin policy, and they use unnecessarily broad rules or faulty logic to prevent users from filing further issues. In this blog post, we’ll examine some case studies of how a broad or faulty CORS policy led to dangerous vulnerabilities in open source software. We’ll also discuss DNS rebinding, an attack with similar effects to a CORS misconfiguration that’s not as well known among developers. What is CORS and how does it work? CORS is a way to allow websites to communicate with each other directly by bypassing the same-origin policy, a security measure that restricts websites from making requests to a different domain than the one that served the web page. Understanding the Access-Control-Allow-Origin and Access-Control-Allow-Credentials response headers is crucial for correct and secure CORS implementation. Access-Control-Allow-Origin is the list of origins that are allowed to make cross site requests and read the response from the webserver. If the Access-Control-Allow-Credentials header is set, the browser is also allowed to send credentials (cookies, http authentication) if the origin requests it. Some requests are considered simple requests and do not need a CORS header in order to be sent cross-site. This includes the GET, POST, and HEAD requests with content types restricted to application/x-www-form-urlencoded, multipart/form-data, and text/plain. When a third-party website needs access to account data from your website, adding a concise CORS policy is often one of the best ways to facilitate such communication. To implement CORS, developers can either manually set the Access-Control-Allow-Origin header, or they can utilize a CORS framework, such as RSCors, that will do it for them. If you choose to use a framework, make sure to read the documentation—don’t assume the framework is safe by default. For example, if you tell the CORS library you choose to reflect all origins, does it send back the response with a blanket pattern matching star (*) or a response with the actual domain name (e.g., stripe.com)? Alternatively, you can create a custom function or middleware that checks the origin to see whether or not to send the Access-Control-Allow-Origin header. The problem is, you can make some security mistakes when rolling your own code that well-known libraries usually mitigate. Common mistakes when implementing CORS For example, when comparing the origin header with the allowed list of domains, developers may use the string comparison function equivalents of startsWith, exactMatch, and endsWith functions for their language of choice. The safest function is exactMatch where the domain must match the allow list exactly. However, what if payment.stripe.com wants to make a request to our backend instead of stripe.com? To get around this, we’d have to add every subdomain to the allow list. This would inevitably cause users frustration when third-party websites change their APIs. Alternatively, we can use the endsWith function. If we want connections from Stripe, let’s just add stripe.com to the allowlist and use endsWith to validate and call it a day. Not so fast, since the domain attackerstripe.com is now also valid. We can tell the user to only add full urls to the allowlist, such as https://stripe.com, but then we have the same problem as exactMatch. We occasionally see developers using the startsWith function in order to validate domains. This also doesn’t work. If the allowlist includes https://stripe.com then we can just do https://stripe.com.attacker.com. For any origin with subdomains, we must use .stripe.com (notice the extra period) in order to ensure that we are looking at a subdomain. If we combine exactMatch for second level domains and endsWith for subdomains, we can make a secure validator for cross site requests. Lastly, there’s one edge case found in CORS: the null origin should never be added to allowed domains. The null origin can be hardcoded into the code or added by the user to the allowlist, and it’s used when requests come from a file or from a privacy-sensitive context, such as a redirect. However, it can also come from a sandboxed iframe, which an attacker can include in their website. For more practice attacking a website with null origin, check out this CORS vulnerability with trusted null origin exercise in the Portswigger Security Academy. How can attackers exploit a CORS misconfiguration? CORS issues allow an attacker to make actions on behalf of the user when a web application uses cookies (with SameSite None) or HTTP basic authentication, since the browser must send those requests with the required authentication. Fortunately for users, Chrome has defaulted cookies with no Samesite to SameSite Lax, which has made CORS misconfiguration useless in most scenarios. However, Firefox and Safari are still vulnerable to these issues using bypass techniques found by PTSecurity, whose research we highly recommend reading for knowing how someone can exploit CORS issues. What impact can a CORS misconfiguration have? CORS issues can give a user the power of an administrator of a web application, so the usefulness depends on the application. In many cases, administrators have the ability to execute scripts or binaries on the server’s host. These relaxed security restrictions allow attackers to get remote code execution (RCE) capabilities on the server host by convincing administrators to visit an attacker-owned website. CORS issues can also be chained with other vulnerabilities to increase their impact. Since an attacker now has the permissions of an administrator, they are able to access a broader range of services and activities, making it more likely they’ll find something vulnerable. Attackers often focus on vulnerabilities that affect the host system, such as arbitrary file write or RCE. Real-world examples A CORS misconfiguration allows for RCE

In a recent study, TechTarget’s Enterprise Strategy Group (ESG) set out to validate the benefits of adopting Dell thin client …   ​  ​In a recent study, TechTarget’s Enterprise Strategy Group (ESG) set out to validate the benefits of adopting Dell thin client … Customer Blog | Dell

Dell Pro Docks simplify IT with secure and manageable docking solutions for the AI PC. Featuring four new docks & powerful management tools.   ​  ​Dell Pro Docks simplify IT with secure and manageable docking solutions for the AI PC. Featuring four new docks & powerful management tools. Client Peripherals Blog | Dell

Welcome back to season two of GitHub for Beginners, a series designed to help you navigate GitHub more confidently! So far, we’ve explored how to use GitHub Copilot and some of its essential features. Today, we will be learning all about large language models (LLMs) and the basics of prompt engineering. LLMs are powerful, and the way we interact with them via prompts matters. For example, have you ever tried asking an LLM a question, but it can’t really figure out what you’re trying to ask? Understanding the power of prompts (and the limitations that come with them) can help you become even more productive. In this post, we’ll explore: How LLMs work and how prompts are processed. How to engineer the most effective prompts. How to troubleshoot prompts when we don’t get the outcomes we want. For all demos in this series, we use GitHub Copilot in Visual Studio Code. Copilot is available in other IDEs, but the available functionality may vary depending on your environment. Learn more about supported IDEs > Let’s get started! What’s an LLM? Large language models are a type of AI that are trained on a large (hence the name) amount of text data to understand and generate human-like language. By predicting the next word in a sentence based on the context of the words that came before it, LLMs respond to humans in a way that is relevant and coherent. Sort of like an ultra-smart autocomplete! When it comes to using LLMs, there are three important things to understand: Context: This is the surrounding information that helps an LLM understand what you’re talking about. Just like when you have a conversation with a friend, the more context you offer, the more likely the conversation will make sense. Tokens: For LLMs, text is broken down into units of tokens. This could be a word, part of a word, or even just one single letter. AI models process tokens to generate responses, so the number of tokens you use with an LLM can impact its response. Too few tokens can lead to a lack of context, but too many could overwhelm the AI model or run into its built-in token limits. Limitations: LLMs are powerful, but not all-powerful. Instead of understanding language like humans, LLMs rely on patterns and probabilities from training data. Taking a deeper dive into training data is beyond the scope of this post, but as a general rule, the ideal data set is diverse and broad. Models are never perfect—sometimes they can hallucinate, provide incorrect answers, or give nonsensical responses. What is a prompt? A prompt is a natural language request that asks an LLM to perform a specific task or action. A prompt gives the model context via tokens, and works around the model’s potential limitations, so that the model can give you a response. For example, if you prompt an LLM with “Write a JavaScript function to calculate the factorial of a number,” it will use its training data to give you a function that accomplishes that task. Depending on how a specific model was trained, it might process your prompt differently, and present different code. Even the same model can produce different outputs. These models are nondeterministic, which means you can prompt it the same way three times and get three different results. This is why you may receive different outputs from various models out in the world, like OpenAI’s GPT, Anthropic’s Claude, and Google’s Gemini. Now that we know what a prompt is, how do we use prompts to get the outputs we want? What is prompt engineering? Imagine that a friend is helping you complete a task. It’s important to give them clear and concise instructions if there’s a specific way the task needs to be done. The same is true for LLMs: a well-crafted prompt can help the model understand and deliver exactly what you’re looking for. The act of crafting these prompts is prompt engineering. That’s why crafting the right prompt is so important: when this is done well, prompt engineering can drastically improve the quality and relevance of the outputs you get from an LLM. Here are a few key components of effective prompting: An effective prompt is clear and precise, because ambiguity can confuse the model. It’s also important to provide enough context, but not too much detail, since this can overwhelm the LLM. If you don’t get the answer you’re expecting, don’t forget to iterate and refine your prompts! Learn all about prompt engineering for Copilot Chat Discover simple strategies in our documentation to write better prompts and improve your Copilot results. How to engineer better Copilot Chat prompts > Let’s try it out! Example: How to refine prompts to be more effective Imagine you’re using GitHub Copilot and say: Write a function that will square numbers in a list in a new file with no prior code to offer Copilot context. At first, this seems like a straightforward and effective prompt. But there are a lot of factors that aren’t clear: What language should the function be written in? Do you want to include negative numbers? Will the input ever have non-numbers? Should it affect the given list or return a new list? How could we refine this prompt to be more effective? Let’s change it to: Write a Python function that takes a list of integers and returns a new list where each number is squared, excluding any negative numbers. This new prompt is clear and specific about what language we want to use, what the function should do, what constraints there are, and the expected input type. When we give GitHub Copilot more context, the output will be better aligned with what we want from it! Just like coding, prompt engineering is about effective communication. By crafting your prompts thoughtfully, you can more effectively use tools like GitHub Copilot to make your workflows smoother and more efficient. That being said, working with LLMs means there will still

If you know where to look, exposed secrets are easy to find. Secrets are supposed to prevent unauthorized access, but in the wrong hands, they can be—and typically are—exploited in seconds. To give you an idea of the scope of the problem, more than 39 million secrets were leaked across GitHub in 2024 alone.1 Every minute GitHub blocks several secrets with push protection.2 Still, secret leaks remain one of the most common—and preventable—causes of security incidents. As we develop code faster than ever previously imaginable, we’re leaking secrets faster than ever, too. That’s why, at GitHub, we’re working to prevent breaches caused by leaked tokens, credentials, and other secrets–making protection against secret exposures accurate, built-in, and accessible to every developer. Today, we’re launching the next evolution of GitHub Advanced Security, aligning with our ongoing mission to keep your secrets…secret. Secret Protection and Code Security, now available as standalone products Advanced Security for GitHub Team organizations A free, organization-wide secret scan to help teams identify and reduce exposure.3 Here’s how secrets leak, what we’re doing to stop it, and what you can do to protect your code. Let’s jump in. How do secret leaks happen? Most software today depends on secrets—credentials, API keys, tokens—that developers handle dozens of times a day. These secrets are often accidentally exposed, which makes sense. Less intuitively, a large number of breaches come from well-meaning developers who purposely expose a secret. Developers also often underestimate the risk of private exposures, committing, sharing, or storing these secrets in ways that feel convenient in the moment, but which introduce risk over time. Unfortunately, these seemingly innocuous secret exposures are small threads to pull for an attacker looking to unravel a whole system. Bad actors are extremely skilled at using a foothold provided by “low risk” secrets for lateral movement to higher-value assets. Even without the risk of insider threats, persisting any secret in git history (or elsewhere) makes us vulnerable to future mistakes. Research shows that accidental mistakes (like inadvertently making a repository public) were higher in 2024 than ever before. If you’re interested in learning more about secret leaks and how to protect yourself, check out this great video from my colleague Chris Reddington: What is GitHub doing about it? We care deeply about protecting the developer community from the risk of exposed secrets. A few years ago, we formally launched our industry partnership program, which has now grown to hundreds of token issuers like AWS, Google Cloud Platform, Meta, and OpenAI—all fully committed to protecting the developer community from leaked secrets. 💡 Did you know? GitHub partners with providers to build detectors for their secrets behind-the-scenes. This improves our ability to detect secrets accurately and quickly, and to work together to mitigate risk in the case of a publicly leaked secret. In the case of a public leak, GitHub not only notifies you with a secret scanning alert, but also immediately notifies the secret issuer (if they participate in the GitHub secret scanning partnership program). The issuer can then take action depending on their policy, like quarantining, revoking, or further notifying involved parties. Last year, we rolled out push protection by default for public repositories, which has since blocked millions of secrets for the open source community. And finally, as of today, we’re rolling out additional changes to our feature availability, aligning with our ongoing goal to help organizations of all sizes protect themselves from the risk of exposed secrets: a new point-in-time scan, free for organizations; a new pricing plan, to make our paid security tooling more affordable; and the release of Secret Protection and Code Security to GitHub Team plans. What you can do to protect yourself from exposed secrets The easiest way to protect yourself from leaked secrets is not to have any in the first place. Push protection, our built-in solution, is the simplest way to block secrets from accidental exposure. It leverages the same detectors that we created through our partnership program with cloud providers, ensuring secrets are caught quickly and accurately with the lowest rate of false positives possible. Get started Push protection prevents secret leaks–without compromising the developer experience–by scanning for secrets before they are pushed. You can enable push protection immediately with a couple clicks from your repository, organization, and enterprise settings. Studies have shown that GitHub Secret Protection is the only secret scanning tool—proprietary or open source—that can claim an over one in two true positive rate across all findings4. GitHub received a precision score of 75% (compared to the next best, 46% precision). Compared to alternatives like open source scanning solutions, it’s not that GitHub is finding fewer secrets, it’s that we’re finding real ones, so that you can spend your time worrying less about false positives, and more about what matters–shipping. 💡 Did you know? GitHub leverages GitHub Copilot in order to also detect unstructured secrets like passwords with extremely low false positive rates. My colleagues Ashwin Mohan and Courtney Claessens just wrote a great piece, which goes into depth on how we built Copilot secret scanning. Long-lived credentials are some of the most common and dangerous types of secrets to leak, as they often persist unnoticed for months–or years–and give bad actors extended access. That’s why managing secrets through their full lifecycle is critical. Beyond push protection, you can protect yourself from leaks by following security best practices to ensure secrets are securely managed from creation to revocation: Creation: follow the principle of least privilege and make sure secrets are securely generated. Rotation: outside of user credentials, secrets should be regularly rotated. Revocation: restrict access when no longer needed–or when compromised. Throughout the lifecycle of a secret, you should eliminate human interaction and automate secret management whenever possible. In addition, you should adopt a continuous monitoring solution for detecting exposures, so you can react quickly. Like push protection, GitHub’s built-in solution for secret scanning is the simplest way to triage previously leaked secrets. Starting today, investing in GitHub’s built-in security tooling is more

Learn how traditional, generative and agentic AI shape enterprise strategies, so you can deploy AI effectively.   ​  ​Learn how traditional, generative and agentic AI shape enterprise strategies, so you can deploy AI effectively. Artificial Intelligence Blog | Dell