News and Tech Update

Certificate renewal is often treated as a scheduled task: run an ACME client, obtain a new certificate, and move on. In practice, that view is too narrow for production systems. A certificate is not useful because it exists on disk. It is useful because the right service is presenting it to users. Between issuance and that final state, several operational steps can fail. The more useful way to think about renewal is as a deployment workflow: renew, deploy, reload, verify, and recover when something goes wrong. Renewal Success Is Not Production Success The first failure mode is simple: a certificate authority successfully issues a new certificate, but the service continues using the old one. The renewal job is green, yet the incident clock is still running. This happens because issuance and production state are different things. The certificate may need to be copied to a specific host, mounted into a container, written to a secret, synchronized to a load balancer, or placed behind ...

Sonar today made available an artificial intelligence (AI) agent designed to discover vulnerabilities and business logic flaws that pose the greatest risk to an organization should they be exploited. The SonarQube Hunter Agent first analyzes an entire codebase to find three categories of flaws: broken access control, business-logic vulnerabilities, and authentication or session-management issues. Satinder Khasriya, a technical product marketing manager for Sonar, said that, historically, discovering these issues would have required manual testing or a penetration test. The AI agent developed by Sonar automates those investigations by tracing how code and data move through a system in a way that can now run on demand, he added. Additionally, SonarQube Hunter Agent is able to identify the developer who created any piece of code, with verified issues that are surfaced within a DevSecOps workflow via integrations with continuous integration/continuous delivery (CI/CD) platforms. That’...

AI coding agents are becoming part of everyday development work. Developers use them to find libraries, configure projects, troubleshoot installation problems, and set up new tools. An agent can search GitHub, read project documentation, and run commands without the developer having to work through every step manually. That convenience is creating another security concern for DevOps teams. An agent can encounter software and instructions during a task, decide that they are relevant, and act on them. A repository, README file or configuration file can therefore become part of the execution path. Recent attacks have shown how this can be abused. Malicious repositories have been created to attract AI coding agents, while researchers have demonstrated attacks that use project instructions to influence what an agent downloads or executes. Once an agent has access to a terminal, the filesystem, or the network, a routine development task can provide malicious code with a way into the envir...

Harness today launched a code repository service that is specifically designed for DevOps teams that are relying on artificial intelligence (AI) agents to generate code. Martin Reynolds, Field CTO for Harness, said the Agent-Ready Harness Code Repository and AI Code Review service provides an alternative to existing GitHub source code repositories that were not designed to handle the volume of pull requests and updates that are made by AI agents operating at machine speed. As a result, there are not only more outages but search and file history get slower as indexing falls behind, pull requests pile up faster than anyone can read them, and a permission system designed around a list of developers lacks the ability to identify and track an AI agent that might merge code on its own. The assumption legacy source code management tools make is that a human wrote code and opened a pull request that will be reviewed sometime later. In contrast, the Harness Code Repository has been tested t...

An AI agent that can call tools is not automatically an unsafe system. The dangerous move is smaller: Letting a workflow turn a recommendation into an external action without a durable decision record. That distinction matters in DevOps. An agent can sensibly summarize a failed deployment, draft a rollback plan or classify a dependency alert. The moment it opens a change request, modifies a feature flag, creates an incident, messages a customer or publishes a configuration, the system needs more than a high-confidence score. It needs a change-control gate. The gate below is a practical pattern for a tool-using agent. It verifies whether the policy is still current, pauses for the required human decision, makes one idempotent outbound request, then confirms the receipt. It is deliberately boring. That is the point. Figure 1: Illustration of a Workflow Moving Through Policy, Human Approval and Idempotency Gates While a Risky Duplicate Path is Stopped Why a Confidence Threshold Isn’...

In an enterprise environment, production failures are more often defined as testing failures , but they include other high-impact aspects, such as release readiness, data quality, exception handling and operational approval. However, the missing layer is not just about conducting more testing. It should include a proper, disciplined review process for the validation of business-critical data and release activity. The problem is not just about the effect of production on payroll, benefits, reporting, reconciliation or other sensitive operational functions. Production issues can also lead to payment problems, downstream reporting errors, audit concerns and operational disruption. Production readiness should be treated as a business-control question, not just as a software-quality question. What Production Validation Means Figure 1: Enterprise Release Workflow Incorporating Production Validation As illustrated in Figure 1, production validation is the operational discipline that sits...