r/devsecops

We rolled out AI assistants to about 120 engineers and the policy is two paragraphs long. The assistants can read the repo and write files and some of them shell out. Our appsec review covered the model vendor and nothing about what the agent does locally. Im trying to work out where the control points even are, since the laptop is now executing code nobody reviewed. Secrets in env files are the part keeping me up. How are people scoping this?

The line between MDM and endpoint security is getting thinner.
Managing devices alone isn't enough anymore when those same endpoints can be the entry point for vulnerabilities, data leaks, risky applications, or unauthorized access.

A modern MDM should ideally combine device management with security controls such as vulnerability and patch management, application and device controls, web filtering, endpoint DLP, compliance enforcement, and centralized security policies.

The real advantage lies in having these controls work together rather than managing security and device operations through multiple disconnected tools.

Is your organization consolidating MDM and endpoint security or running separate stacks?
Share your experiences.

​

Supply-chain alert: Tensorlake npm package hit by the Shai-Hulud worm. The popular Tensorlake SDK (part of a project with 1,000+ GitHub stars) shipped a poisoned release - version 0.5.144 - infected with the self-propagating Shai-Hulud worm.

The malicious version was published through the project's legitimate GitHub Actions release pipeline, complete with valid SLSA provenance. The attacker poisoned main first, then let the trusted pipeline do the rest.

This is a well-known Shai-Hulud pattern which a single, simple YARA rule flags in milliseconds. In fact a basic rule matched it on the first pass in our own pipeline. If npm, Inc. GitHub ran even a basic YARA scan on packages before publishing, most of these campaigns would be stopped before a single developer is infected. As Al speeds up how fast we ship, we're pulling in dependencies faster than anyone can audit them. Registries like npm sit at the chokepoint, and a basic malware-signature gate at publish time is the lowest bar we should expect.

0.5.144 has been removed from npm and version 0.5.143 is clean. If you installed 0.5.144, rotate every credential reachable from that machine, now.

I finally got to write this blog post, I've wanted to write it for a long time now. It contains the different types of sensitive data we've seen so far, where it's coming from, and why it matters. Hope it can be helpful to some of you!

SAST scan on a PR came back clean. Diff touched auth middleware. Scanner checked for known bad patterns, found none, green check, merged.

Nobody actually traced through what the middleware change did to the token validation order for an edge case that wasn't in the scanner's pattern set, because it wasn't a known vulnerability class, it was a logic gap specific to how this particular service combined two libraries. Found two weeks later during an unrelated audit.

The scan wasn't wrong. It checked what it was built to check and found nothing matching. The gap is that "scan passed" gets read as "this is secure," when it actually means "this doesn't match patterns we already know to look for." Those used to be close enough to the same claim that nobody bothered distinguishing them out loud. Novel logic gaps specific to how a service wires things together were always outside that coverage, just less common before more code started getting generated without someone necessarily tracing the full logic path by hand first.

Not arguing against scanning, obviously it's necessary. Just think "passed the scan" needs to stop functioning as a stopping point for anything touching an actual trust boundary, auth, payment, data access, and start being the floor instead of the finish line.