devopsy.kinsta.cloud

Tag: github

  • GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian published an analysis of more than one billion commits to GitHub repositories that found 10 million occurrences of secrets, with one out of 10 developers exposing a secret.

    Mackenzie Jackson, a developer advocate for GitGuardian, said more than 80% of all the secrets caught by live monitoring GitHub were exposed through personal repositories, with a large share of them being corporate secrets. In fact, three million of the secrets discovered were unique instances, with 5.5 commits out of every 1,000 made exposing a secret.

    On a year-over-year basis, the report also found that the number of hard-coded secrets discovered in these repositories increased 67%. More than half the secrets discovered (56%) contained a generic password.

    There appeared to be no correlation between developer experience and the number of secrets exposed. Junior and senior developers are equally predisposed to making the same mistakes, said Jackson. The most common mistake is secrets left exposed because developers used them to simplify access to components and resources when building their applications and then forgot to remove them when the application was deployed in a production environment.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. The issue with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have issues with how secrets are managed could be staggering.

    In theory, at least, the adoption of DevSecOps best practices should be mitigating this issue, but as the volume of code stored in repositories continues to increase, it would appear more fundamental mistakes are being made. Cybercriminals, meanwhile, have a greater appreciation today for weaknesses in software supply chains, so many of them are scanning repositories for secrets that will enable them to breach an application.

    Of course, there’s a lot more attention being paid to secure software supply chains, especially in the wake of the Biden administration creating a National Cybersecurity Strategy that requires Federal agencies to, among other things, lock down software development life cycles on an end-to-end basis. Most enterprise IT organizations, if they have not done so already, are expected to follow suit.

    As a result, DevOps teams should expect to see more cybersecurity professionals focusing more on secrets management. Developers, naturally, will not want to be called out for mismanaging secrets, so over time, the overall state of application security should steadily improve. The issue, of course, is the volume of attacks against software supply chains is expected to increase. Many previous mistakes are likely to come back and haunt developers and the organizations that rely on their code and wreak havoc downstream.

  • OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

    OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: ChatGPT darling OpenAI wants people to write code in English, and the unintended consequences of blocking shared accounts. (more…)

  • Best of 2022: We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources 3D Emoji

    Best of 2022: We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources 3D Emoji

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: JavaScript is a bloated barrier to progress, and Microsoft’s emoji are on GitHub. (more…)

  • GitHub Previews Free CI/CD Migration Tool Due in 2023

    GitHub Previews Free CI/CD Migration Tool Due in 2023

    At its GitHub Universe event, GitHub today unveiled a bevy of updates to its cloud service, including a forthcoming set of migration tools. The tools will automate migrations from legacy continuous integration/continuous delivery (CI/CD) platform to GitHub Actions.

    GitHub Actions Importer is already being used by a small group of enterprise IT organizations to migrate workflows and template the GitHub CI/CD platform.

    Damian Brady, senior manager for developer advocacy at GitHub, told conference attendees that these free tools will become more broadly available in 2023. GitHub Actions Importer will be distributed as a Docker container that manifests itself as an extension of the GitHub command line interface (CLI).

    One of the biggest challenges the company has faced in driving adoption of its platforms is that many DevOps teams don’t want to rebuild the templates and workflows they are already using on their existing CI/CD platform, he noted.

    Other GitHub Actions extensions include native integration with software development tools for building internet-of-things (IoT) applications and support for personal access tokens (PATs) that enable more granular control over permissions and repository access.

    Other security capabilities include expanded access to audit log events in the enterprise edition of GitHub, an ability for maintainers of open source repositories to privately share vulnerability reports and support for Ruby as one of the programming languages now supported by a CodeQL tool for discovering vulnerabilities.

    Additional extensions to existing services for developers also were previewed, including an ability to interact with the GitHub Copilot tool for automating code writing using voice commands. Dubbed “Hey, GitHub!” the tool is available as an experiment being advanced by the GitHub Next research team.

    Finally, the company previewed enhancements to code search-and-view capabilities in the Codespaces tool that will now be made available for free for up to 60 hours per month to developers.

    GitHub claims its CI/CD platform is now being used to process 10 million builds a day, most of which are employing code accessed via its repository. It’s not clear how that compares to other CI/CD platforms, but it’s apparent the GitHub Actions CI/CD platform has gained a significant amount of traction as GitHub continues to make a case for creating tighter integrations between its repository and CI/CD platform. GitHub is also clearly signaling it will spend a lot more time wooing organizations that already have a legacy CI/CD platform installed.

    In the meantime, the next era of DevOps has arrived as workloads become both more complex to build and deploy across highly distributed computing environments. Many of the CI/CD platforms that organizations deployed are now straining under the weight of multiple customizations and extensions that have been made over the years. Each DevOps teams will need to decide whether maintaining those platforms makes the most technical and economic sense or if they should migrate to a more modern platform.

    Regardless of what they decide, one thing that is certain is that DevOps teams won’t be getting larger, so the need to invest in higher levels of automation has become pressing.

  • What GitHub’s 2FA Mandate Means for Devs Everywhere

    What GitHub’s 2FA Mandate Means for Devs Everywhere

    Multifactor authentication (MFA) is becoming increasingly standard within software development organizations, with GitHub recently announcing that two-factor authentication (2FA) will be mandatory for all code contributors by the end of 2023.

    This is a smart move. In recent years, bad actors have frequently initiated attacks by accessing source code through the use of stolen developer credentials. Once inside, they quickly penetrate organizations’ entire code repositories and elevate access to company-wide systems. This was the case with the 2021 SolarWinds compromise that ultimately jeopardized federal agencies, corporations and governmental institutions.

    But for some developers with lofty goals and concentrated timelines, MFA is an extra step that has the potential to slow them down. As organizations continue to implement MFA and other foundational security controls, they may face pushback—but they shouldn’t be deterred. MFA is a critical attack barrier that improves individual protections and can contribute to tightened source code security. 

    If organizations approach implementation thoughtfully, they can lay the foundation for subsequent security controls—and build credibility among their users and within the larger development community.

    The Risks of Lax Individual Developer Security

    Organizations’ source code typically powers a host of upstream programs and products, so it’s valuable for bad actors to launch attacks by infiltrating their repositories. Attackers can also hide malware in source code that can be escalated to breach entire systems and third-party organizations. This risk is heightened by the fact that many companies rely solely on antivirus scans and other surface-level monitoring tools to flag source code vulnerabilities instead of combining them with dynamic testing and penetration testing.

    Attackers typically gain access to source code through stolen developer credentials. While single authentication systems—i.e., usernames and passwords—are the easiest to compromise, MFA creates an additional barrier that’s more difficult for attackers to overcome. While this tool does create additional friction in the development process, it’s worth the extra step. Even for hobbyist or open source developers, compromised source code can cause larger repercussions that put other developers at risk. When it comes to cyberattacks, it’s best to assume any entity is a potential target. 

    Beyond individual security, MFA and other foundational controls are critical to safeguarding organizational reputations and adhering to legal privacy standards. By 2023, 65% of the global population will have personal data covered by privacy regulations. Security measures that protect authentication credentials will become even more important in the coming years, especially for organizations producing source code that powers consumer-facing products and programs. With an intentional approach to implementation, MFA can help mitigate potential source code attacks—and form the basis of comprehensive security programs.

    Four Steps to Successful MFA Implementation 

    The benefits of MFA far outweigh the cost of user friction and developer pushback. Get the most out of this authentication technology by following these four steps to implementation.  

    1. Start small and build credibility. Approach implementation gradually to help developers understand MFA’s value. Successful implementation will give your leadership and security teams credibility for future security initiatives, and it will improve processes for security integration into your larger software development life cycle.  
    2. Examine your security program’s value chain. Implementing foundational security controls like MFA provides an opportunity to examine your security program’s entire value chain. Take time to look for potential vulnerabilities beyond your source code repository and flag areas within your development lifecycle that may create risk.
    3. Layer subsequent security controls. With MFA under your belt, build up your security program with other tools and controls—like dynamic and penetration testing, source code scanning, software composition analysis (SCA) and vulnerability management. The more security tools you layer, the harder you make it for attackers to succeed. 
    4. Plan for continuous optimization. Attackers will devise more ways to thwart MFA as more organizations mandate it. For example, the popularity of using SMS as a second form of authentication declined when attackers developed methods to gain control of mobile phones. To keep up with evolving attacker behaviors, continuously optimize your MFA technology and subsequent security controls. 

    MFA Will Become the Industry Standard

    As bad actors evolve attack methods and privacy regulations strengthen, MFA will undoubtedly become an industry standard for protecting source code repositories. 

    To stay ahead of the curve, focus on the concept of MFA throughout your network by ensuring it protects every system entry point. This extra step is an easy price to pay for improved source code protection—and ultimately safeguards every asset, product and program your code powers. Thoughtfully implementing MFA can lay the foundation for comprehensive source code protection.

  • GitHub Brings 2FA to JavaScript Package Manager

    GitHub Brings 2FA to JavaScript Package Manager

    GitHub has made generally available a two-factor authentication tool for the package manager for JavaScript applications maintained by its NPM, Inc. arm.

    In addition, all npm packages have been re-signed and there is now an npm command line interface (CLI) command to audit package integrity.

    Finally, GitHub has added the ability to connect GitHub and Twitter accounts to npm along with a streamlined login and publishing experience with the npm CLI.

    Myles Borins, staff product manager for open source at GitHub, said these enhancements are part of an ongoing effort to enable organizations to better secure their software supply chain by better protecting credentials against being used to take over GitHub accounts.

    There isn’t a huge volume of these types of attacks, but it’s apparent cybercriminals are attempting to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, noted Borins. Once cybercriminals gain access, they could potentially insert malware in software components that could find its way into any number of downstream applications. That malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. More troubling still, that malware might begin to spread laterally across an entire application environment.

    GitHub is currently dealing with the fallout from a report that its repositories were attacked; that turned out to be a false alarm. The repositories attacked turned out to be either forks or clones of real, popular repositories with names similar to legitimate repositories on the GitHub platform. No malicious code was actually merged into any of the original repositories; however, it’s apparent cybercriminals are using a technique known as spoofing commit metadata to attempt to trick developers into committing code to a fake repository.

    The challenge that GitHub is trying to navigate is the degree to which some security controls should be enabled by default based on the level of risk, said Borins. Individual developers, for example, might have a higher tolerance for risk than an enterprise IT organization building an application that is core to the processes that drive the business, he noted. In some cases, organizations may opt to restrict access altogether whenever a user name/password can’t be remembered while others will simply limit access to ensure productivity is maintained, added Borins.

    In general, the average enterprise IT organization is likely to have a higher tolerance for disrupting workflows to make sure critical intellectual property is always protected, he added.

    The critical issue, of course, is no one knows for sure what open source component might one day wind up in what application. Regardless of the type of application, developers now routinely reuse code that could contain any number of known vulnerabilities or zero-day vulnerabilities that have yet to be discovered. The foundation for building secure DevSecOps workflows for most organizations at a bare minimum is going to start with implementing two-factor authentication, said Borins.

    Regardless of the DevSecOps approach, just about everyone recognizes there is a need to better secure software supply chains. The one thing that remains to be determined is what impact achieving that goal might actually have on the rate software is being built and delivered.

  • GitHub Adds Tools to Simplify Management of Software Development

    GitHub Adds Tools to Simplify Management of Software Development

    GitHub has made generally available Projects powered by GitHub Issues, a set of tools for managing application development projects based on a spreadsheet interface.

    Mario Rodriguez, vice president of product management at GitHub, said these tools enable DevOps teams to more easily filter, sort and group issues and pull requests. That capability makes it possible to, for example, configure and track cycle velocity and current work status and create visualizations using cumulative flow diagrams.

    Over the course of the rest of this year, Rodriguez said GitHub also plans to add additional capabilities including custom triggers, conditionals and action logic along with a mobile edition of Projects powered by GitHub Issues.

    The overall goal is to provide DevOps teams with a set of project management tools that enable organizations to plan where they code, said Rodriguez. In many cases, that approach eliminates the need to deploy a separate set of project management applications, he added.

    As more organizations become dependent on software to drive digital business processes, it’s become apparent that managing all the ongoing application development projects has become a significant challenge. GitHub has been developing Projects powered by GitHub Issues to provide organizations with a set of tools that can be accessed not just by DevOps teams but also by application owners and business leaders to track the status of various projects, said Rodriguez.

    Most organizations have not reached the point where revenue growth is completely dependent on the rate at which software is developed and deployed, he noted. However, as DevOps teams more regularly engage other departments in the business, Projects powered by GitHub Issues can provide anyone with access to a spreadsheet-like application that is simple to use, said Rodriguez.

    In general, GitHub is committed to improving developer experiences at a time when organizations are competing for the best talent available, added Rodriguez. If salary and benefits are equal, the decision to work for one company versus another comes down to the quality of the application development experience, he noted.

    As the provider of the most widely-used code repository, GitHub has been extending the reach and capabilities of its platform to address a range of DevOps workflow issues. The issue that DevOps teams need to address is how to anchor those workflows to a code repository versus the continuous integration/continuous delivery (CI/CD) platforms they employ to build and deploy applications.

    Regardless of approach, there’s no doubt that DevOps teams can now construct more scalable workflows. That’s critical, because the number of concurrent application development initiatives that organizations are managing simultaneously has increased substantially in recent years. The underlying platforms used to manage those projects need to be extensible to prevent workflows from becoming overly rigid, said Rodriguez.

    It’s not clear to what degree business leaders appreciate the value of DevOps workflows, but as business processes continue to evolve, the ability to effectively compete could rest on the agility of an application development team.

  • GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian has expanded its ability to secure code repositories by providing deeper integration with GitHub.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the results of security scans are now provided in the context of pull requests alongside suggestions for remediating issues.

    The company also expanded developer onboarding options by adding an application programming interface (API) key provisioning mechanism integrated with its command line interface (CLI) in addition to making it easier to configure that CLI.

    Finally, GitGuardian extended support for role-based access controls (RBAC) to its platform so that team members can be assigned different permissions levels for incidents based on their role.

    GitGuardian makes it possible to scan source code to detect API keys, passwords, certificates, encryption keys and other sensitive data in a code repository in real-time. Developers building an application often make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete these secrets. Cybercriminals know to scan for these secrets to make compromising an application environment easier.

    A recent GitGuardian report found a typical company with 400 developers would discover 1,050 unique hardcoded secrets when scanning its entire codebase. Each secret had 13 different occurrences, which meant the effort required to remediate those associated vulnerabilities would be considerable, the report noted.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. GitGuardian makes it simpler to achieve that goal within the context of a set of DevSecOps best practices by integrating with GitHub with a single click, said Ghalleb.

    It’s still early days as far as adoption of DevSecOps best practices is concerned, but it’s clear more responsibility for application security is being shifted left toward developers. The challenge is many developers still lack the tools required to make sure applications are secure before they are deployed in production environments.

    Naturally, the earlier an application security issue is resolved the less costly it is to fix. The problem with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers there is an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have secrets management issues could be staggering.

    One way or another, it’s only a matter of time before more of those issues are surfaced. In the meantime, DevOps teams can reduce the number of applications that might have this issue by making it easier to discover secrets within applications before they are deployed in production environments. After all, the only thing worse than a secret being discovered by a cybersecurity team is having one uncovered by cybercriminals that use it to wreak havoc.

  • Blast Radius of GitHub Breach Major Security Concern

    Blast Radius of GitHub Breach Major Security Concern

    The extent to which software supply chains may be compromised in the wake of a security breach disclosed by GitHub may include thousands of organizations.

    GitHub has revealed that unauthorized parties compromised OAuth user tokens maintained by Heroku, an arm of Salesforce that provides a platform-as-a-service (PaaS) environment, and Travis CI, a provider of a continuous integration/continuous delivery (CI/CD) platform. GitHub has since disconnected the third-party applications that were employing those tokens to access repositories but how much any code might have been exfiltrated or, worse yet, modified may not be known for weeks.

    “There’s a lot of directions this could take,” said Mitch Ashley, principal researcher for Techstrong Research, an arm of Techstrong Group, which owns devopsy.kinsta.cloud. “This is an attack against an authentication mechanism.”

    In fact, the full extent of the blast radius of the breach may never be known unless every organization employing Heroku or Travis CI platforms discloses whether their software supply chains were breached. GitHub has also yet to provide any timeline for the extent of the breach, so no one affected yet knows how far-reaching an investigation should be launched or how long it could take to discover malicious code that may have been injected into applications, noted Brian Soby, CTO at AppOmni, a provider of a platform that provides visibility into platform configurations.

    “We don’t know yet when this occurred,” he said. “This could have a big blast radius.”

    In the meantime, the GitHub disclosure will only intensify security reviews of software supply chains, which have begun in earnest in the wake of a series of high-profile breaches that started with an incident involving an IT service management platform provided by SolarWinds.

    In the case of the latest GitHub breach, security professionals are surmising that developers hard-coded tokens into applications accessing GitHub to make it easier to access repositories. “Developers are lazy,” said Demi Ben-Ari, CTO for Panorays, a provider of a platform for evaluating third-party security risks. “They like to take shortcuts.”

    Some organizations in the wake of the attack may move to distribute source code across repositories from multiple vendors as part of any effort to better secure their intellectual property, noted Ben-Ari.

    Organizations also may decide to rely on code repositories that are not accessed via the cloud. However, given the need to integrate disparate services across a software supply chain, there is no guarantee that an organization with a repository running in an on-premises IT environment wouldn’t be affected by a similar attack.

    On the plus side, as more organizations become aware of the threat vector employed to compromise the GitHub repositories, the level of awareness for implementing best DevSecOps practices should increase. The challenge, of course, remains bridging the technical and cultural divides that often result in developers not following best security practices when building and deploying applications. However, as the number of incidents continues to mount, more organizations are beginning to appreciate just how easy it is for the code they are relying on to engage customers and suppliers to be tampered with or outright stolen.

  • ForAllSecure Adds Free Testing Tools for OSS

    ForAllSecure Adds Free Testing Tools for OSS

    ForAllSecure is investing to make open source software (OSS) more secure and is making available free, personal-use versions of its Mayhem application security testing tools infused with artificial intelligence (AI) capabilities to anyone using GitHub repositories.

    Company CEO David Brumley said anyone who integrates Mayhem into a qualified GitHub repository being used to build open source software will receive $1,000 as part of the company’s Mayhem Heroes program.

    There are now two free, personal-use editions of Mayhem that can be used to analyze code or application programming interfaces (APIs). Those tools are based on fuzz testing technology, which randomly injects data into applications to detect vulnerabilities as part of an effort to automate DevSecOps processes.

    In the wake of the discovery of zero-day vulnerabilities in open source software that have impacted enterprise IT organizations, more attention is being paid to how open source software is created, maintained and secured. Many of the developers who build and maintain open source software don’t typically have a lot of cybersecurity expertise, and don’t have the time and resources required to continually remediate vulnerabilities as they are discovered. The Mayhem application security testing tools are designed to make it faster to discover vulnerabilities using AI technologies to reduce the number of false-positive alerts.

    It’s too early to say how quickly open source software might be made more secure, but tons of resources are being made available. The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software used inside (and outside) government agencies by expanding compliance mandates. The White House is also trying to encourage IT vendors and larger enterprises to contribute more to the effort to secure open source software.

    The pressure is rising on both developers and consumers of open source software to make sure open source software is secure. However, many open source projects are maintained by a small number of programmers who contribute their time and effort to build components that others are free to use. Many of them argue it is the responsibility of the organizations that deploy that software to ensure the software is secure  Many IT vendors and large enterprise IT organizations that rely on that code aren’t contributing anything meaningful back to the project, in terms of either financing or just helping open source maintainers find and remediate vulnerabilities. The irony is many of those same organizations are now assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions.