staging-devopsy.kinsta.cloud

Tag: source code security

xAI Open-Sources Grok Build Coding Agent After Cloud Upload Exposes SSH Keys, Repos

xAI has published the full source code for Grok Build, its terminal-based AI coding agent, on GitHub under an Apache 2.0 license. The release lands three days after a security researcher showed the tool quietly shipping entire developer repositories — SSH keys and password databases included — to a Google Cloud bucket xAI controls.

The timing is not a coincidence. A researcher publishing under the handle Cereblab used the network interception tool mitmproxy to capture traffic from Grok Build CLI version 0.2.93. On a 12GB test repository, the coding task itself generated roughly 192KB of traffic. A separate, undocumented storage channel sent 5.1GB in 73 chunks to a bucket named grok-code-session-traces — about 27,800 times more data than the job required. Files the agent never opened made the trip anyway, along with credentials in tracked .env files, in plain, unredacted form.

One user reported running the tool in their home directory and watching it pull in SSH keys, a password manager database, personal documents, and photos. The uploads happened regardless of xAI’s “Improve the model” privacy toggle, which researchers found had no effect on the behavior. That directly contradicted xAI’s own marketing language, which had told developers that nothing from their codebase was transmitted during a session.

xAI killed the upload server-side on July 13, without a security advisory or a version note explaining what changed. Elon Musk posted that all previously uploaded user data would be “completely and utterly deleted,” though the company hasn’t said how many users were affected, how long the data sat in storage, or offered any way for individual developers to confirm their own repos were purged.

Two days later, on July 15, xAI open-sourced the tool. The GitHub repository at xai-org/grok-build is a substantial release — a Rust workspace north of a million lines covering the agent loop, the file-editing and shell-execution tools, the terminal UI, and the extension system for skills, plugins, hooks, MCP servers, and subagents. Grok Build can now be compiled locally and pointed at a self-hosted inference endpoint, cutting the cloud out of the loop entirely if a team wants that.

It’s worth being precise about what “open source” means here. The license is the real Apache 2.0, and the code is readable end-to-end. But xAI’s own contributing guidelines say external pull requests aren’t accepted — this is a source-transparency release, not a community-governed project. Security issues route through HackerOne, not public GitHub issues. Developers can audit it, fork it, and build it themselves. They can’t send a patch upstream.

That distinction matters for DevOps teams weighing whether to adopt or continue using the tool. Reading the source lets you verify what the agent does with file access before you grant it. It doesn’t give you a say in how the project evolves, and it doesn’t retroactively explain why the upload channel existed in the first place or who inside xAI had access to what was collected.

The episode also lands at a pointed moment for the AI coding agent market. Grok Build competes directly with Anthropic’s Claude Code, OpenAI’s Codex CLI, and community-governed tools like OpenCode — all of which, by design, grant an AI agent read and write access to a developer’s file system. Researchers testing comparable tools during the investigation reported that Claude Code, Codex CLI, and Gemini CLI didn’t show the same whole-repository upload behavior. That’s not a clean bill of health for the category — wire-level auditing of any tool with file-system access is now a reasonable baseline, not paranoia. It does suggest the failure was specific to Grok Build’s implementation rather than an industry-wide pattern.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees the episode as a governance gap more than a one-off bug. “The Grok Build episode reveals coding agents as unmanaged non-human identities, granted standing access to source, credentials, and infrastructure,” Ashley said. “But security programs still govern them as ordinary developer tooling.”

That mismatch, Ashley argued, is what turned a software defect into a trust crisis. “Making the source available after the fact isn’t a substitute for provable security controls,” he said. “Anyone who ran the tool against live credentials before the fix should rotate them now, regardless of xAI’s deletion claims.”

For platform engineering and security teams, the practical takeaway is straightforward. Any coding agent with shell and file-system access should be treated like any other service with broad credentials: reviewed before rollout, monitored at the network level, and covered by a documented data-handling policy that the vendor is willing to put in writing. A privacy toggle that doesn’t actually toggle anything is worse than no toggle at all, because it creates false confidence. Open-sourcing the code after the fact is a legitimate step toward rebuilding trust. It’s a slower, harder path than earning that trust up front.

Developers who ran Grok Build against a repository containing live credentials before July 13 should treat those credentials as exposed and rotate them, regardless of what xAI’s deletion timeline eventually looks like.

July 20, 2026
A DevOps Guide to the Language of DevSecOps
Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:
- Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
- Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
- Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
- High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
- Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.
What is DevSecOps?

DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

DevOps Guide to Security Acronyms

All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

1. SBOM—Software Bill of Materials

A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

2. DAST – Dynamic Application Security Testing

DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

3. SCA – Software Composition Analysis

SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

4. SAST – Static Application Security Testing

SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

5. IAST—Interactive Application Security Testing

IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

6. RASP—Runtime Application Self-Protection

RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

7. OWASP—Open Web Application Security Project

OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

8. XDR—Extended Detection and Response

XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection.

9. XSS—Cross-Site Scripting

XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data.

10. SQLi—SQL Injection

SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

11. CSRF—Cross-Site Request Forgery

CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

12. SAML—Security Assertion Markup Language

SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO).

Conclusion

In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline.

The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

Image Source
April 7, 2023
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.

August 9, 2022