News and Tech Update

Every software team eventually runs into the same question: How much testing is enough? For years, the default answer has been “more.” More automated tests. More regression suites. More environments. More devices. But as applications become more complex and release cycles continue to accelerate, testing everything simply isn’t realistic, even with the support of AI. Modern software is built on microservices, third-party APIs, cloud infrastructure and code that is constantly changing. Teams are expected to release faster while maintaining quality, security and reliability. The challenge isn’t a lack of commitment to testing; it’s that time and resources are finite. Instead of asking, “How much testing is enough?” we need to determine “What should we test first?” The answer starts with understanding risk. Not Every Bug Carries the Same Risk One of the biggest mistakes organizations make is treating every bug as equally important. A typ...

Fortunately, companies do not always have to choose between in-house vs outsourcing . Instead they can adopt a hybrid development strategy, which combines the capacities of internal and external IT teams. This approach allows companies to capitalize on the strengths of both traditional software development models, while offsetting their respective limitations, thereby streamlining project execution. However, to leverage a hybrid model successfully, companies must be prepared to tackle the operational complexities that arise when internal and external teams work together. This article explores why companies adopt a hybrid development model, outlines its key challenges, and provides recommendations to address them. Why Businesses Choose a Hybrid Software Development Model Even proficient internal development teams can face challenges delivering new software projects end-to-end. For instance, a team can have sufficient proficiency to handle the majority of frontend and backend developm...

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience. Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it tends to create opportunities for others. The ten job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale being offered. We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration. Dice Booz Allen Hamilton McLean, VA DevOps Engineer $77,600 to $176,000 Alarm.com Centennial, CO DevOps Engineer $120,000 to $130,000 HarbourVest Partners Boston, MA DevOps Engineer $135,00...

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