devopsy.kinsta.cloud

Tag: Secrets

  • GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian this week revealed it has allied with CyberArk to streamline secrets detection and management by making it easier to share insights.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the two companies have integrated their respective platforms using open source software that integrates GitGuardian Secrets Detection and CyberArk Conjur Cloud, a software-as-a-service (SaaS) platform for managing and rotating secrets as needed.

    In addition, CyberArk Conjur Cloud is now integrated with HasMySecretLeaked, a tool for discovering if a specific secret has been exposed on GitHub. That capability enables DevSecOps teams to periodically cross-reference secrets and credentials against a private database of secrets known to have been publicly exposed.

    GitGuardian claims to have uncovered more than 20 million publicly exposed secrets on the GitHub repository. While GitGuardian provides tools to discover exposed secrets, organizations rely on the CyberArk platform to manage secrets and remediate issues that arise when they are left exposed.

    The immediate challenge is to find ways to integrate secrets detection within the context of larger ecosystems, said Ghalleb. In the longer term, GitGuardian is working toward embedding its tool into integrated development environments (IDEs) to surface exposed secrets as developers build software, said Ghalleb.

    Naturally, there is a lot more focus on secret detection, and secrets management is getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. For many organizations, however, it’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is shifting left toward developers and the DevOps teams that support them.

    Unfortunately, too many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Many forget to remove those secrets before an application is deployed in a production environment. 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 the meantime, cybercriminals are becoming more adept at using scanning tools to discover secrets and then exploiting them to compromise applications after they have been deployed.

    Hopefully, DevOps teams will implement DevSecOps best practices to address those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.

    It’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are drafting legislation that would hold organizations much more accountable for the security of the applications they build and deploy. As more fines are eventually levied, the tolerance for leaving secrets exposed in applications is only going to decline.

    Secrets discovery and management is, of course, only one aspect of application security, but the more these issues are addressed before applications are deployed the less stressful cybersecurity becomes.

  • Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar has added a secrets detection capability to its portfolio of tools for analyzing code and DevOps workflows.

    Designed to be applied to both finding secrets in code repositories and as applications are developed using an integrated development environment (IDE), this capability is being added to SonarLint, SonarQube and the managed SonarCloud service to identify, for example, passwords, application programming interface (API) keys, encryption keys, tokens, database credentials and other private information.

    Sonar co-CEO Olivier Gaudin said the goal is to eliminate secrets that are accidentally or maliciously stored in source code to improve software supply chain security.

    While it’s important to discover secrets in codebases, Sonar is making a concerted effort to make it simpler for developers to discover secrets before they find their way into a codebase that is one step away from a production environment, noted Gaudin. The SonarLint static analysis tool the company provides can now discover secrets in microseconds using the syntactic and semantic analysis engines the company has now extended, he added. No developer is going to wait five to 10 minutes for a code scan to be completed, said Gaudin.

    A Learn as You Code tool also explains how each secret found in a code segment poses a security risk. The overall goal is not only to remove secrets but, ultimately, reduce the number of instances where secrets are discovered in code, said Gaudin.

    Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text that can be used to compromise application security, the need to encrypt secrets becomes a higher priority.

    There is, of course, no shortage of tools for detecting secrets. Sonar is now simply making a case for managing secret detection as part of a larger effort to reduce vulnerabilities in code that cybercriminals can exploit. That approach should help reduce the total cost of securing a software supply chain at a time when forthcoming regulations are going to make organizations that deploy software more accountable for application security.

    In the meantime, thanks to the rise of generative artificial intelligence (AI), the volume of code that needs to be scanned will likely exponentially increase. The issue with general-purpose AI platforms such as ChatGPT is they were trained using code of varying quality that often contains vulnerabilities that are now sometimes incorporated into the code they generate. On the plus side, however, many developers have little to no application security expertise, so it’s just as feasible that ChatGPT will create more secure code than a human developer. Regardless of how the code was created, however, no one will know for sure how secure it is without scanning it first.

    Hopefully, as AI progresses, the quality of the code being generated will only continue to improve. Until then, DevOps teams should continue to assume all code is suspect until proven otherwise.

  • HashiCorp Acquires BluBracket to Extend Secrets Management Reach

    HashiCorp Acquires BluBracket to Extend Secrets Management Reach

    HashiCorp this week revealed it has acquired BluBracket to add a set of scanning tools for discovering static secrets to its portfolio.

    James Bayer, senior vice president of research and development for the Secure product line at HashiCorp, said the existing Vault platform for managing secrets is designed to enable developers to manage them as they build applications. BluBracket has developed a secrets management tool that makes it possible to discover secrets in applications that have already been deployed in production environments, he said.

    The amount of secrets management-related technical debt many organizations have can be enormous, especially if they’ve been deploying applications for decades. IT teams need a tool that discovers secrets in applications that, in many cases, were deployed by application developers that are no longer with the company, Bayer added.

    The BluBracket tools make it possible to discover those unmanaged secrets even before efforts are put in place to improve application security, he noted.

    HashiCorp will initially integrate BluBracket’s functionality into HashiCorp Vault to expand HashiCorp’s zero-trust capabilities, and add detection and remediation workflows via additional capabilities expected later this year. That’s critical, because for decades, developers have been storing secrets in applications and forgetting to remove them before an application is deployed.

    In general, HashiCorp is moving to transform its Vault platform into an orchestration engine for managing secrets regardless of where those secrets might be stored, said Bayer. That approach will enable developers to build applications and store their secrets on, for example, the Amazon Web Services (AWS) cloud in a way that can be centrally managed via the Vault platform, he added.

    Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text, the need to encrypt secrets becomes a higher priority.

    The core DevSecOps issue most organizations are wrestling with is how involved cybersecurity teams should be in application development. There’s clearly a concerted effort to push more responsibility for application security further left toward developers. The challenge is, even when those tools are provided, it’s not clear that developers can distinguish between the severity of one vulnerability versus another.

    Conversely, most cybersecurity teams don’t really understand how modern applications are developed. That doesn’t necessary mean cybersecurity professionals need to dive deep into application development workflows, but it does mean they should, at the very least, understand how applications are constructed to make sure the appropriate security guardrails have been put in place.

    Regardless of approach, it’s clear there is a need for some type of centralized security function to better ensure application security. Unfortunately, the cultural divide between application developers and cybersecurity teams remains fairly wide. The DevSecOps journey ahead will be long, as each organization determines how best to bridge that gap when the supply of available cybersecurity expertise remains constrained.

  • GitGuardian Survey Surfaces Secrets Management Challenges

    GitGuardian Survey Surfaces Secrets Management Challenges

    A survey of 507 IT decision-makers in the U.S. and the United Kingdom published today found 75% of respondents said a secret leaked from at least one application, with 60% noting that the leak caused issues for either the company, employees or both.

    Conducted by Sapio Research on behalf of GitGuardian, a provider of a platform for securing application secrets, the survey found less than half of respondents (48%) are confident in their ability to protect application secrets to a great extent.

    The top source of risks when it comes to secrets management are source code and repositories (58%), followed by hard-coded secrets (47%). Just under a third (30%) of respondents to the GitGuardian survey admitted they share passwords and secrets when building applications as clear text within a messaging application.

    Just over a quarter (27%) still relied on manual code reviews to prevent secrets leaks, the GitGuardian survey found.

    On the plus side, 94% of the respondents said they were considering improving their secrets management practices in the coming 12-18 months, even though 93% said either “all” or “some” of their repositories were continuously scanned for hard-coded secrets.

    Thomas Segura, a cybersecurity expert for GitGuardian, said as the number of applications developed continues to increase, secrets sprawl has become a bigger challenge for application security. The way secrets are managed during application development has become a bigger issue in the wake of a series of software supply chain breaches that led to malware being injected into applications.

    The concern is cybercriminals that compromise software development environments will be able to retrieve secrets that they can later use to compromise an application after it has been deployed in a production environment. Cybercriminals are also now routinely scanning for secrets that may have been stored in text after an application has been deployed.

    The challenge is that secrets have not been historically managed effectively, so many organizations are now looking to implement more rigorous processes. Another challenge is that, in many cases, it’s not apparent whether those processes will be implemented by a DevOps team familiar with how an application is constructed or an application security team with more cybersecurity expertise, noted Segura.

    Regardless of the approach to remediating these issues, there is always going to be an issue because the humans who build applications are always going to make mistakes. The goal is to minimize the number of secrets that might be leaked by implementing DevSecOps practices that automate the review process, said Segura.

    In theory, at least, advances in artificial intelligence (AI) should make it easier to automate more of the secrets review process. In the meantime, however, organizations need to review their existing processes in advance of pending legislation that looks to hold organizations more accountable for application security if it is determined that the organization did not take reasonable precautions.

    It may be a while before such legislation becomes law, but one way or another, it’s clear that DevOps teams are soon going to be asked tougher questions about how secrets were managed every time an application security breach occurs.

  • 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.

  • 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.

  • The Scanner We Really Need

    The Scanner We Really Need

    IT has scanners for everything. And by everything, I mean everything. We scan source code for vulnerabilities and data leaks. We scan apps for vulnerabilities. We scan the network for holes. We scan our cards for access … Okay, that last one doesn’t fit, but you get the idea.

    Know what we don’t scan for (and what I propose we start scanning for immediately)? Secrets. Oh, there are apps that include finding secrets as part of their feature set—but only a part—and they only scan for secrets within their domain. What we really need is something all-encompassing. Secrets have a way of turning up everywhere—Git, flat files, databases, source code, email … If it can store text, your secrets are probably in there. The larger the organization, the more true this is.

    Way back in the day, I started working at a company that had mainframe admin credentials stored in a flat file on the network. I am not an InfoSec employee, but I can smell insecurity easily enough and I told them to knock it off.

    I am not mentioning the company by name because this is not indicative of their practices today, nor am I mentioning my position or the market, because anyone interested could then use my LinkedIn profile to figure out who it was.

    In my role there, I had the authority to tell them to knock it off, but they handed me a ready response: “Our network is secure, so we don’t have to worry about it. And we monitor the file … some …”

    The same type of mentality seems to permeate IT today. Security by obscurity is alive and well with regard to secrets, and yet we as an industry know (from hard-earned experience) that it is largely a myth.

    So, we need a tool that can access all the places that secrets might be hiding and ferret them out—I’m thinking like a simple UI that takes a secret and searches for it in all of the configured places—would be perfect. Well, almost perfect. Iteration 2.0 would report on what is accessing the secret in that location.

    Get secrets management. Several markets offer secrets management as part of a toolset, you might even own a product that can do it for you. Then, given the search tool and a good secrets management solution, you could search out all instances and replace access to them. Until iteration 2.0 comes out, you could replace them in a test environment and see what breaks—though we also have the hard-earned experience to know that this isn’t foolproof, so you’ll want to heavily document the change for that odd thing that breaks 20 months from now.

    This is not that difficult a product to design and build; finding where each secret is accessed from would be the hardest part. But that’s still doable with our current dev tools. One of you should build it and get rich.

    But meanwhile, as always, keep rocking it. Secrets stored in not-so-secret locations or not, you’re keeping the company running day in and day out. That makes you the stars of business. Keep up the good work.

  • Managing Hardcoded Secrets to Shrink Your Attack Surface 

    Managing Hardcoded Secrets to Shrink Your Attack Surface 

    The practice of hardcoding secrets—such as authentication credentials, passwords, API tokens and SSH Keys—as non-encrypted plain text into source code or scripts has been common in software development for many years. It is an easy way to save time and labor, but it is also highly insecure. The issue is that anyone with access to the code also has access to these hardcoded (or embedded) credentials, meaning your code is supremely vulnerable to attack.  

    Of course, today’s DevOps-oriented software development life cycles are all about velocity and efficiency—the goal is to advance and launch products not in weeks or months, but in days or even hours. Anything that might slow that pipeline is to be avoided, which is why hardcoded secrets are not going anywhere. They are going to be with us for many years to come.  

    At the same time, cybersecurity experts are right to be alarmed about the growing problem of secrets sprawl, which occurs when an organization stores secrets in a variety of locations, including source code, text files and spreadsheets. In today’s multi-cloud DevOps environments, it is simple arithmetic: As the number of users grows, your attack surface grows, too, in many cases expanding exponentially. 

    The Right Tools to Manage Secrets

    According to Gartner, “Hard-coded secrets embedded in source code and scattered throughout the DevOps pipeline pose significant risk. Technical professionals responsible for DevSecOps must introduce tools that securely store and manage secrets and enforce access controls without disrupting automated DevOps workflows.”

    What has come to the fore as many organizations have adopted cloud infrastructure, containerization and microservices architecture—especially regarding the software development life cycle (SDLC)—is that conventional technologies for secrets governance and entitlements management are not at all adequate in the cloud. Vault technology for static secrets is a well-understood set of capabilities that has been a cornerstone of cybersecurity best practices for many years. SecOps and DevOps teams realize that they need to adapt vaulting to cloud environments, but progress toward effective cloud secrets governance has been held back by several challenges.

    Just-In-Time For the Cloud 

    First, as noted above, disrupting continuous integration/continuous delivery (CI/CD) processes is not seen as an acceptable practice. DevSecOps teams very much expect to deploy secrets management capabilities without slowing or otherwise impeding the development process and without having to expend additional resources. Yet many standalone vaulting services are cost-prohibitive for most SMBs. Further, in many cases, conventional approaches to secrets management cannot deliver full governance capabilities, including clear visibility and attestation, across multiple vaults or within cross-cloud environments.  

    The good news is that today’s advanced dynamic permissioning platforms incorporate just-in-time (JIT) secrets provisioning capabilities and zero standing privilege (ZSP) enforcement mechanisms and can overcome these obstacles. The automated granting and revocation or expiring of permissions—JIT privilege grants—is highly effective at minimizing attack surfaces. These solutions—increasingly grouped under the banner of cloud infrastructure entitlement management (CIEM)—work based on the concept of zero-trust, which means no one and nothing is trusted with standing access to your cloud accounts and data.  

    With JIT, elevated privileges can extend either for the duration of a session or task, for a set amount of time or when the user checks the profile back in manually. Once the task is complete, those elevated privileges are automatically revoked—all without sysadmin involvement. Where a user previously had standing access privileges potentially extending around the clock for months or years at a time, converting to JIT granting compresses that attack surface to several hours per month.  

    Even better, as cloud-native entities, these solutions can support highly effective secrets governance initiatives for SMBs and enterprises alike. CIOs, engineering managers, CISOs and other IT security officers looking to better protect their multi-cloud DevOps environments should be looking to adopt an automated secrets governance platform that enables them to deliver on these four priorities: Visibility, enforcement, automation and investigation. 

    Visibility 

    Cross-vault visibility into all your secrets, secrets owners and secrets users is a must-have. You need to be aware, at any given time, of every human and machine user that has access to a secret, and you need to be able to uncover and monitor your highest-risk secrets or accounts across vaults.  

    Enforcement 

    You need to be able to enforce your secrets policies across vaults, which necessarily includes the ability to automatically rotate your static secrets across all vaults based on organizational policy. JIT permissioning is key here because it enables users to generate temporary credentials on the fly, and necessarily incorporates the automated granting and expiring or revocation of permissions—JIT privilege grants—which is highly effective at minimizing attack surfaces. 

    Automation 

    You need to be able to manage the identity life cycle for your secrets—preferably through an automated joiner/mover/leaver process. Consider, for example, if several people have access to a shared secret. Sharing accounts is not a best practice from a security standpoint, but it is common (and becoming more so) with the growing use of cloud resources within DevOps organizations. If one of those individuals in the shared secrets group leaves the organization, that permission/privilege then becomes a potential vulnerability. Automated shared secrets rotation that is invoked by policy directly addresses this issue. 

    Investigation 

    Security incidents are an inevitable eventuality in any organization. When an incident occurs—data breach, lost device, ransomware attack—you need to be able to tie secrets back to identities for proactive monitoring and post-incident investigation. Understanding which identities or individuals were exploited—and how—is essential for addressing vulnerabilities or bad practices. Analysis and reporting are also a critical capability for looking into access changes, addressing policy drift and identifying risky behaviors. 

    There’s no question that secrets governance in cloud environments requires rethinking and retooling established vault technologies and best practices for securing static secrets. JIT permissioning and secrets grants based on ZSP precepts provides an effective path forward. Consider that with JIT and ZSP, elevated privileges are circumscribed, and time-limited to minimize the permissioning and privilege threat surface. Taken together, these capabilities can deliver highly effective secrets governance to secure your entire organizations, without slowing or otherwise impacting your DevOps teams.