News and Tech Update

GitLab administrators got an unwelcome reminder this week that a single API endpoint can undo years of access control work. On September 10, GitLab shipped a critical patch release — versions 19.3.2, 19.2.6 and 19.1.8 — to fix 18 security vulnerabilities, two of them rated critical. One of those two is about as bad as a vulnerability gets: an unauthenticated attacker can read arbitrary files off a self-managed GitLab server without so much as a login attempt. That flaw, tracked as CVE-2026-85706, lives in GitLab’s repository commits API. GitLab describes it as improper path confinement combined with missing authentication enforcement on the endpoint. In practice, that means someone outside the organization, with no credentials, could send a crafted request and pull back files that should never leave the server: configuration files, tokens, SSH keys, database credentials. GitLab gave it a CVSS score of 10.0, the maximum on the scale, because it requires no authentication and very ...

Somewhere along the way, DevOps became a tooling conversation. Ask someone how mature their DevOps practice is and the answer will often involve CI/CD pipelines, automated testing, infrastructure as code, observability, deployment frequency, or some combination of the above. All valuable tools, but that is often where the conversation ends. They compartmentalize DevOps principles to a niche scenario and ignore those same principles when it comes to team dynamics, organizational design, strategy, product development, and so on. This becomes more obvious when we return to the Three Ways, commonly summarized as Flow, Feedback, and Continual Learning. These ideas are often explained through software delivery because that is where DevOps emerged, but nothing about them inherently limits their application to software tooling. They describe how information moves through a system, how the system learns what happened, and how that learning changes what happens next. It is essentially PDSA in ...

Security tooling has a familiar adoption problem. The organizations that need it most — the ones scaling fast enough that their attack surface is outgrowing their process — are often the same ones that can’t justify a sales call and a signed contract just to see whether a product fits. They want to turn it on, run it against real repositories, and see what it actually finds before anyone talks pricing. GitHub just made that path available to a lot more of them. The company raised the eligibility ceiling for self-serve GitHub Advanced Security (GHAS) trials, moving the cap from enterprises with up to 100 licenses to those with up to 300. Any GitHub Enterprise Cloud organization under that new threshold can start a 30-day trial directly from the “Billing and licensing” page in their enterprise settings, no sales conversation required. During the trial, an organization can add any number of committers and turn on both GitHub Secret Protection and GitHub Code Security acr...

Vulnerability prioritization is not a language problem. The safest agent architectures use models to interpret and explain, while deterministic systems traverse the evidence. Ask a security team a simple question: Of the vulnerabilities your scanner reported this morning, which ones can actually be exploited in production? The honest answer is often that nobody knows yet, and proving it can take hours or days. That makes it tempting to point an AI agent at the scanner output and ask for a prioritized list. The agent will respond immediately, in fluent prose, with a confident rationale. But if the evidence required to determine exploitability is not in the input, the answer is still a guess. Better model quality does not solve missing data. Exploitability Is a Property of a Path Exploitability is not simply a property of a vulnerability record. In production, it depends on relationships. To determine whether a vulnerable library matters, a team may need to establish that the packa...

Atlassian today extended the capabilities of its portfolio to provide teams of artificial intelligence (AI) coding agents with the level of context needed to build and deploy applications in production environments at much higher levels of scale. Code Context, built on Atlassian’s Teamwork Graph, makes it possible for AI coding agents to generate more reliable output by, for example, vetting ideas for architectural feasibility before a line of code is generated, while Agent Context Controls makes it possible for DevSecOps teams to govern which agents can operate in a space and exactly what they’re allowed to see. Additionally, Atlassian is adding to its Jira and Confluence platforms for managing software development projects an ability to continuously scan for well-defined, unassigned work items that can be delegated to a Jira Coding Agent that creates a pull request for review. An AI Review capability provides a dedicated agent on every pull request, checking it against those coding...

Something specific happened to software delivery in the past two years. The 2026 survey data is unusually clear about what it was. Sonar’s 2026 State of Code Developer Survey found that AI-generated or AI-assisted code accounted for 42% of code committed by respondents , with developers projecting that share to reach 65% by 2027. GitLab’s 2026 AI Accountability Report, a Harris Poll survey of 1,528 developers and technology buyers across six countries, found that 85% agree AI has moved the bottleneck from writing code to reviewing and validating it. Both figures get quoted often. The part that gets left out is that the bottleneck didn’t wander downstream on its own. Engineering organizations moved it there. The Half That Got Automated Was Already Cheap PractiTest’s 2026 State of Testing Report puts AI adoption across testing organizations at 76.8% . Where that adoption went is the more useful number. Teams use AI for test case creation at 69.6% and for scrip...