News and Tech Update

Security researchers have uncovered a GitLab behavior that could let attackers use a leaked project email address to push code, trigger CI/CD jobs and reach other repositories accessible to the address owner. Aikido Security researcher Joe Leon detailed the attack path this week in a blog post after reporting it to GitLab earlier this year. The issue involves GitLab’s incoming email token, a credential embedded in private email addresses that GitLab provides for creating issues and merge requests by email. “The token inside this email address is essentially a fine-grained personal access token with significant access to your GitLab projects,” the report said. GitLab’s documentation says the token never expires and warns that anyone who obtains it can create issues and merge requests as the user. GitLab also allows users to attach .patch files when creating merge requests by email. GitLab applies the patches to the named source branch or creates the branch if it does not already exi...

A dependency scan warns of a vulnerable library several hours before the release. The developer finds a solution, but it might affect some working features, and security and operations teams wait for approval to take any action. The end-of-line race against the clock to finalize releases is well known to teams that postpone security decisions to the final hours of a release. DevSecOps teams can streamline such processes by establishing protocols and providing feedback as the work progresses. This article discusses the location and responsibilities involved in making such determinations and decisions and examines approaches to negotiating releases in the presence of an unresolved security problem. Why the Final Security Gate Slows Everyone Down It is a difficult situation, however, to discover that a design choice needs to be changed. Late findings also raise new questions that should have been asked earlier. Should the developer be expected to investigate every scanner finding? Can t...

The control that held your infrastructure together was plan review, meaning a person reading a diff and deciding whether to approve it. Not the policy document and not the pipeline configuration. It worked because change arrived at human speed. That condition no longer holds. An agent opens 40 pull requests before lunch. Reviewers approve them to clear the queue. The approval requirement is still declared in the workflow file, still blocking the merge, still writing an audit event, and no longer doing its job. Nothing removed plan review. Change volume saturated it. A saturated control emits the same signals as a working one. What Plan Review Was Actually Doing The approval action performed four distinct functions. Nobody designed that bundle; it accumulated over time, with a required reviewer after an outage and a checklist after an audit, each attaching to the action already in the workflow. Policy compliance: Does the change conform to the rules the organization agreed to? Bl...

Talentica Software this week launched a managed software delivery service that leverages artificial intelligence (AI) to enable DevOps teams to deploy applications developed using AI coding tools at scale. Company CTO Manjusha Madabushi said the DevX AI Pods service makes use of a set of AI agents that Talentica has trained to provide the context needed to successfully build and deploy applications using AI tools. Those agents analyze existing artifacts such as product requirement documents (PRDs), the codebase, test cases, and the underlying software architecture to ensure that the application developed using AI tools can actually run in a production environment, she added. Specifically, AI agents leverage a Correctness, Consistency, Completeness and Relevance (CCCR) framework that Talentica developed to evaluate the code being created. That output is then validated by a team of more than 600 Talentica software engineers to ensure it meets the original criteria specified. That app...

About 170 private GitHub repositories belonging to French cybersecurity company CrowdSec were compromised and source code was stolen by attackers earlier this year in the wake of an npm supply chain attack in May by the notorious TeamPCP threat group on TanStack. TeamPCP used the Mini Shai-Hulud self-propagating worm to grab credentials and tokens and published 84 malicious artifacts across 42 TanStack packages, and CrowdSec GitHub repositories were caught up in the attack. CrowdSec, which crowdsources threat intelligence, earlier this month learned that source code had been stolen from the laptop of a former employee that was compromised in the TanStack attack. An OAuth token taken from the ex-employee’s GitHub account still had permission to read the vendor’s private inventories. TeamPCP on May 22 took credit for the supply-chain attack on TanStack 11 days earlier. In all, about 300 CrowdSec public and private repositories were compromised. Also on May 22, one of the founders of...

Deployment frequency has become one of the clearest markers of a mature engineering organization. Teams that once shipped monthly now ship daily, and teams that shipped daily now ship several times a day. This shift has largely delivered on its promise. Smaller changes are easier to reason about, rollbacks are faster, and feedback loops are shorter. What has received less attention is the effect this same shift has had on the practice of debugging performance issues. Several assumptions that previously held, a stable release to compare against, a known change set behind a given incident, sufficient time between deployments to observe a system before the next one lands, no longer apply in the same way. A Moving Baseline Performance debugging has traditionally depended on comparison. An engineer examines current behavior against a known good state, typically the previous release, and narrows down what changed. This approach works well when releases are infrequent enough that the previ...