Menu

Dimensional Data

GitHub Security

Announcing general availability of GitHub Advanced Security for Azure DevOps

GitHub Security

We live in a world fully consumed by software. According to the IDC, around 750 million applications will be shipped globally by 2025, meaning the feat of securing the world’s software is growing at an unprecedented rate at a time when digital trust has never been more important. At GitHub, we’re committed to empowering developers to not only create software, but ship secure products. GitHub Advanced Security (GHAS) was built to minimize context switching, reduce tooling, and allow you to rapidly find and fix vulnerabilities at the speed of innovation. Our application security testing solutions are natively embedded in the developer workflow and empowers DevSecOps teams to prioritize innovation and enhance developer productivity without sacrificing security. But what does this look like in practice? Code scanning, our native SAST solution, surfaces the right alerts at the right time. When a security alert is triggered, it’s shown incrementally in the pull request. This is different from more traditional SAST tools, which may provide a long list of alerts to sort through when a scan is complete, lacking specific context. With this approach, users engage with almost 80% engagement of alerts surfaced by code scanning, leading to a 50% real-time fix rate in. This is 3.8X more effective than third-party alerts, where the engagement rate is around 16% and the fix rate is around 13%. Today, with the general availability of GitHub Advanced Security for Azure DevOps, we are bringing GHAS’s native security features to the Azure DevOps workflow, meaning Azure DevOps users can benefit from the same advantages seen by GitHub Enterprise users. To get started today, any Azure DevOps Project Collection Administrator (PCA) can enable GitHub Advanced Security protections through the Azure DevOps configuration settings. Rapidly deploy and scale your security program With general availability, we’ve added new functionality to help you quickly enable GitHub Advanced Security to cover your organizations repositories. You can now choose to enable GHAS at the organization or project level, as well as on individual repositories. This should allow you to quickly deploy GHAS, when you want it, where you want it. When you enable GitHub Advanced Security for Azure DevOps, you’ll receive a prompt that will alert you that this is a billable event and give you an estimate of the number of committers. You can also now choose for Advanced Security to be automatically enabled for any future repositories you and your teams create. View all your alerts in a single pane of glass A key part of any successful application security program is a way to view all your alerts, across your organization, in a single pane of glass. This ensures you and your team have maximum visibility into your application security posture. We’ve taken this necessary feature, and built on it with our partnership with Microsoft Defender for Cloud (MDC). You can now not only view all Advanced Security alerts across your Azure repositories within MDC, but can also view alerts from GitHub as well. This functionality is available in the free tier of MDC, ensuring any team can take advantage of this powerful integration. Getting started with GitHub Advanced Security for Azure DevOps If you’re interested in getting started with GitHub Advanced Security for Azure DevOps, please see our documentation. Need more information? We will also be hosting a webinar […]

Read More

Passkeys are generally available

GitHub Security

Passkeys are a new form of sign-in and phishing resistant credential that make it easier to protect your GitHub account by reducing use of passwords and other, more easily phishable authentication methods. Since the launch of passkeys in beta in July, tens of thousands of developers have adopted them. Now, all users on GitHub.com can use passkeys to protect their account. This continues our commitment to securing all contributors with 2FA by the end of 2023 and strengthening security across the platform—without compromising user experience. Read on to learn about how to enable passkeys on your GitHub account. And, for those of you also building authentication experiences, we share what we’ve learned about how to roll out and make passkeys easy to use to help you integrate this powerful new credential method more quickly in your service. Get started with passkeys To register one or more passkeys on your account, head to your account security settings and click “Add a passkey.” If you already have security keys set up, you might see an “Upgrade” option next to those, if they are usable as passkeys. For more details about upgrading security keys to passkeys, read the passkeys docs. What we’ve learned building support for passkeys Passkeys are a relatively new credential type, and we’ve learned a lot about how to make them easy to use for large communities. Here we’ll share some of what we learned, and how we responded to that feedback—to help other authentication teams looking to adopt passkeys into their product. Not every platform is passkey ready, but they can still be supported We found that Linux and Firefox users struggled to use passkeys, as those platforms don’t yet have strong support for passkeys. As a result, we decided to enable cross-device registration of passkeys. That means, you can register a passkey on your phone while you’re using your desktop. The passkey lives in the phone, but users can connect it to their desktop and set-up and authenticate through the desktop’s browser. This enables Linux and Firefox users to set up passkeys. At a technical level, this meant ignoring the results of the IsUserVerifyingPlatformAuthenticator API (IsUVPAA) call, and instead just relying on the presence of the webAuthN APIs. This meant that both hardware keys (which don’t cause the IsUVPAA check to return true) and cross-device usage could still be accessed even when the underlying combination of OS and browser didn’t result in IsUVPAA returning true. Make it easy to upgrade compatible security keys There are a lot of security keys already registered on GitHub.com, many of them hardware keys. We had predicted that most hardware key owners wouldn’t want to upgrade to a passkey, due to threat models and lack of sync support. But a lot of users opted to upgrade a compatible security key to a passkey. So, we invested in making it easier to do so. In the account security settings, a new “upgrade” arrow next to compatible security keys enables immediate upgrade. Note that not every compatible security key will have this button next to it, as we only started checking for compatibility in late February this year. We also learned that some browser, OS, and security key combinations don’t support the re-registration flow that we use for upgrades, and will error if GitHub attempts […]

Read More

The GitHub Security Lab’s journey to disclosing 500 CVEs in open source projects

GitHub Security

When I stepped onto the scale this morning, I remembered that there are some numbers that feel awkward to celebrate, while perhaps some others are worth celebrating! Recently, the GitHub Security Lab passed the milestone of 500 CVEs disclosed to open source projects. What’s a CVE? In short, it’s the record of a security vulnerability, under the CVE program, intended to inform impacted users. So, finding more vulnerabilities in open source shouldn’t be good news, right? Even as developer communities are getting better at keeping themselves secure, security issues may still slip through their defenses. This means that there will always be a need for security researchers, like the Security Lab, to discover and help fix them. If you’re not familiar with the Security Lab, we’re a team of security experts who work with the broader open source community to help fix security issues in their projects, with the goal of improving the overall security posture of open source. Our core activity is to audit open source projects, not only the ones hosted on GitHub–and help their maintainers fix the vulnerabilities we find, for free. This research is foundational for our other activities, such as education, improvement of our open source static analysis rules, and tooling. And now we are celebrating more than 500 CVEs disclosed. ???? How did we get here? The history of the Security Lab dates back to Semmle, the company that created CodeQL, and which was later acquired by GitHub. 2017 was a pivotal year, as we realized how powerful our product could be for finding security vulnerabilities. Unlike many other static analysis tools, CodeQL efficiently codifies insecure patterns and responds urgently to new security threats at scale. To showcase this capability, Semmle created a small security research team who used CodeQL to search for vulnerabilities in open source projects, and a web portal named LGTM.com where all open source projects could run CodeQL for free and be alerted of potential security flaws directly within their pull requests. This approach grew into an important company objective: find and fix vulnerabilities at scale in open source. This was a way of giving back to the open source community, just like any software company should. In September 2019, GitHub acquired Semmle, providing an ideal home for advancing the goal of improving open source security at scale. This led to the creation of the Security Lab, with a larger team and new initiatives, including curating the GitHub Advisory Database. The GitHub Advisory Database provides developers with the most accurate information about known security issues in their open source dependencies. GitHub also incorporated CodeQL as a foundation of code scanning and a core pillar of GitHub Advanced Security (GHAS), keeping it free for open source. Code scanning reached parity with LGTM.com in 2022. We have also expanded beyond CodeQL and now use a variety of tools in our audit activities, such as fuzzing. But CodeQL remains one of the most effective tools in our toolbox, because it enables us to conduct variant analysis at scale, and allows us to share our knowledge of insecure patterns with the community, in the form of executable CodeQL queries. The secret? Our maintainers-first approach Not all reports get a CVE. CVE records are useful for informing downstream consumers, so when there is no downstream […]

Read More

Abonează-te la noutăți

Primiți noutăți și oferte despre SDLC tools

Close Menu