devopsy.kinsta.cloud

Tag: credentials

Widespread Mini Shai-Hulud Campaign Is a Matter of Trust

The latest series of attacks using the notorious Shai-Hulud worm puts into sharp focus the threats facing software developers and their CI/CD pipelines, an issue that has been raised in recent months as bad actors increasingly turn their attention to DevOps environments.

That said, these most recent Shai-Hulud incidents attributed to the TeamPCP group also reflect the trend toward abusing trust, a key point given the extensive connectivity between corporate ecosystems and development platforms.

“Shai-Hulud should be understood less as a one-off package compromise and more as an evolving supply-chain playbook,” said Jonathan Stross, SAP security analyst at Pathlock.

Earlier waves of Shai-Hulud attacks in 2025 and this year focused on stealing developer and maintainer credentials and using them to publish more malicious packages. In the latest incidents – referred to as “Mini Shai-Hulud” – the threat group abused trusted CI/CD publishing paths and OpenID Connect (OIDC) tokens, meaning that malicious package versions still carried valid provenance attestations.

“In other words, some of the signals defenders increasingly rely on to establish trust were present, even though the package content was malicious,” Stross said.

Chuck Randolph, senior vice president for strategic intelligence and security at 360 Privacy, said organizations, their development teams, and code repositories need to recognize and prepare for such campaigns, which build on the trend over the past several years to abuse identities.

“Modern attacks increasingly exploit trust rather than simply targeting vulnerabilities,” Randolph said. “Whether it is software ecosystems, digital identities, or interconnected platforms, adversaries are learning to weaponize trusted relationships to gain speed, scale, and operational access.”

Broad Exposure

What organizations need to take away from all this is that “the attack surface is no longer limited to a single system or user,” he added. “Exposure now exists across entire ecosystems, where one compromised relationship, credential, or trusted platform can create cascading downstream effects. The broader lesson is that digital exposure and operational risk are becoming increasingly interconnected.”

Researchers with a number of security firms, including Endor Labs, Aikido, Socket, and StepSecurity, wrote reports in recent days outlining the latest round of attacks that involve compromised npm and PyPI packages from a range of companies, including Mistral AI, Guardrails AI, TanStack, and UiPath.

TeamPCP emerged last year, targeting cloud-native environments with automated supply-chain attacks that plant malware into software updates that infect organizations that download them. In this campaign, the threat actors acquired broad permission in GitHub Actions workflows and made their payload appear to be an initialization module.

Stealing Credentials and Secrets

An obfuscated JavaScript file planted in the npm packages looks for secret files and SSH keys and steals credentials – including security keys and passwords – and targets high-profile cloud players like Google Cloud Platform, Amazon Web Services, HashiCorp Vault, and Kubernetes, as well as AI tools, messaging apps, and cryptocurrency wallets.

In line with other TeamPCP attacks, the malware creates a ransom note and threatens to wipe the computer of its data if the victim tries to revoke the compromised access.

Jason Soroko, Senior Fellow at Sectigo, noted that the “latest wave adopts a stealthier execution model. By bundling a JavaScript payload within the package tarball and utilizing an optional GitHub dependency to trigger execution via the Bun runtime, the attackers bypass traditional static scanning.”

Same Goals, Bigger Scale

Aikido security researcher Raphael Silva wrote in a report that the vendor’s malware team detected 737 malicious package-version entries across 169 npm package names. The campaign echoes another one involving Shai-Hulud last month that targeted SAP packages.

“The basic goal is still the same: steal credentials from developer machines and CI/CD runners, then use those credentials to reach more packages,” Silva wrote. “What changed is the scale and the release path. This wave does not just look like someone manually publishing bad versions. The malware is built to run inside build systems, steal npm and GitHub access, and abuse trusted publishing paths to push new compromised packages. … This is the follow-up: the same idea, but with a much bigger blast radius.”

‘The Worm is Iterating’

Peyton Kennedy, security researcher with Endor Labs, wrote that Mini Shai-Hulud is not only getting larger, but also more technically sophisticated with each campaign. For example, the four SAP packages in two weeks became 84 TanStack packages and the static-token and OIDC branch-push vectors in the SAP campaign now include “a new orphaned-commit-through-a-fork technique that bypasses branch protection rules while still yielding a legitimate OIDC-derived publish token,” Kennedy wrote.

“The underlying truth of this campaign arc remains unchanged: provenance tells you where a package was built, not whether the build was authorized,” he wrote. “OIDC trusted publishing removes the need for long-lived tokens, but introduces a new trust surface — the scope of what workflows and commits can request those tokens. Narrowing that scope to the minimum required is the control that closes this class of attack.”

“The worm is iterating. Defenders need to as well,” Kennedy wrote.

May 15, 2026
Bad Actor Drops 36 Malicious Packages in npm, Targets Guardarian Users

The npm code repository is again being used by a bad actor to launch a supply chain attack that includes three dozen malicious packages that appear as Strapi CMS plugins but deliver a range of threats.

Strapi is a popular open source headless Node.js content management system developers use to build, manage, and expose content through REST or GraphQL APIs while using a range of front-end frameworks, like React, Next.js, and Vue. Capabilities that make it attractive include a customizable administrator panel and flexibility in databases developers can use.

According to researchers with cybersecurity vendor SafeDep, the 36 malicious packages were published using four npm accounts, with varying numbers of packages in each account.

“Contrary to what you might expect from a package-spam campaign, the analyzed packages carry different payloads — eight distinct variants in total — revealing a real-time attack development session against a specific target,” researchers with cybersecurity vendor SafeDep wrote in a report. “This campaign is a rare window into an attacker’s real-time development process. Over 13 hours, the operator published ten packages with eight distinct payloads, each iteration responding to what was likely working (or not) against their target.”

Multiple Threats

The payloads carry a range of threats with them, from Redis remote code execution (RCE) and PostgreSQL exploitation to Docker and Kubernetes container escape, credential harvesting – such as passwords, SSH private keys, and cryptocurrency wallet information – persistence, and Python reverse shell deployment.

“Every package contains three files (package.json, index.js, postinstall.js), has no description, repository, or homepage, and uses version 3.6.8 to appear as a mature Strapi v3 community plugin,” the researchers wrote. “The package names follow the naming convention used by legitimate packages like strapi-plugin-comments or strapi-plugin-upload. All official Strapi plugins are scoped under @strapi/, making these unscoped names a social engineering choice targeting developers searching for community plugins.”

The attacker’s malicious code is found in the postinstall file script, which is different for each package. It is executed on “npm install” through the postinstall script, without any interaction from the user being needed. It includes the privileges for the installing user, which in CI/CD environments and Docker containers means root access.

Guardarian is the Target

The campaign appears to target Guardarian, a European Union-based cryptocurrency gateway that allows users to buy, sell, and swipe more than 1,000 cryptocurrencies. From the first payload onward, Guardarian references are found.

This confirmed that “this was a targeted campaign against a cryptocurrency payment platform from the very beginning — not an opportunistic spray that became targeted over time,” they wrote. “The hardcoded database password in Payload 6 proves this is not the attacker’s first interaction with the target’s infrastructure.”

Multiple Packages Over 13 Hours

The SafeDep researchers were able to track the packages published over a 13-hour period. The first hour involved the two payloads that came with Redis RCE exploitation, with crontab injection, SSH key injection, and other capabilities.

That was followed over the intervening hours by payloads with simplified direct reverse shells and then reconnaissance to collect credentials and secrets for future use, direct database exploitation using hardcoded PostgreSQL credentials to grab Strapi data, probing for Guardarian payment.

Hours 10 through 13 were focused on persistent access, with the bad actor switching to a second npm account and deploying persistent implants and armed with the target’s hostname, CI/CD pipeline, and secrets directory layout.

“The eight payloads show a clear narrative: the attacker started aggressive (Redis RCE, Docker escape), found those approaches weren’t working, pivoted to reconnaissance and data collection, used hardcoded credentials for direct database access, and finally settled on persistent access with targeted credential theft,” they wrote.

Rotate Credentials

Developers who installed any of the malicious packages need to assume they’ve been compromised and rotate credentials – database passwords, API keys, JWT secrets, and private keys, among others — that are stored on their system.

The campaign is only the latest in a growing trend of dropping malicious packages into code repositories to initiate supply chain attacks. Sonatype researchers wrote that throughout last year, they identified more than 454,600 such malicious packages, bringing the total of known and blocked malware to more than 1.233 million packages not only in npm but also PyPI, Maven Central, NuGet, and Hugging Face.

“This year, we observed that the evolution of open source malware crystallized, evolving from spam and stunts into sustained, industrialized campaigns against the people and tooling that build software,” they wrote, adding that both the scale and sophistication of the threat grew in 2025.

More than 99% of open source malware last year was found on npm. State-linked threat actors like North Korea’s Lazarus Group was able to plant five-stage payload chains that included droppers, credential theft, and persistent remote access, while Shai-Hulud “proved that open source malware can now propagate autonomously through open source ecosystems,” they wrote.

April 6, 2026
Sophisticated Supply Chain Attack Targeting Trivy Expands to Checkmarx, LiteLLM

The supply chain attack that compromised Aqua Security’s Trivy open source security vulnerability scanner and its associated GitHub Actions earlier this month continues to expand, with software development tools from Checkmarx and LiteLLM being the latest victims of the sophisticated campaign.

The threat group behind it, TeamPCP, is using the attacks to create persistence and to steal credentials and sensitive digital keys from organizations.

“The TeamPCP stealer’s primary function is harvesting credentials from CI runner memory,” Sysdig threat researchers wrote. “When a compromised Trivy action executes in a workflow, it extracts GitHub personal access tokens (PATs) and other secrets from the Runner.Worker process memory. If those tokens have write access to repositories that also use Checkmarx actions, the attacker can use them to push malicious code to additional action dependencies.”

The researchers added that such action “creates a cascading supply chain compromise: One poisoned action harvests credentials that enable poisoning of additional actions, each using a different typosquat domain to avoid pattern-based detection.”

A Moving Target

Damon Small, a board member with security firm Xcape, said that “the risk here is a ‘wormable’ supply chain: the malware scrapes runner memory for GitHub PATs and cloud keys, which it then uses to compromise any other repositories that the infected pipeline has write access to. For defenders, the priority isn’t just updating Trivy; it is a scorched-earth credential rotation.”

Small added that “it takes a special kind of irony for a vulnerability scanner to become the primary infection vector for your entire cloud environment.”

Organizations with pipelines that ran a Trivy scan between March 19 and 23 need to assume that every secret that was accessible through the scans – from Amazon Web Services (AWS) keys to npm tokens to SSH keys – has been stolen, Small said.

“Moving forward, security teams must enforce the pinning of all third-party GitHub Actions to full 40-character commit hashes to prevent this ‘silent’ tag-swapping from recurring,” he said.

Incomplete Containment an Issue

According to Wiz researchers, TeamPCP actors were able to launch the multi-faceted attack through access gained via the “incomplete containment of an earlier incident,” pushing credential stealer code from a typosquatted domain into Trivy and publishing “backdoored binaries … to GitHub Releases, Docker Hub, GHCR, and ECR. The maintainers have since removed these malicious artifacts.”

Palo Alto Networks researchers noted that “incomplete containment is a recurring issue in incident response. When breaches are not fully addressed, they create the conditions for the next attack.” That was the case with Trivy.

The Python-based payload harvested not only credentials from cloud providers AWS, Google Cloud Platform, and Microsoft Azure, but also Kubernetes secrets, CI/CD and application secrets, infrastructure and access information, and cryptocurrency, according to Microsoft’s Defender Security Research Team.

Keeping Under the Radar

The attackers were able to pose as legitimate developers, and according to Microsoft, “after exfiltration, the malware cleaned up all temporary files and launched the legitimate Trivy scan. The workflow completed successfully with expected output, masking the compromise from pipeline operators.”

The persona impersonation tactics used by the TeamPCP attackers were similar to what Microsoft researchers saw in the Shai-Hulud 2.0 campaign.

Suzu Labs CTO Denis Calderone said security teams need to pay attention to TeamPCP’s technical execution.

“Stolen credentials from a misconfigured GitHub Actions workflow gave the attackers access to push malicious code into 75 of 76 version tags,” Calderone said. “The payload ran inside CI/CD pipelines, silently collecting GitHub tokens, cloud credentials, SSH keys, Kubernetes tokens, database passwords, and crypto wallets from every pipeline that pulled the compromised version. CI/CD runners hold the keys to everything, so compromising the pipeline is effectively compromising every environment that pipeline touches.”

After the Trivy compromise, TeamPCP was able to expand its reach into Checkmarx’s KICS open static code analysis tool and LiteLLM, an open source AI gateway that offers a unified API that is compatible with OpenAI and use to call more than 100 large language model (LLM) provides, including OpenAI, Azure, AWS’s Bedrock, and Google Cloud Platform.

TeamPCP Worms Its Way In

The expansion to other victims was accomplished through CanisterWorm, which TeamPCP launched by using stolen credentials, according to Palo Alto researchers. The worm compromised more than 45 npm packages across various scopes.

“Later variants added token theft and malicious publishing in the postinstall hook, making every developer or CI pipeline that installed an affected package an unwitting propagation vector,” they wrote. “Twenty-eight packages were compromised in under 60 seconds.”

The CanisterWorm component caught the attention of Suzu Labs’ Calderone.

“This is the first documented malware to use blockchain for command and control,” Calderone said. “Instead of traditional C2 servers that can be seized or sinkholed, the attackers are using smart contracts as a decentralized dead-drop. There’s no single server to take down, no domain to block. The operator can rotate payloads on-chain without ever touching an infected host.”

He called it “a fundamental shift in how attackers maintain persistence and control, and if this model proves out, it’s going to change how we think about disrupting campaigns.”

Targeting Open Source, AI Development

Sonatype researchers noted the targeting of LiteLLM, writing that the attackers are “looking to take advantage of enterprises leveraging open source to rapidly develop and deploy AI applications. The design of the malware suggests a broad targeting strategy aimed at developers, cloud environments, and modern application infrastructure.”

Kubernetes environments are getting attention from the bad actors, but the data being collected is intentionally expansive, targeting any system that can store credentials or interact with cloud services.

“This makes the software supply chain attack especially dangerous in environments where developers, CI/CD systems, and production infrastructure share access to sensitive credentials, as compromise in one layer can quickly cascade into others,” they wrote.

March 25, 2026
Analysis of GitHub Repositories Surfaces Nearly 23M Secrets

An analysis of public GitHub repositories published today finds 22.8 million hardcoded secrets, representing a 25% increase since a similar study was done a year ago.

Conducted by GitGuardian, the analysis also discovered well over a third (35%) of all private repositories contained at least one plaintext secret that could easily be discovered.

More troubling still, 70% of the secrets that GitGuardian discovered in 2022 still remain active three years later, according to the report.

In total, 4.6% of all public repositories contained a secret, 58% of all detected secrets were generic, including hardcoded passwords embedded in source code, database connection strings, custom authentication tokens and encryption keys stored in plaintext.

Soujanya Ain, senior product marketing manager for GitGuardian, said the report makes it clear that despite increased adoption of best DevSecOps practices and the availability of services such as the GitHub Push protection plan, the number of applications secrets that cybercriminals can easily gain access to, continues to increase.

Tools such as GitHub Copilot are also contributing to the problem. Out of the 20,000 repositories that provide access to GitHub Copilot, more than 1,200 had at least one secret, representing 6.4% of the sampled repositories.

In addition, 2,584 repositories where continuous integration/continuous delivery (CI/CD) configurations indicated the availability of a secrets manager, 132 repositories had leaked at least one exposed secret, representing 5.1% of the studied repositories. Overall, the most frequently leaked secret discovered in public repositories (19%) provided access to the MongoDB document database.

However, private repositories also appear to be providing application development teams with a false sense of security. For example, identity access management (IAM) keys for accessing Amazon Web Services (AWS) services appearing in plaintext accounted for 8% of the secrets discovered, compared to 1% in public repositories. Generic passwords appeared three times more often (24%) in private repositories than they did in a public repository.

Additionally, secrets are also being embedded in images that can be easily discovered. For example, nearly all the secrets (98%) of the secrets detected in DockerHub were in an image, with more than 7,000 AWS keys exposed. Approximately 100,000 valid secrets, including AWS keys, Google Cloud Platform (GCP) keys, and GitHub tokens belonging to Fortune 500 companies, are currently exposed. Out of 1,179,475 unique secrets detected, 101,186 were automatically verified as valid, according to the report.

The report also notes that IT tools routinely contain exposed secrets, with 2.4% of the Slack channels analyzed containing leaked secrets and 6.2% of tickets created using Jira software from Atlassian exposing secrets. These tools have become a major blind spot for many organizations, noted Ain.

The degree to which more secrets are being exposed versus discovered using machine learning algorithms is unclear, but, in an era where cybercriminals have discovered they can use stolen credentials to simply log into application environments to spread malware, the management of application secrets still needs to become a more pressing concern.

March 11, 2025
HashiCorp Extends Secrets Management Reach

Secrets management is core to DevSecOps—how credentials are managed can make all the difference in preventing an application from being compromised in the first place. The challenge is making it as simple as possible for developers to access where most of those credentials are stored in the enterprise.

HashiCorp this week released an update to the open source Vault secrets management software that adds support for both the Microsoft Azure Active Directory Auth Method and the identity and access management (IAM) engine used in Google Cloud Platform (GCP). Those new capabilities complement existing support for LDAP, Amazon Web Services IAM, Kubernetes, GitHub, Okta or others.

In addition, version 0.10 of Vault adds support for a graphical user interface (GUI). Previously, the GUI was available only in the enterprise version of Vault that HashiCorp supports. But Andy Manoske, a product manager for HashiCorp, said organizations are making it clear they want developers and cybersecurity professionals to make use of the same core secrets management framework. Because most cybersecurity professionals don’t know how to program it became necessary to add a GUI to the core Vault open source software, Manoske said.

In general, Manoske says developers and cybersecurity professionals are starting to work more closely together. Microsoft Active Directory is the most widely used platform for storing credentials. As enterprise IT organizations start to move more Windows applications to the cloud, enabling developers to programmatically access the credential data is becoming a bigger requirement, he said.

Additional capabilities in version 0.10 of Vault include the ability to automate the rotation of root credentials at specified intervals and support for versioning. That latter feature is critical for both compliance and disaster recovery purposes, as well as enforcing temporary changes to secrets keys during the investigation of a potential cybersecurity breach, Manoske said.

From a DevSecOps perspective, Manoske said the biggest challenge remains the reliance on manual efforts to manage secrets within the applications rather than storing them externally in a secrets management platform. Cybercriminals increasingly are making use of automation tools to scan applications for vulnerabilities that enable them to compromise credentials. Vault provides a means for managing credentials that encrypts credentials that can be applied across thousands of applications at scale. It’s hard to see how organizations can address application security without finding some way to automate secrets management, he said.

Progress in DevSecOps so far has been slow, but steady. Most organizations won’t be able to address DevSecOps effectively until they master DevOps fundamentals. Once that occurs, organizations need to establish a workflow between developers who want to address every function with application programming interfaces (APIs) and cybersecurity professionals that define corporate policies.

Embracing DevSecOps is, of course, as much about the processes and culture as it is about new technologies. The real challenge is finding a way for developers and cybersecurity professionals to collaborate without seriously compromising the rate at which applications are being developed.

— Mike Vizard

April 11, 2018
Moving Security Beyond SSH and PKI

SSH (secure shell) is still the most common method of remotely accessing a Linux server, which makes it a common target for attackers attempting to infiltrate corporate networks. While the protocol itself carries a number of advanced security properties, it does allow for human error, opening the door for unwarranted privileged access to sensitive company resources.

Keeping track of all valid credentials across a company is something that IT departments continually struggle with. The stakes are high if they fall into the wrong hands, essentially handing over the proverbial “keys to the kingdom.” A recent study by Dimensional Research found that 90 percent of respondents do not have a complete and accurate inventory of all SSH keys, and 63 percent don’t actively rotate keys, even when an administrator leaves the company.

Managing privileged access to servers has always been a rigorous exercise in key management. There are a number of best practices to follow to avoid the many common pitfalls, such as storing private keys in a vault service or maintaining a strict rotation policy, but they don’t get to the crux of the matter: The credentials are static. Here’s a (not so) crazy thought: What if we got rid of them entirely? Static credentials are a thing of the past, representing the failed perimeter model of corporate security.

Problems with Traditional PKI

The traditional PKI (public key infrastructure) that backs SSH was built for a different time, when a key exchange meant enough to grant trust. Without a proper authentication process, there is no clear way to attribute to a person, nor a feasible way to provide any historical context. As these keys get issued and distributed across fleets of infrastructure and cloud services, the challenge only compounds. Each public key accrues more privileges over time; the longer it’s been alive, the more likely it’s been shared with a resource, making it extremely difficult to track and subsequently revoke. With this model, time is a bug that can’t be fixed.

Authorizing a specific request should also go beyond the mere presence of the public key within the authorized_keys file of the server. Independent of authentication, authorization is about who should and should not be able to access a specific server from a known device, and what permissions they have on the machine. You may have a policy that states only members of the engineering team can only access a production server through a bastion host. Adhering to that policy in practice, however, is impossible without a proper authorization process.

Enter Zero Trust Security

We’ve come to a consensus across the industry that the network perimeter is breaking down in the modern cloud era. It’s time to take that one step further and agree on a new model of trust attestation to match, where decisions are removed from the network layer and handled correctly at the application layer. Flipping the model around like this means starting with zero privileges by default, and only granting access to a resource once a request has been fully authenticated and authorized. Verify, then trust—the mantra of Zero Trust.

Google’s BeyondCorp is the marquee example of Zero Trust done right, an internal initiative meant to better secure how employees access corporate resources. The end result is a carefully crafted distributed system that makes real-time trust decisions based on what is known about a user and their device, allowing the thousands of Googlers across the globe to work securely from any location without the use of a VPN. BeyondCorp is just one example, and we’ve seen more and more companies start to adopt a similar approach.

Ephemeral Client Certificates

The thinking behind ephemeral credentials is that a request triggers independent authentication and authorization processes, where a trust attestation is made against the policies of the resource. If valid, a single use credential is issued, which is used to initiate a secure session with the resource. This credential is tightly scoped to the specific request, rendered useless in any other scenario.

The fundamentals of this workflow can be accomplished through a client certificate-backed PKI architecture. Client certificates became a supported feature of OpenSSH in 2011 with the introduction of version 5.4. Unlike standard SSH keys, which carry no metadata, certificates are cryptographically verifiable metadata objects that can inject information such as usernames, roles and more. Time now becomes a feature because the scope of the credential truly represents a dynamic attestation of trust.

The fine-grained access controls inherent in a client certificate-backed PKI architecture solves for the problems with SSH keys because the credential can be tied to an actual user. The threat vector of lost, stolen or misused credentials is also eliminated, saving managers from the numerous headaches associated with SSH key management.

To put these ephemeral credentials into action, you need to surround the client-certificate PKI with the supporting access controls. Companies with the means can build their own system similar to Google’s BeyondCorp, but this is no simple task, as you need to operate your own Certificate Authority along with a distributed system capable of performing dynamic authentication and authorization against policies in real time.

About the Author / Ivan Dwyer

Ivan Dwyer is the VP of Product Marketing at ScaleFT, working with the community to raise awareness around BeyondCorp and Zero Trust for organizations of all kinds looking to modernize their security architecture. Connect with him on LinkedIn and follow him on Twitter.

December 5, 2017
DevOps and Database Security

Osterman Research recently released a survey-based report on database security. The results don’t exactly instill confidence where username breaches are concerned: While more than 50 percent of respondents felt that a breach of the database would be a serious problem for their organization, 44 percent responded that it would take more than a day to detect compromised credentials and a breach of data. Considering that attackers are going to get in and get out as fast as possible, more than 24 hours is plenty of time for those compromised credentials to result in copies of tables making their way to the dark web. Some of our biggest hacks—Yahoo! springs to mind—take much, much longer to be detected.

There are tools available to monitor database logins and activity, from free (and sometimes onerous) logging for databases including MariaDB, MongoDB and MySQL to review and analysis through things such as Splunk plugins for most database systems. Once you are tracking logins and source IPs and possibly watching for spikes in query volumes, the power of DevOps can help you manage monitoring.

The key here is to collect the data, even if temporarily. A great first step is building a process that turns on login-attempt logging for a set period of time, then processes the resulting file to send the user a list of when they logged in and from where.

Next, capture summary information about number of queries and response sizes. That can show abuse of credentials, by either internal or external bad actors. The issue is not the availability of tools to do these jobs; the issue is making it a priority.

While not exposing your database to the internet is a good policy, monitoring database credentials provides in-depth defense against external attackers and a defense against internal attackers. Utilizing the tools available plus some work from DevOps (to automate the process, then to work out a way to add new application and user logins to the monitoring system) will improve your ability to detect credential issues, and the process—as so often happens when DevOps is involved—will force you to review which applications are hitting the database from where, possibly opening eyes to ideas for improvement in database usage and location.

These are the areas of security where DevOps really can help; it is rare for any one team to control security for logins/queries on the database. Is it the DBA’s responsibility? The security team? Operations (which generally creates the accounts)? Utilizing the tools available, and sitting down to discuss which makes the most sense for your organization, you can generate a simple report to be reviewed on a regular basis and settle the responsibility question. That means there is no huge loss of time pawing through logs and no waiting weeks to find out your database has been exfiltrated. It just makes sense, and it bridges the gap where security gets direct benefit out of DevOps, instead of the indirect benefit offered by standardized processes.

— Don Macvittie

April 14, 2017