F8
F12 or EscF2 or DeldelF8 or EscF2 or DelWinRE access): F12 (when the Dell logo appears)F10 (but maybe also hidden below F12?)F9 or EscF10WinRE access): F12 (when the Lenovo logo appears)F1 or F2, depending on modelautounattend.xml and populate it (Schneegans can help).
.exe for my favorite backup-scheduling software – might as well have it handy; there’s probably plenty of room to spare on the clean-install USB flash drive.C:\ drive setup and hoping for the best, but if I’d had 2 internal disks, I’d want this, as well as some of my “day 0” steps, to deal w/ getting user accounts’ documents and stuff set up onto a secondary D:\ drive.autounattend.xml on it in the appropriate way.
prepare-oscleaninstall-bootdrive.ps1 script I already wrote.My new computer’s under warranty, so if I realize, at some point, that I’ve got a lemon, I might need to be able to restore it back into the exact shape in which I got it.
(Note: “day -1” involves a lot of waiting on disk I/O against hacky old disks and USB adapters that are all I’m willing to pay for in this era of price gouging, particularly if anything goes wrong and has to be repeated or done in a slower sector-by-sector way, so, seriously, expect it to take a whole day, if not more. Do not get excited about moving on to “day 0” today, and perhaps not even tomorrow or the next day. Schedule a lot of long walks outside and chopping vegetables / folding laundry inside.)
C:\ partition of the drive shipped inside the new PC. Best I could do was restore from the full-image, which seems to report slightly different partition sizes, but oh well. Further compressed imaging works against the restore pseudo-clone as a source, but no compressed imaging works against the internal drive.)-1E VM validation right away, if this is the only backup I’m going to be able to preserve of the “just-unboxed” internal drive state.)
Note: no luck, can’t seem to find a way to get into it. Will just have to table until “day 0” at end of clean install.
X:\ just has cmd.exe with a lot of commands missing or incompatible with WinRE/WinPE modes, so haven’t been able to get it off that on the backup-management flash USB. Waiting for backup attempts to complete so I can reboot into system boot menu & see if there’s some sort of GUI copy of the OS license key, or to see if anything that came w/ the computer’s WinRE/WinPE works any better than the one from my backup-management flash USB.Congratulations, me!
This physical machine can now feel comfortably “mine” (because I now have a “vendor’s” restoration plan).
autounattend.xml configured to do drastic formatting of the new PC’s internal disk, consider booting off my backup-management flash USB and using its PowerShell to wipe the new PC’s internal disk clean and format it.
autounattend.xml, so I need to do those manuallyD:\ drive.)..exe on another computer for the new PC’s serial number and throw it onto a thumb drive, if I don’t want to have to deal with my WiFi card being named “WiFi 2” after you get that .exe with the USB Wi-Fi card.).exe files. I should probably put them into version control, and also should probably script running them as I figure it out, in case I ever need to do a fresh clean install, and put that into version control, too. That or I should add a step to the top of this “day 0” to use Schneegans to modify autounattend.xml to do the driver installation after grabbing them all once the hardware arrives and I know my service tag number. (Actually, I suppose that could also be in parallel on “day -1” alongside unbox-backup.)autounattend.xml file on the clean-backup USB back to all 0s.Congratulations, me!
I am now bootable into my accounts on a cleanly-installed Win11 operating system.
Congratulations, me!
I’ve now basically got this lump of metal set up like “new-laptop-day” feels in an enterprise. It’s cleanly imaged, and it’s auto-managed appropriately.
Congratulations, me! I’ve just been issued a well-managed “new laptop” by my “enterprise endpoint management” department (heh – me).
Time to make it more than an OS – time to make it a system that I can truly call MINE. 💃
Remember, I’m working off a clean OS install, so I’ve got a little bit more to do than I might in, say, a “rollback” to an old backup of a well-worn image.
If I want to get really paranoid, I can manually back up the new PC’s internal disk after each major piece of work, but remember, I’ve also already got dailies going.
IMPORTANT: write things down into remote-backed-up version control. Preferably automating as I go w/ a “GitOps” / “paper plates, not fine china; cattle, not pets” mentality, as, say, idempotent PowerShell scripts. But at the very least as Markdown files / PowerShell comments / etc. (lol, the notes as the Git; my hands and eyes as the Ops.)
%USERPROFILE%/tempyyyymm folder for now, to make it easier to just lift-and-shift Documents and such (trying to leave those empty).autounattend.xml or something. Network & Internet settings -> Advanced Network Settings -> Network reset and letting it restart didn’t help. Hmmmm, maybe the clean install didn’t pick up on this hardware’s driver. 🙁Microsoft Entra Agent ID product manager Vince Smith just came on episode 64 of Merrill Fernando’s “Entra Chat” podcast and shouted out a colleague’s project, the M365 Agent Registry.
Problem is, the M365 Agent Registry’s built-in Microsoft-authored agent listings don’t include client-side “chat UI tools” like GitHub Copilot CLI and the GitHub Copilot VSCode Chat pane.
Which means your average enterprise customer can’t actually get a good view of what’s behaving “agentically” on their staff members’ behalf.
Over a year ago in May 2025, I didn’t write my “securing authenticated agentic AI” post about the kinds of computer processes Microsoft 365 seems to be considering “agents” – I wrote it the moment it hit me just how bad of “lethal trifecta” trouble everyday corporate-employee software developers could get themselves into with the GitHub Copilot VSCode Chat pane, their usual enterprise productivity SaaS accounts like email or JIRA, and an MCP server logged into those accounts.
While I was thinking about data integrity’s resistance to malice, George Fletcher, an identity specialist, gave a great example of the need for data integrity in the face of mistakes, in his June 2026 article “The Authorization Problem We Keep Half-Solving:”
I want to start by considering the following hypothetical. Alice asked her AI travel assistant to book a long weekend in Lisbon for her and her husband. Flights, a hotel near Alfama, a dinner reservation on Saturday night, a rental car for a day trip to Sintra.
Imagine it works. Mostly. The hotel booking goes through. The flight doesn’t, because the airline’s website rejects the agent’s session as “unrecognized device.” The restaurant reservation lands at the wrong restaurant (a similarly named place across town), and there’s no clean way to know whether the agent has exceeded Alice’s budget along the way, because no one has actually told it what its budget is. Alice just said “book us a nice weekend.” The agent inferred the rest.
I can’t remember where, but people followed up with all sorts of interesting comments and quote-posts, including, for example, the idea that when figuring out how we got to a point where suddenly Alice has overdraft fees in her bank account, 2 nonrefundable tickets to the north side of Portugal and no car booking yet a weekend’s nonrefundable reservation at the most expensive middle-of-nowhere boutique B&B on the south side of Portugal, there’s a ton of stuff besides “it was this agent” and “it was Alice’s account” that would be helpful during root cause analysis to have logged.
For example:
nice” should trump other things, like Alice’s actual funds left? For example:
Unfortunately for Microsoft’s enterprise customers, there’s nothing about this Portugal nightmare that needs Alice’s “AI travel assistant” to be whatever it is that M365 might have decided “counts” as “an agent.”
Alice’s Portugal disaster totally could’ve happened through a basic desktop productivity tool like GitHub Copilot!
In other words, Microsoft’s omission of GitHub Copilot and its variants from the M365 Agent Registry’s listing of “Microsoft-authored” agents means that enterprise customers aren’t actually getting the observability into threats that Microsoft leadership is going around on podcasts promising M365 Agent Registry provides.
Yikes.
As Vince pointed out on episode 64 this weekend, the “lobsters” / “claws” as in “OpenClaw” proved to Microsoft’s leadership that they needed to avoid thinking of “agents” as services that only execute on servers that are remote to Alice.
But I challenge Vince and his colleagues at Microsoft to keep going. I challenge Microsoft’s leadership to stop thinking of “agents” as compute processes that only begin execution in response to events that happen when a human has long since walked away from the machine on which the agent is executing (e.g. a scheduled operating system task waking OpenClaw back up to re-check flight prices, because an earlier run of OpenClaw decided it seemed like a good idea to schedule that task).
Hyperscaler product managers, please pay attention: even a highly interactive desktop client chat UI “tool” like the GitHub Copilot CLI or the GitHub Copilot VSCode chat panel can, with Alice sitting right there patiently sipping coffee and waiting for the chat prompt’s “send” button to stop spinning, book the wrong trip to Portugal. And your enterprise customers need to know that when they look through products like M365 Agent Registry – that’s precisely what they turn to M365 Agent Registry to learn.
GenAI “tools” can behave agenticALLY (even at their most basic, the IDEs write content to OS files!), which means they 100% belong listed in “agent registries.” They are 100% part of what your enterprise leadership want to sleep well at night knowing they learned about when they poke through an “agent registry” trying to observe the threat landscape.
I just learned that CloudFlare reported 57.5% of web traffic they screen coming from bots instead of humans, to which Curt Tigges commented:
“I think it’s worth distinguishing between ‘bots’ and ‘agents’; most bot traffic is definitely not agents, it’s (deterministic screen-scraping) scripts.”
But then CloudFlare’s CEO defended focusing on the supercategory, saying:
“Bot / Crawler / Agent are all synonyms depending on whether you want them to be a good or bad thing, normatively.”
I think we’ve got a similar thing going on here – this is not the time to be pedantic and miss out on exposing crucial business information because it “didn’t count.”
Yes, I understand that creating fine-grained taxonomies have their use in human thinking, I really do. (Heck, it’s the core of what George Fletcher tries to name in his followup post, “A Framework for Delegated Authorization.)
Yes, I get that there are times when it’s important to come up with names that break up the whole world of “LLM-driven software that can nondeterministically, at machine speed, cause ‘write’ side effects that might not have been the actual intention of whoever thought LLM-driven computation might be a great way to solve a given problem” along questions like:
But I don’t think this is one of those times.
Deciding which agentic-behavior-capable products authored by Microsoft belong in the “Microsoft-authored agents” section of the M365 registry has only one right answer to me – all of them.
Microsoft – call them all “agents,” because they can all, nondeterministically and at machine speed, drain a company bank account on booking the wrong nonrefundable trip to Portugal.
]]>I’m not sure how to feel about that. Lots of “lethal trifecta” (see Simon Willison’s blog) and “software supply chain security” (see Andrew Nesbitt’s blog) issues to be explored, that’s for sure.
Update: I got to have a great conversation with some other developers about the promises and threats of LLM GenAI-based approaches to troubleshooting operational issues.
First, I clarified:
“Like this?
- “Letting an LLM nondeterministically use its embedded powers of probability to decide amongst the following options for how a given error in CI/CD pipeline logs is best handled:
- by quietly running diagnostics and authoring a pull request and running regression tests against the pull request it just authored, vs.
- by Slack-pinging a repo owner
- “Rather than, say, hard-coding a deterministic rule of:
- if this error, and if repeated 5 times or more in 30 seconds,
- then Teams-ping a repo owner”
I pondered, about the idea of programming such things using English as a programming language:
“Yeah, I mean, probability-based approaches to troubleshooting have definitely existed as service operations techniques used for the last decade+ at adequate levels of scale.
“Having a bit of ‘machine learning’ helping constantly readjust the threshholds at which a questionably performing container in a Kubernetes cluster, for example, gets destroyed and recreated, rather than just setting and forgetting it at ‘XYZ must be <90%.’
“I think it was previously mostly seen at massive scale of service traffic, though, because programming older probability-based tools was a lot harder than writing plain English, so you had to have a bunch of data science PhDs embedded in the ops teams to get it to work right, or whatever.
“I suppose an advantage to having all of those probability and statistics PhDs running around, though, is that they’ve got that deep level of familiarity with when a nondeterministic probability-based solution ain’t the right solution.
“It’ll probably be both a blessing and a curse for it to be accessible to the rest of us to try to make that architectural/design decision, for any given solution implementation.”
I also think that as a culture, we haven’t yet latched onto widespread understanding of what it means to be deterministic vs. nondeterministic, so most of us tend to presume if it’s a computer, it behaves more or less deterministically, because that’s how they did behave for decades.
One person in the conversation had this absolute gem:
“‘AI’ appears to be reinventing people but worse.”
Speaking of trying to reinvent the human by using probability and statistics math, check out Chris Wiggins and Matthew Jones’s “How Data Happened: a History from the Age of Reason to the Age of Algorithms.” It turns out that “data-driven” decisionmaking about how to organize ourselves, as groups of people, is only about 500 years old. Before that, you had philosophers Aristotle and Machiavelli just arguing. (The book covers the ways in which it’s debatable whether data-driven decisionmaking is actually an improvement to human life. Which Annalee Newitz’s “Stories Are Weapons: Psychological Warfare and the American Mind” makes a great companion piece to, by the way – they both touch on early-20th-century American advertising’s impacts on the social sciences, and vice-versa.)
Also, remember:
(As I heard on, I believe it was the .NET Rocks podcast, once we know what it’s “for,” we instead give it a name like “machine learning,” “natural language processing,” “optical character recognition,” “automatic speech recognition,” “data mining,” “heuristic search,” etc. And then “AI” gets recycled to describe the next thing we don’t quite understand.)
We still don’t actually know everything about what LLM-based GenAI is and isn’t good at.
]]>While, for authN and authZ, I still love my old “E2E and Synthetic Testing Considered Harmful” advice, I’d also like to add on some supply chain compromise tips.
I’m probably not the best at this, but here are some quick wins I think I’ve collected so far about how to import SDKs and other open-source libraries/packages/modules/software/etc. onto your computer / into your codebases, in this Sha1-Hulud / package-registry native worm era.
While many SDKs are widely respected, their authors are not infallible or immune to phishing (nor are the authors of the SDKs upon which those widely respected SDKs, in turn, “transitively” depend – which could compromise the contents of various versions of widely-respected SDKs through a “supply chain worm” in the style of Sha1-Hulud).
Patching codebases to use the latest and greatest version numbers of widely-respected SDKs is generally desirable, because new releases typically offer security patches and improved features.
However, any given brand new version number for an SDK could, despite its authors’ best efforts, theoretically have been compromised and also contain malware.
Following tips below can, hopefully, reduce the probability of developer laptops, developer VDIs, enterprise servers, or enterprise CI/CD runtimes becoming infected by such malware.
If the programming language that a web developer is using offers the ability to import “during development only” SDKs separately from “necessary to make the web application run” SDKs, then SDKs should be imported using the “during development only” mechanism.
devDependencies, not dependencies, in the package.json file for a Node.js JavaScript codebase.Web developers should specify the exact intended version number (e.g. 1.2.3) of each SDK that they currently intend their source code to use, rather than specifying a range (e.g. 1.2.x or latest) of acceptable version numbers.
Many programming languages offer built-in helper tooling.
npm install and npm update commands offer a --save-exact option, in any of the following ways:
.npmrc configuration files that can be checked into version control so that no developer ever forgets to use the option inline, and.npmrc file, though as in package cooldown below, while it could help in a hurry, I don’t like the long-term maintainability of not saying what you mean & meaning what you say in source code itself.Important: Don’t forget that you probably have “auxiliary” dependencies (e.g. 3rd-party steps like actions/checkout that are found in your CI/CD pipeline’s scripting) that also need to start getting exact-version-number-pinned.
The specific versions of the SDKs used within a given codebase should be kept up-to-date and patched.
npm audit command.While it is crucial to keep SDK versions up-to-date, keeping them too up-to-date can be a problem in the era of widespread SDK supply chain compromises.
If their programming language allows it, web developers should strongly consider setting a “package cooldown” / “minimum release age” when patching SDK version numbers within their codebase.
As of mid-2026, recent “supply chain” compromises seem to be ending up removed from major package registries within a few hours to a few days, so while industry consensus might further change, a cool-off period of 7 days seems to be the generally recommended window before treating a recently-released SDK version number as “safe enough” to try installing.
Many programming languages offer built-in helper tooling.
npm install and npm update commands offer a --min-release-age=SOME_NUMBER option, in any of the following ways:
.npmrc configuration files that can be checked into version control so that no developer ever forgets to use the option inline, and.npmrc file.
npm_config_min_release_age environment variable whose value is set to, say, 7, could definitely help in a hurry – and then you can go back and do the more code-editing-intensive versions later.)
.npmrc files in the OS shell’s “working directory” from which the NPM CLI was invoked, then any per-OS-user-home-directory .npmrc file that might exist, then any “global” .npmrc file that might exist, and finally the NPM CLI’s installation’s built-in npmrc file – no preceding dot).ubuntu-latest runtime is, as of 7/14/26, still just Ubuntu 24 and, in turn, still just Node 10, which doesn’t know what the --min-relase-age flag even means (it came out in Node 11.10).
@actions/setup-node workflow to force installation of a more recent version of Node+NPM onto your ubuntu-latest runtime, your min-release-age settings are useless – yikes!
--before flag that’s actually just what’s under the hood of --min-release-age, but then you need to add code to do the math to get a timestamp to work with it, which is annoying, but anyway, right now, you either need to force ubuntu-latest to update NPM, or you need to compute a value and use --before, on 7/14/2026.)If your programming language doesn’t include package cooldown, please help by chiming in and complaining until it does:
extensions.autoUpdateDelay’s value should be an integer representing hours. Current default is just 2 hours, which personally I think is assuming superhuman speed of the VSCode Extension’s Marketplace team to get compromised extensions pulled down. I’d probably go for more like 3 or 7 days’ worth of hours, but even better, your company can pick a number greater than 2 and set it enterprise-wide, so let your leadership know.If their programming language allows it, web developers should generate, and check into source code version control history, “lock files” that specify exact version numbers not only for the web developers’ intended SDKs, but also exact version numbers for all of the “transitive dependencies” that those SDKs in turn depended upon, at the exact time that the developer generated such a “lock file.”
package-lock.json file into source code version control.If their programming language allows it, web developers should almost always install SDKs onto a machine by using a mechanism that installs them from the above “lock file.”
For example, as seen in OWASP’s NPM security cheat sheet, use Node.js JavaScript’s npm ci command, rather than the npm install (a.k.a. npm i) command.
dotnet restore** command, rather than some sort of installation/updating command.This is particularly important in the following contexts:
The only exception is when a web developer, on their laptop or VDI, is explicitly in the process of SDK version maintenance as mentioned in “frequent version number patching” above.
npm install or npm update (or for a .NET developer to run dotnet tool install or dotnet tool update or dotnet package add or dotnet package update).
--save-exact and --min-release-age options.package.json and package-lock.json for NodeJS/NPM) back into source code version control.Perhaps especially if your programming language doesn’t offer lockfiles (but arguably even if it does, just to get various programming languages’ lockfiles standardized into a single machine-readable format), consider also generating, and storing somewhere organized, a software bill of materials (“SBOM”), for each version-control commit of your codebase.
Be sure to include both:
package.json and package-lock.json if you are a Node.js JavaScript developer), andactions/checkout that are found in your CI/CD pipeline’s scripting).It probably doesn’t help you, the developer, much.
But when central IT comes knocking, asking if you got hit by the latest worm, being able to send them all SBOMs from all commits during that timeframe can probably help ease their worries.
Another benefit of checking a lockfile into your source code version control repository is that your programming language might offer a command for auditing whether any of your direct and transitive dependency versions have been published as already known to be malicious.
If you were to always (e.g. in your CI/CD, or out of habit on laptops) run such a command before running the command to install those packages onto the host machine, then you could pretty easily refuse to proceed to installation (e.g. npm ci or dotnet restore) if you found any alerts.
For example, you can run npm audit against a NodeJS codebase, or leverage automatic auditing of your .NET codebase, or run a third-party software composition analysis (“SCA”) tool against your codebase.
Such tooling will always work better if you’ve had the coding discipline to install dependencies only from lockfiles that are checked into version control.
Audit tooling probably won’t catch your random in-CI/CD-shell-script npm install @some-publisher/some-tool@1.2.3 invocation (and therefore they’ll miss the fact that version 1.2.3 of @some-publisher/some-tool resolved at runtime to a malicious version of @some-other-publisher/some-recently-hacked-tool!).
So, as mentioned under “installation from lockfiles” above, please avoid writing such inline installer invocations anymore, if you want to enjoy the full strength of programming languages’ built-in audit tools and 3rd-party SCA tools.
Another benefit of checking a lockfile into your source code version control repository is that your programming language might offer a command for verifying each direct and transitive dependency’s provenance.
If you were to always (e.g. in your CI/CD, or out of habit on laptops) run such a command before running the command to install those packages onto the host machine, then you could pretty easily refuse to proceed to installation if you found any alerts.
Whether this helps is hit or miss, but since it sometimes helps, it’s probably better than nothing:
npm audit signatures against a package-lock.json would’ve caught the malicious 1.14.1 version of axios in March 2026, giving you a chance to refuse to run npm ci, since the attackers only compromised Axios’s NPM account, not Axios’s GitHub account.npm audit signatures against a package-lock.json likely wouldn’t have caught July 2026’s malicious 6.13.5 version @asyncapi/specs and you likely would’ve blithely proceeded to run npm ci anyway, since the attackers seem to have compromised AsyncAPI’s GitHub account.If you’re following my advice to always install only from lockfiles (e.g. npm ci) except when explicitly deliberately in the middle of trying to generate/update a lockfile (e.g. with npm install, npm i, or npm update), never fear – you can still do provenance validation if your programming language lets you split apart lockfile updates from installation! You just have to break your work up into two parts. For example, NodeJS’s NPM has a --package-lock-only flag, so you might do a deliberate update like this:
npm update --package-lock-only to update the filesnpm audit to find out if there are security vulnerabilitiesnpm audit signatures to validate provenancenpm ci if everything went well in the previous 3 steps.If their programming language allows it, web developers should almost always install SDKs onto a machine using a mechanism that prevents the SDK installation process from running arbitrary scripts on that machine.
This is because execution of arbitrary scripts during SDK installation has been a major compromise vector in recent supply chain compromises such as Sha1-Hulud.
npm ci, npm install, and npm update commands all offer an --ignore-scripts option, in any of the following ways:
.npmrc configuration files that can be checked into version control so that no developer ever forgets to use the option inline, and.npmrc file, though as in package cooldown above, while it could help in a hurry, I don’t like the long-term maintainability of not saying what you mean & meaning what you say in source code itself.--ignore-scripts set to true by default, but it’s quite new, so you probably have to hand-upgrade all of your laptops, CI/CD pipelines, etc. to take advantage of that.)Specifically for build-time / test-time SDKs such as Playwright, clutter might accumulate that is undesirable.
The most common machine type in which an SDK such as Playwright would be installed and executed is a CI/CD pipeline. In the case of the built-in CI/CD runtimes that come with major cloud-based Git version control hosts, these machines are ephemeral and self-destruct the moment a CI/CD pipeline finishes executing, so no extra cleanup would be needed.
However, when a clutter-producing SDK such as Playwright is installed onto a long-lived machine such as a developer laptop, developer VDI, or enterprise-hosted CI/CD runtime, the following clutter can build up that would be wise (because, really, who wants extra .exe files sitting around ready for malware to latch onto and use against you?) to periodically delete altogether:
npx playwright uninstall --all command that cleans out copies of old web browser executables that previous Playwright runs had put into a Windows machine’s %LOCALAPPDATA%\ms-playwright folder (or a Linux machine’s ~/.cache/ms-playwright folder).Maybe run some CLI commands on your computer like aws logout or az logout, or something, before running any third-party SDKs (which, if you have VSCode extensions auto-updating, includes “before opening VSCode”).
That way, if you get infected, maybe you’ll notice that the malware is trying to query AWS for secrets and whatnot from your machine when it prompts you to log your CLI in or something.
OWASP’s GitHub Actions cheat sheet has a similar trick: explicitly set every single GitHub Actions YAML file you write to have permissions: {} (no permissions), rather than just leaving the permissions property out altogether, and see if it breaks, and then rebuild the permissions block’s values permission by permission (e.g. adding back content: "read" manually if your YAML file needs to run an actions/checkout step).
Following on that logout theme, here’s another idea: push your company’s leadership to adopt a “zero standing privileges” (“ZSP”) approach to granting human identities any access (“authorization” / “authZ”) to sensitive cloud resources.
For example, tell them that you don’t want your computer, while az login is active, able to run az keyvault secret show unless you, within the last few hours, have intentionally and manually engaged in a just-in-time (“JIT”) privilege escalation to activate your Key Vault Secrets User Azure RBAC Role Assignment against that particular Azure Key Vault. If someone granted you, or a group to which you belong, Key Vault Secrets User in “active” status rather than in “eligible” status, push for them to fix it and assign it as “eligible” instead.
Your company’s identity provider might even make it possible to do this for cloud secrets that live in non-hyperscaler-sized clouds. For example, even if Hashicorp Vault doesn’t have an option for requiring that you do JIT authZ escalation before performing vault kv get, perhaps it has an option for requiring that you be a member of a certain Microsoft Entra ID security group for vault kv get to work against a given secret. And guess what? Microsoft has options for your membership in Entra Security Groups to be “zero standing privilege,” and for you to have to JIT activate your membership in that group using Entra ID PIM! So, seriously – push your company to get creative.
Convenience and security are often at odds (if something is more convenient for you to do, it’s also more convenient for a virus that’s infected your computer to do as if it were you). Slow supply chain package worms like VSCode extension compromises down by making sure that your cloud accounts cannot, by default, perform sensitive actions. It’s a great compromise – adding an extra 2 minutes of inconvenience to the days in which you actually need to access a given cloud secret/certificate, so as to harden security for your computer on all the days you don’t.
This isn’t a particularly big ask, either. Companies don’t need to do this for all of the access you’ve ever been granted to any cloud resource. Just the particularly sensitive ones that these kinds of supply chain worms target, like reading secrets out of AWS Secrets Manager, AWS KMS, AWS ACM, Azure Key Vault, GCP Secret Manager, GCP KMS, or GCP Certificate Manager.
An ounce of prevention is worth a pound of cure, and retrofitting humans’ existing sensitive authZ grants to ZSP can massively stop the bleeding when – not if – your “endpoint” (laptop, virtual desktop infrastructure (“VDI”), etc.) gets infected by a supply chain worm.
At the very least, push hard for your company to, going forward, issue new sensitive authZ grants in a ZSP approach.
Tomas Listiak’s “How to safely approach a JavaScript interview test project” takes “reduce clutter” to the extreme and focuses a lot on following the sort of “burner phone” approaches to running strange code that I’ve seen security researchers adopt for years (I get the impression they’re constantly reimaging their laptops and possibly even changing out hard drives altogether).
The cloud industry has spent more than a decade optimizing for developer velocity. We made dependency installation fast. We made CI/CD pipelines automatic. We made SaaS build platforms beautifully simple. We taught ourselves to trust registries because the alternative was slow, manual, and socially unpopular.
Mini Shai-Hulud is not the end of that model. It is the invoice.
The convenience of
npm installis not free. It is a line of credit against your security posture, and the interest rate just went up.This does not mean we should retreat into caves and compile everything by candlelight, although some incident response teams have looked into it. It means we need to stop treating dependency installation as a harmless clerical step. It is code execution. It happens early. It happens often. It happens in places where secrets live.
/rubber-duck mode this morning and was not impressed, but I think that’s because I already word most of my prompts in rubber-duck “change my mind” fashion.Copilot said that rubber duck mode:
“is purpose-built for adversarial critique – explicitly tuned to find bugs, logic errors, and design flaws – and explicitly not to comment on style, formatting, or other trivial things.”
Whereas it said ask mode:
“answers whatever you ask, in whatever tone you set; no special ‘adversarial’ framing – it’ll critique if you ask, but it may also compliment, hedge, or drift into style suggestions.”
Got it. So … rubber-duck mode is just letting me write your “ask-mode” prompts.
Seriously, here are some quotes pulled straight from one of my recent chats with an LLM in “ask mode:”
“Same question, but now with me clarifying to you: I meant around (name-of-system) modernization, specifically.”
“In your response to my last prompt, you wrote both of these two quotes:
- ”‘(censored; private)’
- ”‘(also censored; private)’
“Are these two quotes referring to the same thing or different?”
“If (censored; private) modernizes (name-of-system) as planned, what do you think (also censored; private) will turn all these old (name-of-other system) apps into instead (or, alternatively, why would they deprecate them altogether)? What would (also censored; private) likely replace them with, if anything?”
“Yes, go ahead and tell me about the published modernization roadmaps. Only about the actual coming (censored; private), though, not looking back at the (also censored; private).”
“If you had tons of (censored; private) to squander … which parts of the modernization roadmaps you just told me about would you consider such practices optimized to accelerate versus a potential time-wasting distraction?”
“Same question, except now imagine that the (censored; private) modernization ain’t going so hot and you work for (also censored; private) and are still stuck on (name-of-other-system) strangler fig best efforts and whatnot for a few years longer than expected. But you are now the one with all the (yes, also censored; private). Same question about which parts of your responsibilities benefit versus are wasted with such resources.”
“But,” “or,” “if,” “though,” “versus,” “except” – I kid you not, in a 12-prompt chat transcript, I jumped into the middle, looked at 8, and that’s what I see in 6 of those 8. I rubber duck the world as a matter of personality. 🤣
I think this harnessing of doubt is why I feel pretty satisfied with my results when I prompt LLMs, which are, mathematically under the hood, sycophantic because their math is about “next-token prediction” (not “next if there is a next” – just “next”). My animal neurons’ parallel algorithms for doubt is how I add the “if there is a next” and steer it as best I can.
I heard an NPR broadcast this winter with the following amazing quotes on the value of doubt:
Winthrop says that if children are building social-emotional skills largely through interactions with chatbots that were designed to agree with them, “it becomes very uncomfortable to then be in an environment when somebody doesn’t agree with you.”
Winthrop offers an example of a child interacting with a chatbot, “complaining about your parents and saying, ‘They want me to wash the dishes — this is so annoying. I hate my parents.’ The chatbot will likely say, ‘You’re right. You’re misunderstood. I’m so sorry. I understand you.’ Versus a friend who would say, ‘Dude, I wash the dishes all the time in my house. I don’t know what you’re complaining about. That’s normal.’ That right there is the problem.”
A (report accompanying a) recent survey from the Center for Democracy and Technology, a nonprofit that advocates for civil rights and civil liberties in the digital age, … warns that AI’s echo chamber can stunt a child’s emotional growth: “We learn empathy not when we are perfectly understood, but when we misunderstand and recover,” one of the surveyed experts said.
A friend once showed me his LLM chat logs trying to sentiment-analyze another acquaintance’s text messages, after I disagreed that the messages seemed as worrisome as my friend feared. Sure enough, I noticed that we had completely different LLM-prompting styles.
My friend basically asked the LLM:
“Do these texts mean what I think they mean? It seems like this person is saying X.”
Whereas in his shoes, (after censoring and rewriting the texts, for good measure, because blegh, even starting afresh every time in incognito mode, these things are probably already building enough of a profile on me by IP address and device fingerprint), I imagine I would’ve prompted the LLM:
“My brain’s over-loaded fearing these texts mean this person is saying X, but that’s probably just my human-brain hardwired negativity bias. Sanity-check me, please – what other possibilities might it be reasonable to read into these texts?”
After seeing that not everyone intuitively rubber-ducks LLM chatbots the way I do, I’ve definitely started asking for more context about what prompts were, now, if peers tell me their position I disagree with has been influenced by a conversation w/ an LLM, and reminding them that they’re next-token-prediction machines.
I try to help people enjoy their LLM-assisted lives more by reminding them that working with LLMs is very “garbage in, garbage out.”
That specifically, you have to work hard to be adversarial.
That you have to exaggerate doubt if you want to get anything actually-useful out of them.
Fascinating that /rubber-duck mode basically just helps scale up … me. 😉
I realized I already covered a lot of what I want to say to Scott in “A related problem: what actually is second-guessing?” in my “Music, bird brains and LLM math” post 2 months ago.
Animal brains are made of so much more more than “next-sense-datum prediction,” even while that is definitely an important part of animal brains (possibly related to birdsong).
Perhaps, as Scott guesses, we’ll mathematically imitate another part of animal brains in 9-16 years. Maybe it’ll be that round in which we find out what doubt is made of.
Maybe.
I have my doubts.
#OSSSummit talk, (#OSSHomework!), here are my conference highlights from the Linux Foundation’s Open Source Summit and the CNCF’s Observability Summit. Still a work in progress; keep refreshing through next week until I get a chance to fully fill it in.
Be sure to catch my talks!
Jim Zemlin gave the opening remarks keynote.
Lots of polling “how many of you…?” like I learned recently from Bill Hoogterp’s “Your Perfect Presentation.”
Dad jokes about his family in attendance, which, yay, was totally already happening in my talk’s speaker notes, thanks for warming it up.
Open source let the world optimize kernel performance together.
“Frontier” open-weight LLM models thus far are from abroad, though expect a US one this year.
Exponentially growing commits, since about May 2025. (Actually, now that I think about it, me too – a lot of the reason my GitHub repository count has been exploding exponentially, besides changing into a more dilletante-oriented consulting job description, is that LLMs expedited my learning in those gigs, so I’ve suddenly got a lot more to publish about what I’m learning.)
Ay yi yi, more Tayloristic labor value extraction from its producers toward people who already have more money than they could ever need simply to be human (e.g. put food on the table and relax with loved ones). I mean, this quote from the Linux Foundation’s 2026 State of Tech Talent Report sounds great, right?
To bridge these full-stack and operational gaps, organizations prefer to look to their internal staff. Upskilling and cross-skilling existing staff is the top strategy (57%), favored over external hiring (49%). This approach offers major advantages in preserving institutional knowledge and is strongly preferred for understanding business context (7.9x) and staff retention (7.7x). Hiring externally, by contrast, is slower and riskier: new hires take 53% longer to reach productivity, and 28% resign within six months. Overall, the findings suggest that technical professionals value learning and development at least as highly as compensation when deciding whether to stay.
On the surface, I agree with this 1000% and want to say, “FINALLY!” But think about how incessantly extractively underpaid internal advancement has been, compared to what companies offer external hires, for the last half-century in America. No one keeps up with the rising cost of living except by job-hopping. As HackerNews commenter OtherShrezzing wrote last week:
“If you’re 10x more productive, someone (should be) willing to pay you 10x as much as they were last year, because you’re producing 10x as much value as before. Has your salary increased 10x?”
There’s a bit of hope, though – if Jim is right that only business context / domain experts – not external hires – even CAN properly prioritize the backlog of valuable things that can suddenly be built – well, then, now we’re talking about a situation in which underpaid employees hold all the power, and can fix the imbalance of who takes home all the spare cash from that extra value that they created, as long as they organize appropriately. As Jim said:
“Attackers are organized, well-funded, and using AI today. Defenders are larger but fragmented. Fragmentation is the bug we can fix in this room.”
I know he said that about getting companies to organize themselves (e.g. 20% tech debt Thursdays) to actually take the time to use AI coding assistant tools to, for example, write the danged tests.
I know he wasn’t talking about reducing human suffering.
But it’s the same thing, if you ask me.
When we cognitively overwork staff, we are losing the JUDGMENT that can only come from proper REST (which includes the rest you get, off the clock, by having adequate salary to not spend those hours between work and sleep insanely stressed out over money). Jim pointed out that “the bill is coming due for decades of underinvestment” in infosec quality assurance. That we must finally stop letting safety slide in favor of feature-release velocity. Well, guess what, everybody? Just like all-feature, no-tech-debt schedules (whose companies actually gave every last engineer protected 20% time – “Tech Debt Thursdays” – for the last 30 years? Not mine) squandered opportunities to focus on security quality that now we’re paying for in the form of Sha1-Hulud and Axios, so too would cognitively overworking staff squander their precious JUDGMENT by preventing them from being well-rested enough to bring it to the table. (Maybe you can “10x” them somehow, but they’re gonna show up robotic, not with the full judgment that is internal employees’ true strength.)
Labor rights are an infosec issue. Taylorism is an “externalized/socialized cost; privatized profit” problem. And it’s one that’s on the same long-term disaster order of magnitude as dumping toxic waste pollution into drinking water. The externalized/socialized cost is that we ordinary people are going to seriously suffer if power grids go down on account of poorly-cleaned-up security technical debt. And we, as humans organized into companies, can’t clean up our security technical debt unless we leverage internal employees’ expertise, which means internal employees need to be well-rested, which means we need to pay internal employees appropriately for all of this feature-value and tech-debt-cost-savings they’re producing once you put AI coding assistant tools into their skilled hands.
From “The Exploit of Trust: Securing the Open Source Supply Chain” by Kadi McKean”.
Apparently Sha1-Hulud wasn’t just a catchy name, but the first of its kind (a self-replicating package-registry-native worm).
(My note: so if it feels like the world changed last fall … yes. It did.)
One reason supply chain compromises are hitting NPM so hard is that NodeJS is the programming language behind accounts for a massive percentage the open-source packages whose source code lives on GitHub.com, period.
The TruffleHog package used by the Sha1-Hulud worm to find, test, and exfiltrate secrets is actually usually used as a “blue-team” security tool that, despite perhaps its bad reputation as part of the worm, enterprises might want to look into using more often. It seems to be equivalent to GitHub Secrets Scanning, but free and open-source. Meant to let developers security-scan their own code as part of automated QA tests.
She says developer education is perennially a must-do part of security strategies, even if “educate and pray” can’t alone be the only guardrail.
The US government’s National Institutes for Standards and Technology’s (NIST’s) National Vulnerability Database (NVD) is dropping in utility as a one-stop shop for CVE announcements. The US’s CISA agency beat them on some important stuff last year. Some not-in-English CVE vulnerability numbering authorities are also doing a great job and maybe worth watching these days.
See if you can start security-scanning VSCode extensions for malware. Check if things like CrowdStrike already do that or not?
(My note later: I sure wish VSCode had a “minimum release age” on its extensions auto-update. It seems I’m not alone: 1 from 2019, 2 from October 2025, 3, 4, 5.)
She said starting immediately, developers need to:
SBoM, AIBOM, MLBom, CryptogrophyBOM – lots of “bill of materials” formats exist for making it easy for this information to be machine-analyzableCheck out the OpenSSF’s SLSA framework.
From “Lightning Talk: SSDF Is Not a Checklist: Turning Tasks Into CI/CD Automation” by Tracy Ragan.
Adoption of a lot of things that can help with automation of supply chain scanning are currently a royal pain to install and configure and maintain.
Everyone’s working on paving usability roads, but don’t go into it expecting a paved road yet.
From Mihir Vora & Prem Dhayalan’s “Ending the ‘Glue Code’ Tax on Engineering Velocity” lightning talk.
Although spinning up a pub-sub events message broker to stand in the middle of a CDEvents flow is easy (all the hyperscalers offer them), there’s still sadly little vendor support for publishing CDEvents or subscribing to / consuming CDEvents.
Q&A: a guy in the audience pointed out that he’s seen SBOM files upwards of 50MB large, so he’s not sure if you would always want to include a full SBOM in the body of a CDEvents message.
Clever use of CDEvents for infosec observability – I think it was in this session that a speaker pointed out that:
From the Q&A after “Lightning Talk: CI/CD Cybersecurity Guide - Open Source Tools to Improve DevOps Security” by Kate Scarcella.
There was an interesting question from the audience more or less asking, “For decades I’ve been told feature velocity rules all. Do I really have to decrease feature velocity just because it’s 2026? I’m not exactly in life-critical / safety-critical systems!”
(I forgot Ms. Scarcella’s answer, but I believe it was some variant of “yes,” echoing what Jim Zemlin said in the opening keynote.)
From Jennifer Mulford’s AI in CI/CD Without the Hype: Practical Patterns for Platform Engineers.
I’ll be bookmarking this recording and handing it out like candy to leadership and engineers alike when I repeatedly say “I’m not saying you can’t let nondeterministic machines do important things, but I am saying you can’t do it YOLO-style. See Ms. Mulford’s approach; she said it best.”
LLM agents are like someone capable but new. And because they run on next-word-prediction probability mathematics, they will always be a “yes machine.” And because they run on electrified sand, not brain tissue, they won’t ever gain the constraints of “aversion” and “doubt” that animals learn from reward, experience, etc. Unlike a new employee, mathematically, they’re not capable of gaining “hard-won experience” over time about what’s sacred, what’s brittle, what’s dangerous, etc.
Next-word-prediction probability mathematics inherently is oppositional to “doubt” – again, the “yes machine” algorithm under the surface is just sorta built into the math of how they work. Which means they do confident wrong answers. There can be serious harm, and at the very least, the minor harm of wasted time.
CI/CD is usually about high-consistency needs. We’re not talking about misspelling “you’re” in an email when you should’ve said “your.” CI/CD usually implies high consequences for failure / wrongness. So it’s kinda inherently a terrible place to run a nondeterministic probability-based machine.
Some patterns and guardrails that can help are, like with new human approvals, just-in-time authZ, approvals (e.g. CI/CD pipeline steps requiring human approval to proceed), monitoring, etc.
Airplane autopilot mode exists because we, as a populace, decided to monitor, test, etc. the heck out of it for decades. (And still even then, we have humans as the final decider! The machine is just an emplifier/expediter.)
Obvious patterns of things LLMs are great at, though, tend to be read-only and extremely language-heavy (LLM stands for large language model, after all):
Reminds me of the person I knew who was an intern for a state governor. Every morning, they were part of a team that read all of the newspapers from dozens of towns all around the state, circling passages the governor needed to read when she arrived at 8AM so she could be ready for 9AM calls. At no point was the intern doing … governing. They were just someone who got newspaper-summarization delegated to them. They did not, at any point, ever get put in charge of personally signing or vetoing things passed by the legislature, despite how much of the governor’s “job” they otherwise helped the governor do effectively.
In fact, this “read-only, language-intensive” governor’s-intern model of AI use is how the good guys caught the Axios hack so fast (hours, I think she saidd). Someone had built an LLM-based tool that helped them comb codebases that their codebase uses for source code diffs, looking for stuff that seems out of place, and it worked!
Aside: she reminded us that there wasn’t even anything wrong with plan-crypto-js or axios before the hack. It’s not like those maintainers were writing sloppy software before the hack. It got hacked and transformed into bad code through the human angle, not through a vulnerability in the codebase. I can’t remember how this was relevant, but it was interesting.
Main takeaway: for heaven’s sake, please please please do read-only first when you roll out AI agents. DO NOT RUSH INTO WRITE.
And also, please don’t rush into overeager read. Start by just describing small self-censored snippets of problems within individual chat session prompts; don’t just give the chatbot read access over HTTPS into your whole Atlassian Confluence Wiki about all of your architecture secrets. It’s hard to put that data-exfiltration/leak genie back in the bottle; start by simply not opening it in the first place.
“Earning trust:” LLMs are typically start-over sessions, an audience member pointed out that they … don’t..
(Even machine learning algorithms and other forms of “AI” also perhaps don’t 100%, because probability-math still, and can perhaps drift into unreasonable corners.)
Deterministic harnesses wrapped around AI, though, perhaps can. But the LLM-based tools themselves can’t “earn” trust the way a human-animal intern can. They’re pre-trained next-word-prediction equations that are terrible at doubt; their underlying math simply isn’t meant to fully imitate all of the various processes involved in brain-tissue-based “learning” that goes on in animals.
She replied pointing out, though, that trust can kind of flow in the opposite direction. You can earn trust in your human self to learn what your LLM-based tool is pretty good at (e.g. read-only low-consequence-if-failed language-heavy tasks) and what they seem to be lousy at. (She also pointed out that this is an important reason to have senior/experienced staff overlooking the AI, not just junior human staff!)
She said to do lots of observability. I’m looking forward to the #O11ySummit to learn more about what “table stakes” for monitoring an AI agent are.
An adventure in what you can build when you’ve been an “AI” company for decades and your leadership goes “Oh, again?” and treats building internal platforms to govern the latest hype as just another Tuesday that needs a two-pizza team.
I was already aware that API gateways like Azure API Management (“APIM”) can be used to clean up lousy APIs’ behavior – e.g. rewriting headers, adding rate-limiting, cleaning up insufficient authentication/authorization granularity/modernity, etc. It hadn’t occurred to me, though, that when I was underwhelmed by the authN/authZ granularity built into a given vendor’s “MCP server,” I could treat it the same way, insisting upon adding my own wrapper-layer of “no, THIS is how you shoulda exposed it to clients.” Neat. Their wrapper came with a dashboard, too, which included not just a configuration panel, but also a small test environment harness (chat panel) for validating whether your configuration settings were working as intended (e.g. “Hey Siri, give me all the social security numbers” -> “I can’t do that, Dave”), and some monitoring of how use was actually going. Very APIM-like, just with a nondeterministic tool as the client instead of curl as the client. Neat.
Heyoooooo, Ms. Buzek mentioned the lethal trifecta! Can we be conference best friends?
She was definitely my role model for “voice” as a technical public speaker. Great blend of deep-dive face-in-a-screen nerdiness and strong-voiced audience engagement.
Vocab: MCP helps in “context exchange.”
Their idea of “observability” that they focused on building into their UI was not so much classic OTel-ish stuff as business-level “admin panel” stuff.
From “Small Government, Big Problems: Utilizing OSS To Support Our Citizens” by Bob Henderson.
As a citizen of many governments, it was fun to get to see a talk about how their IT departments keep life running for folks like me.
An interesting problem for sparsely-populated, large-terrain governments like North Dakota is that it’s hard to find enough money to pay someone educated enough in IT to be hireable in a city to settle in a harsh climate with long travel required to not only fun, but also healthcare, etc. It can particularly lead to far-flung counties relying on the region’s only population center (e.g. the state capital / largest city/county) for remote IT support. Surprisingly, the influx of oil wealth out west didn’t help – it made the problem worse. (IT folks already willing to live there could get paid double to work in new filthy-rich private-sector IT jobs that had just come to town and thereby stabilize their family’s financial security, instead of continuing to work for their local government’s IT department.)
Standards and conventions matter a lot when you have the entire spectrum of humanity and all of the different types of jobs that serve it as your “customers,” and when you’re already understaffed. Programmers sometimes roll their eyes at PDF, but it’s a heck of a lot faster way to be capable of reading a copy of someone’s dataset than first having to obtain a Crystal Reports account and install it onto your desktop.
As some general themes:
Government seems to have very little middle-ground employment turnover. High-flyers straight out of college either leave within 18 months or settle in for life because they’re committed to the cause of serving the people. But those who stay for life have to figure out work-life balance on decades of underpayment and hence financial insecurity, which, as I mentioned above, can make life outside of “work” an awful lot of work, so they often find themselves reacting to their commitment’s strict cap on financial security / earning potential by similarly capping/plateauing just how much stress they’re comfortable taking on during those 40 hours a week. They tend to have an ultra-reliable work ethic and floor of skill/output, but it can be hard to get the enterprise’s ceiling to lift “at work” when folks are already a little overtaxed by financial stressors “at home.”
When designing application user experiences, remember that every configuration option you offer is not only a decision, but a failure point risk.
From “Keynote: Linus Torvalds in Conversation with Dirk Hohndel”.
Challenges with keeping up with the updates the Linux kernel needs:
Etiquette suggestion: “If you found a bug with AI, assume others did too.” (And don’t spam maintaners unnecessarily.)
Etiquette suggestion: Be a whitehat-type, not an ego, when you discover how to cause misery for some victim on a Friday afternoon.
Etiquette suggestion: “Heartbleed” was the first big “branded” bug with a name and a website. These kinds of fame-seeking / employment-seeking ones seem to often correlate with insufficient advance disclosure. Please don’t.
The Linux kernel has 35 years of code and about 35 million lines of code piled up. So it gets bug reports daily – there’s no way a codebase that big is bug-free.
LLMs have enabled reverse-engineering bugs from fixes. This has recently killed the legacy “security through obscurity” approach to quietly getting patches into Linux distributions without people quite realizing what was wrong. Sadly, we just have to deal with that reality, now. That a security blog, trying to be first to press, will have reverse-engineered, and be talking about, the root issue within hours of a fix getting proposed.
Still, remember that LLMs can also reverse-engineer closed-source application behavior and release note changes, so keep using open-source, he suggested!
Dirk seemed frustrated that these press-and-attention-seekers all mostly seem to “find” rather than “fix.” Linus replied that, to be fair, “finding” is often a lot easier than fixing. However, Linus expressed frustration with all of this fun-and-games-with-LLM bug-hunting leading to “drive-by” reports of issues without assuming the responsibility to bother to circle back to reply if the maintainer asks a followup question.
Linus hopes that while we’re in a ton of short-term pain right now, hopefully all of the AI-assisted long-term fixing will eventually lead to hardened open-source software that will get a little relief from the currend deluge.
But open-source software maintainers were already burning out from overwork before LLMs, and now it’s gotten to “OMG” levels of burnout risk / actuality. Every Linux kernel release has over 1,000 people involved, containing a solid cadre of usually-well-paid maintainers. But tens of thousands of random projects are not so lucky as the Linux kernel that way.
Linus doesn’t really code – he more works with people – and doesn’t particularly like using AI for “people work.” But he’s seen people use an LLM-based tool from Google to review what’s going on in mailing lists and thinks that’s neat.
It’s estimated that there are hundreds of millions of open-source projects on GitHub.com, about hundreds of thousands of which are critical to enterprises.
Try using a local LLM for productivity tasks. Many Linux kernel developers are enjoying using them.
“99% of our lines of code are written by LLMs” sounds as silly to brag about as what’s equally true of all software written in higher-level programming languages: “100% of our lines of code are written by compilers and assemblers.” Stop. It’s still humans causing coding to happen; you sound ridiculous.
This was a good reminder that while most keynotes are TED-talk-ey (I read a book about public speaking, as I prepared for my own talks, that pointed out they often even tell a story from childhood as an opener, because they’re supposed to help change how you think rather than what you know), you can still occasionally get onto the mainstage with a solid code demo. Fun!
“Provenance guarding” – trying to avoid accepting volunteer “coders’” pull requests that are just plagiarized from competitors. (Ay yi yi, I had no idea LLMs had scaled up that, too – I thought it was mostly in school settings that that was a UX problem!)
Yes, these speakers are amongst the maintainers burning out in today’s environment. It seems related to expectations – ones that exceed reasonable human scale.
Even for paid-to-maintain-as-a-day-job maintainers like them, getting launches to happen ends up bleeding out of “working hours” into personal life because the volume is so insanely high. They couldn’t even attend this conference without having to shepherd a release along right before getting a big moment going on stage.
From “Keynote: Zephyr: By Developers, For Developers” by Kate Stewart.
I texted my product manager friend: “The founder of a featured software project is keynoting, and I’m blown away by how much glue work and product management is fundamental to the speaker’s story of success over alternative products.”
(I’ll leave my sociopolitical observations about who just so happens to be retelling a story about something that was only achieved through a lot of “glue work” in my private diary – but you can go see Denise Yu’s original post on the topic if you want to guess. 😉)
Also, Jim Zemlin emceed today instead of speaking, and it was fun to get to see one person to both types of “public speaking.” Very “recitation acting vs. improv.” Fun for me, as I look to others for inspiration about the many forms “public speaking” takes.
From “Keynote: Free to Use, Not Free to Run: Reinventing Package Registries” by Robin Bender Ginn.
We just assume package registraties will “be there,” but the modern open-source software supply chain is nothing short of the same kind of miracle as “free overnight shipping.”
The NPM package “Express” (heck, which was featured in my talk) gets downloaded 1 million times a day. That’s some seriously delivery infrastructure!
Package consumption has exploded as transitive adoption (e.g. Express, Lodash) has expanded. This is straining the servers and the maintainers who try to code them well enough to keep them online.
The CI/CD automation movement really taxed package registries’ loads.
Etiquette tip: If you can internally mirror registries, that’d be lovely. One enterprises’s default configuration for its Apache Spark clusters happened to be triggering 80,000 redundant Maven artifact downloads per week, for example. If you wanna program things inefficiently, please do it against your own infrastructure if you could?
Eclipse’s OpenVSX throttled consumption, requiring pay-to-download for commercial platforms.
Etiquitte tip: Talk your boss into donating to the OpenJS Foundation and other foundations supporting package registry (e.g. NPM, PyPi, MavenCentral, etc.) maintainers. They’re pretty underfunded compared to open-source software developers, and they have higher costs because they have to actually run servers/services/infrastructure to help us all out, and everything’s gonna fall apart or go behind pay-to-download walls if we don’t.
Robin was a good role model for “voice” as a TED-talk-mood speaker.
I’m not naming names, but it cracked me up that in the lunchroom, I witnessed some attendees rolling their eyes at what an unmoving personality-conflict disaster a certain standards initiative was, and possibly doomed to failure in the long term on account of it, only to hear it celebrated in a session this week as a miraculous cornerstone of productivity.
So either the standard is already more feature-complete than those eye-rollers gave everyone credit for, or it’s just the most perfect darned illustration of the exact “some person in Nebraska” brittleness Robin was talking about (chef’s kiss).
From “Beyond Containers. Why MicroVMs Are Essential for Multi-Tenant Workloads” by Alex Zenla.
Edera (a vendor) argued that:
What makes a VM “micro?” Just-enough CPU, RAM, etc. allocated to it, of course, but that’s just sane VM provisioning, so that’s not really it. What makes it a “micro-VM” is that the distribution of the operating system the micro-VM runs is just the OS kernel plus your application. It’s a VM that doesn’t bother to run the full OS, or to try to virtualize hardware that isn’t even likely attached to underlying bare metal (e.g. an IDE port) and that certainly your application isn’t expecting to need, in contrast to a general-purpose virtualization-ready OS’s kitchen-sink just-in-case inclusion of drivers, etc.
Edera sells some sort of tool that fits somewhere kind of between what Podman or Kubernetes does, and what VMWare or other hypervisors do. It makes sure each container ends up wrapped in an appropriately small VM.
That said, a common problem with rolling your own micro-VM management (and another part of what Edera’s product tries to tackle fixing for you, with features like the “Edera Root Zone Mechanism”, or Edera-Falco integrations) is that a lot of adjacently-installed-container tools expect the very kind of bleedover that presents a security threat. For example, “lots of Kubernetes tools like to run in host namespaces” and “eBPF doesn’t work out of the box with multiple VMs.” See the “The Non-Obvious Things” slide when recordings go up.
Drivers for GPUs often crash things (not sure if my notes meant to say containers or VMs), or are big vulnerabilities, because GPUs weren’t designed from the ground up to secure running general computation applications. Only to put pixels on a monitor. Apparently, therefore, limiting the blast zone of such crashes to a micro-VM can also help with reliability; this isn’t a pure security concept. Although also, they tend to be terrible at the “multi-tenancy by politeness” thing for the same reason – GPUs just don’t have the same sanity-checking built in, at a hardware level, as a CPU.
A lot of the history behind the whole “treat a container like a smaller VM – it’s ‘virtualization’ without having to deal with ‘VIRTUALIZATION’” trend came about when VM management tools (e.g. VMWare) seemed way heavier-weight than they are today. (But it sorta turned into “multi-tenancy by politeness,” not “multi-tenancy by actually a good idea.”) VMs as a concept aren’t fundamentally heavyweight, but a lot of tools and OS distributions tend to make them so, by trying to emulate so much hardware.
From “OCI Images: Not Just for Containers Anymore” by Austin Abro.
They demonstrated wrapping a folder of 5 .png files into an Open Container Initiative (OCI) image.
I wish that hyperscalers would simply improve provenance for their PaaS offerings, but failing that, I wonder if some sort of OCI package registry, GitHub Packages could, to ZIP files attached to “release” tags, for output of npm run build-type webapp payloads before throwing them over the fence into, say, a hyperscaler PaaS like AWS Elastic Beanstalk / Azure App Service / GCP App Engine. Maybe also colocating the dist output of npm run build alongside its source code and/or SBOM?
Another “public speaking” role model. This talk was all-ridealong, little-TED-vibes, but the material was crucial, so it works! Worth remembering as I try to come up with good “code on the screen” content for VBrownBag in October.
From “Is Maven Safe for Production?” by Adam Kaplan & Manfred Moser.
I’ll be bookmarking this recording and handing it, too, to leadership, and to people who aren’t developers (whom I want to convince to begin new supply chain hardening initiatives), because it included the best definition of the package manager I’ve ever heard. Was the voiceover for the “ingredients’ & “plugins” & “extensions” slide; will need to wait for the recording to come out.
Generally, the way Java does package namespacing (its reliance on reverse domain names made it easy for MavenCentral to just say “okay, cool, prove you have control of that domain name before we let you publish as it”), and some choices made by MavenCentral from the get-go as compared to NPM, have positioned the Java dependencies ecosystem to get hit a little less onslaughtily than the NodeJS dependencies ecosystem thus far.
(My comment: sounds like the takeaway is: it’s not perfect, but it’s perhaps been a bit of an “I don’t have to outrun the bear, I just have to outrun you” slower ramp-up of attacks, giving Java SDK developers/consumers a little bit more breathing room than NodeJS SDK developers/consumers to catch up on SBOM generation and all that?)
The Maven talk’s slides include handy command-line commands for generating an SBOM about your Java project’s Maven dependencies, and for, as best you can, trying to generate one also for its “plugin” and “extension” calls.
Also, the slide titled “source track” is a great overview of 4 threat vector classes and their corresponding 4 mitigation classes.
If you want to get involved in shaping the direction of OpenSSF’s SLSA, join the OpenSSF Slack and look for the “Dependency” standards committee channel, or something like that.
A “dependency inventory” is the jargon for what a package.xml, or the files generated by vulnerability tools, etc. are considered.
Dependabot and Renovate, jargon-wise, would be a “vulnerability triage tool.”
Open Source Software maintainers are encouraged to do some source code repository mirroring, to help better detect attacks that only hit one thing I think? Wrote “Interesting!” but no longer remember wy.
Maven’s “enforcer” plugin can lock which mvn version your source code insists that it built by.
Q&A notes to self: “Holy cow, I’m hitting my stride with CI/CD at a time of a major possible refactor of ‘on which machine, with which allowed egress to the internet?’ assumptions.” Not sure exactly why I wrote that anymore.
Speaker from Chainguard currently working on a whitepaper. That sounds kinda fun. Now I wanna try writing a whitepaper! 😅
Another “public speaking” role model. Detailed, rather than TED-ey motivational, but with business-level / software-development-lifecycle-level content.
Microservices make network engineers of us all.
Kubernetes makes the idea of what’s “infrastructure” and what’s an “app” a little weird, especially if you don’t normally container-orchestrate your apps (but instead just throw a build artifact over the fence into a bare VM or a hyperscaler PaaS like AWS Elastic Beanstalk / Azure App Service / GCP App Engine). (My note: this is the kind of semi-IaC stuff – “semi” as opposed to, say, Terraform and Ansible and whatnot – that Argo/Flux/etc. are meant to manage.) But these two argued that a “service mesh” is “infrastructure,” not “app.” It handles shared mTLS, etc. You’re definitely doing “ops” concerns at this point.
Mesh-enforced mTLS authZ grant systems remind me of Azure RBAC’s inter-SMI-scoped role assignments.
Great slides from the Service Mesh talk: “the promise vs. the reality” & “when should you deploy a service mesh?”
Istio is pretty cool, apparently.
Welcome back to your computer science / software engineering upper-level undergraduate classes, kids.
As someone next to me whispered, “This talk could’ve been the same 40 years ago.” (But, like, that was a compliment. I once read a definition that computer science is science because it seeks to discover things no one has thought of before. And software engineering is engineering because it seeks to do the things everyone already does – because they’re right.)
(Misc. aside: holy cow, military presenters have enviable ballerina-straight posture even when relaxed.)
The presenter’s reminder that craftmanship is trial-and-error-based acquisition of best practices and skill, and is cool where applicable, but is not engineering. Engineering is specification-driven, math-driven, etc. Plus liability transfer. Worth remembering as I ponder “how can I help?” about this new world of supply chain compromises we’re in.
Lots of the Zephyr / embedded systems / robotics / automotive / aerospace / etc. folks in the audience. Not so much other “web service”-type devs.
I know it seems silly, but I always forget about “things that are big and mobile” when I think about embedded systems. I remember smartphones, and I remember, like, packaging machines on factory floors. But I always forget about motherboard chips in fighter planes, the sensors in their wings, their autopilot, etc.
Jargon: “safety-critical software” examples: 911 calls, how much lye goes into a Florida water supply, etc. “Can endanger or kill a person.” Subset of “high-assurance software.”
DO-178C certification is expensive and toilsome to obtain and keep. But it does seem to have some pretty admirable requirements.
Military planes are often flown at high G-force and therefore, by their very nature, have a tendency to render pilots unconscious. Therefore, military autopilot takeover in the case of a nonresponsive pilot can be super important to engineer into a military plane’s autopilot. (And also, therefore, that DO-178C certification process is worth it.)
US Air Force quality assurance ain’t just a bunch of Microsoft Playwright scriptws. There are people with joysticks in cockpit simulators who manually regression-test embedded software!
Formal verification (mathematical proofs) can help reduce the number of manual (or automated) regression test cases needed, especially where there are potentially infinite-for-all-practical-purposes variants that would need to be covered to test software thoroughly by actually running it and asserting whether it behaves as expected.
People make mistakes when writing out mathematical proofs too. Luckily, there are machine-readable syntaxes like ISAR for writing up your proofs, and then, accordingly, there are automatically-executable unit testing frameworks available for validating whether you made an oopsie, like accidentally dividing by zero where that’d render the proof inapplicable.
Now I’m wondering how much work it’d be to make one of my hello-world-ish “-tiny” repos in a way that compiles down to a “proven” / “provable” artifact. (Not sure if I know enough low-level programming languages, well enough, to get past the myriad assumptions that probably aren’t reasonable to assume.) Apparently the time and energy to do so costs about $1,000 of staff time per line of code to do so, on average … yikes!
Making sure that the “assumptions” surrounding the mathematical “proof” are actually reasonable is the heart of determining whether you’ve even got a problem worth trying to mathematically prove. All of the possible states an AWS server can get into would probably be folly to take the time to formal-math through, so if you find yourself trying to write an assumption like “aws-east-1 is up and doing XYZ,” or you find your assumptions piling on top of the other to some other point of no longer being reasonable, then you might have gotten back out of the realm of business problems where mathematically-proven software engineering can really help you much.
Formal methods provide you some guarantees that the system will meet its specifications. Whether those were the right requirements is another question.
Formal methods, like test case authoring, can only validate things you modeled in the first place. If you forgot to model a cosmic ray flipping a bit in the fighter plane’s chip, then, well, that could be a problem.
A Raspberry Pi overheating would be a violation of a “the hardware works” assumption. That said, “the hardware works” is often pretty reasonable to assume in a military software engineering formal methods proof, because the electrical engineers in charge of the chip can typically be trusted to have done their hardware verification formal methods homework.
Generally, yes, it’s okay to make assumptions about phenomena that are nondeterministic in the real world (though they lend themselves particularly well to deterministic variables) – just make sure it’s reasonable to do so. Yes to your USAF electrical engineers who also did FM. Not so much to aws-east-1.
Satellites are very difficult to patch, so formal methods proofs are pretty great for their embedded software, too.
By design, SEL4 isn’t POSIX, and lacks sleep(), malloc, etc. 75% of a 35-million-LoC Linux kernel is probably device drivers. Whereas the SEL4 microkernel has about 10,000 lines of code and 900,000 lines of proofs (spec probably about 1% that size?).
Generally, “protected procedure calls” are meant for synchronous communications between OS protection domains. (OS “notifications” are more for asynchronous communications.)
He showed sample code which, according to my notes, maps out which OS protection domains get access to which memory and with what kind of access.” Whooof, it’s been a while since I read my Tannenbaum and assembly language memory allocation and whatnot books! Fun trip down memory lane, though.
Hardware industry changes might bring that $1k/LOC cost down, which would be cool, though sadly it might still be a while. Price is when we’ll start to see “proven” chips end up in coffee makers, not just fighter jets.
I wonder if the “formally proven” software library supply chain is nonetheless having similar worm problems to the rest of the open-source software library supply chain. Because, again, phishing isn’t about whether the code was bad when its legitimate author wrote it – it’s about someone bad changing it to become bad.
Speaker says: probably suffers the same risk, though when it comes to source code edits, it’s a heck of a lot easier to notice something amiss in SEL4’s 10,000 lines of code than in Linux’s 35 million. And $1,000/LOC with tight assumptions and the desire to minimize the “trusted computing base” tends to lead to rather small codebases.
Finished the Open Source Summit notes; phew!
TODO: Observability Summit.
In my own talk about tiny repos, I said my blog hosting choices were largely influenced by my desire to grow as a frontend web developer. Heck, I almost went to a screen-reader talk (couldn’t make it, notified a friend and hoped they did instead).
But then I also sat through talks about doing advanced math as part of programming against operating systems and thinking about how GPUs vs. CPUs are designed at a hardware level.
I dearly love being a Renaissance Woman / Jill of all trades / polymath. Gorging myself at a full buffet of knowledge is such incredible fun.
A hyperscaler PaaS like AWS Elastic Beanstalk / Azure App Service / GCP App Engine, or a simple VM, is probably the easiest to operate and understand if you don’t need orchestration, and there are a lot of web applications / services that don’t tend to need orchestration.
Services with non-bursty traffic and low service level agreements (SLAs) are a great example of apps that are probably fine just using a hyperscaler PaaS, and if something goes wrong, you take an outage and you deploy it onto another instance of that PaaS. 🤷♀️
(That said, sometimes even non-bursty apps – particularly commercial-off-the-shelf (“CotS”) sprawling multi-server/service apps from vendors – are having their inter-service connections orchestrated via container orchestration, these days, so that they don’t have to roll their own service mesh. So sometimes you don’t choose that you need Kubernetes; the vendor chooses for you.)
Over the weekend, following up, two things I learned are:
npm i to npm ci.--min-release-age flag to your calls to npm i / npm ci (or put the flag straight into your .npmrc files) with a minimum age of at least 2-3 days, to work that age-old IT “great idea; you go first” adage into dependencies.
I ran into a friend who did a lot of work on SPIFFE, and suddenly it hit me that while I take Azure System-Assigned Managed Identities’ existence for granted, I shouldn’t. They came out in late 2017, but the SPIFFE proposal was in May 2016, so, like, lots of people were working on the concept of “give every machine its own identity” authentication (“authN”) principle that today I treat as table stakes while I gripe about authorization (“authZ”) issues in the LLM generative AI agent/MCP era.
Hallway aside: I remembered one of my friends helps secure a large company, and I asked how they’re dealing with digging around for compromised supply chain packages in places where they might not’ve even thought to look. (e.g. if you have a Java developer working on an AWS EC2 VM running AWS’s Linux … surprise, it’s also got Python libraries on it that might be vulnerable if major Python libraries were hacked, even though the Java developer who maintains it had no idea they were supposed to look for Python vulnerabilities on their machine and wouldn’t know what part of the machine to look on anyway because they didn’t put them there!)
Money. The answer is money.
My friend’s company has gobs and gobs of money, and they can afford to pay top-tier sysadmins who know a lot about infosec blue-teaming and keep abreast of what all the supply chain hackers are up to whatever they want. So they just lend out said sysadmins to said VM owners and tell them to inspect every last VM, if that’s what it seems like it’d take.
They’re simply not in short supply of extremely knowledgeable headcount, so they threat-hunt the toilsome way as needed because they can afford to. 🤷♀️
However, I stopped by the OpenSSF booth, too, and they said that for things on a budget:
As I took a break from trying to figure out how to help about supply chain worms, I ended up doomscrolling and seeing open letters authored by strangers in the UK about the terrible regressions in civil rights and liberties going on over there (particularly aimed at harming transgender people extremely intensely, but FWIW, I only get to get paid for my computer knowledge while wearing non-foot-destroying shoes because of loosened standards since the 1990s about what’s “woman enough;” clearly, harsh gender rules hurt us all).
As I wondered just how soon I’ll next have to try to figure out how to help under the intensity of local violence emergency, like I felt helpless in the face of in Minnesota this winter, I realized that my anger at the people behind supply chain worms is personal. I need rest between emergencies. Clearly, outside of work, there are plenty more coming.
I feel resentful that supply chain attackers are putting me back into “I feel so helpless, because this emergency is too huge, but I can’t relax, because surely someone like me is needed as a helper, also because this emergency is so huge” mode through work when I can clearly see that I should be resting up because that emotional crisis-state is surely on its way back into my personal life soon.
Like open-source software maintainers, I’m tired, and now is not a good time.
I’d thought I was just obsessing about researching software supply chain defense every evening and all weekend, this week, because it was interesting. But in this epiphany, it occurred to me, that that’s not quite what it is. I’m too attached to it in a way that isn’t just interest-based hyperfixation. This is stress-based hyperfixation.
I managed to get out for a walk in the woods within an hour of having this epiphany, so that was good, but still, I was already planning to go for walks in the woods all summer anyway. So, like, that doesn’t lessen my resentment. My walks this summer were supposed to be “catch-up” restorative in general, not trying to do real-time double-duty in the specific already as well.
You know how the COVID-19 pandemic’s March 2020 overnight shift to fully-remote work instantly accelerated “might be nice” enterprise IT transformations like adopting “continuous identity verification” and endpoint/mobile device management that didn’t require coming onto campus to complete?
Sadly, I fear this whole package-registry-native supply chain worm problem is another such “we’re all gonna be treading water” crisis of overwork. (Which, like, will lead to clearing a backlog, but maybe not in a particularly humane way of getting there, and isn’t the world already hard enough?)
I left you a wishlist recapping what I dream-dumped at your booth.
All right, out of time, gotta get outside. Keep reloading through next week until I get everything added in from paper notes.
]]>Entra-native / access-control-platform-native (e.g. Azure-RBAC-native / Entra-App-Role-native) “just-in-time authZ elevation” / “PIM” / “eligible, but not active unless there is proof of fresh human intent/approval and only active for a limited timespan” authorization (authZ) for workload identities.
We’ve already got machine-gets-stuck-until-human-approves flows with Azure Pipelines deployment approval checks and GitHub Actions environment approvals.
Let’s make things where Entra service principals are eligible for certain privileged access control grants, but has to wait to move forward because it only active after the machine requests escalation if one of a designated Entra group of humans personally approves it.
See my blog post “Securing authenticated agentic AI.”
Update, 6/29/2026: see also my new post, “Microsoft 365’s Agent Registry should list tools.” More o11y than prevention, but also important, and kinda related.
Please jump with both feet into the CDEvents protocol pool.
Please make both GitHub and Azure DevOps natively publish events and natively subscribe to / consume events.
CDEvents is as impactful as OpenTelemetry! (Which Azure Monitor invested in becoming capable of consuming, and Azure Application Insights invested in becoming capable of producing.)
Particularly because CDEvents can be used as a form of infosec-critical observability, e.g. to centrally monitor whether every CI pipeline run is also accompanied by a corresponding SBOM generation run, etc. In the post-Sha1-Hulud era, enterprises need CDEvents publication yesterday out of our hyperscaler-owned CI/CD platforms.
GitHub, I loved your “Code-to-cloud risk visibility with Microsoft Defender for Cloud is now generally available” blog post, but I was heartbroken it only applies to containerization.
Azure App Service team, can you please partner with the Defender team and the GitHub team (and Azure DevOps team, for that matter!) to find a way to provide the same type of attestation/provenance party tricks when simply running an npm run build CI/CD build step followed by an azure/webapps-deploy CI/CD deploy step?
Easy-button “Buy” application developers deserve provenance just as much as hard-mode “Build” (container-trained) application developers! 🥰
I know that azure/webapps-deploy is just making a .zip file and throwing it over the fence at Azure App Service over HTTPS, which isn’t inherently as “hashed” as container-building is, and that Kudu potentially lets Azure App Service owners introduce drift even after that, but …
Could you find a way somehow, maybe, at least for the happy path?
I really like the idea of it being obvious that:
Thanks so much!
]]>Click Here to download a PDF of the slides
Come see me again on Thursday afternoon at the Observability Summit.
Here is my conference recap (#OSSHomework assignment number 1); still a work in progress.
7/20/26 update: I laughed uncontrollably this morning when I saw Andrew Nesbitt’s satirical blog post “Package Management as Org Chart.” If you watched my talk’s video, you saw me ponder whether it was really ethical anymore that my tiny teaching repos avoid dependency manager lockfiles and import packages as latest (which I started as a way of reducing distracting lines of code from the point each repo was actually trying to make), in this era of open-source software supply chain worms. Yes, I tend to commit straight to main on my teaching repos – I feel very called out! 😉😆
]]>
- “No lockfile,
latesteverywhere: each install resolves fresh against the registry, and the dependency set is whatever’s newest at that moment. The founder still commits tomain, had a bad experience withnpm-shrinkwrap.jsonyears ago, and won’t touch a lockfile.”
After one afternoon of initial setup, your day-to-day job switches from “add or remove someone in the Visual Studio admin portal” to “add or remove an Entra group member.”
This might not seem like a sea change, but the nifty thing is that it’s likely your enterprise IT department already has some pretty mature bread-and-butter processes for adding and removing Entra group members in response to business-level requests (e.g. through the helpdesk ticketing system, or automatically removing group members whom HR systems report are no longer employees of the enterprise at all).
So you might be able to get out of the manual grant-and-revoke business altogether.
Also, if the Finance department ever wants more confidence that Microsoft is granting entitlements (such as Azure DevOps licensure or GitHub Enterprise Cloud licensure) appropriately according to Visual Studio license level, the Finance department won’t have to wait on you personally to export a list of Visual Studio license levels from the Visual Studio admin portal.
Instead, any old staff member with access to see which employee is a member of which Entra security group (which is often everyone at a company) could pull that report of “who’s got which Visual Studio license level,” as long as they know the names of the relevant Entra security groups.
First, figure out the number of Entra security groups that makes sense for your enterprise to create. The most common approach is one group per Visual Studio subscription level – for example, two Entra groups named:
For each Entra security group you need created, you’ll need to provide your Entra administrator (or whoever handles group creation in your org; there’s probably a helpdesk ticket type for it) with the following details:
| Field | Example |
|---|---|
| Name | Licensed Visual Studio Enterprise Subscribers |
| Description | All members of this group have been assigned a Visual Studio Enterprise subscription via the VS Subscriptions Admin Portal. |
| Owners | You and some backups (note: an “owner” of an Entra security group can in turn be another Entra security group, if that makes it easier to add your whole department in one fell swoop) |
| Starting members | The list of people who currently have that license level (note: as of the time of this writing, each “member” of this Entra security group must be a direct human, and cannot be another Entra security group – Entra wouldn’t complain about nested groups, but Visual Studio would ignore indirect group membership) |
That’s it. Submit that request and wait for confirmation that the groups exist (and, hopefully, are populated with the correct starting members, so you don’t have to do it – but if they leave the membership list empty, read on and add everyone using the usual processes you’ll use as additional people request licensure over time).
Once your new Entra security groups exist, follow Microsoft’s instructions assign Visual Studio licenses to those groups. As a recap, it’s more or less these steps:
Repeat for each group.
That’s the entire one-time setup.
Good news about existing individual assignments: according to Microsoft docs at the time of this writing, If someone already has an individual license assignment in the Visual Studio, but they’re also in an Entra security group that has that same license level assigned, the Visual Studio portal is smart about it. They get absorbed into the group assignment and the Visual Studio portal un-lists their individual assignment. Yay for not needing to manually clean up every old individual assignment!
Scroll to the bottom of your subscriber list and you’ll see your groups listed. Click View subscribers on a group to confirm the right people are showing up. Email a few of those individuals and ask them to spot-check that a few of those individuals can still access their Visual Studio benefits; they should see no interruption.
This is where your day-to-day process changes. You probably won’t end up in the Visual Studio administrative portal anymore, day-to-day.
Instead, going forward:
Here’s the old process:
| Cadence | What Happens | Who Does It |
|---|---|---|
| Ongoing | Add/remove people from the Visual Studio admin portal as needed | You or fellow VS portal admins |
And here’s the transition (new process in the last line):
| Transition Phase | What Happens | Who Does It |
|---|---|---|
| Planning | Identify groups needed, compile member lists | You (one time) |
| Group creation | Request Entra groups with name, description, owners, members | Entra admin, as requested by you (one time) |
| Portal setup | Add each Entra group to the Admin Portal with subscription level | You (one time) |
| Verify | Confirm members show up and licenses are active | You (one time) |
| Ongoing | Add/remove people from the Entra group as needed | You or fellow group owners, or maybe even central IT for you |
The whole transition should only be a few minutes/hours of hands-on work. Most of the delay will involve waiting on the Entra security group creation request to be fulfilled by your central IT team.
After that, managing Visual Studio licenses stops being a portal task and becomes a simple Entra security group membership management task – one that, if you’re really lucky, can be automated by colleagues who automate Entra security group membership every day.
This post was heavily LLM-generated, with just a bit of editing, sorry, friends! It seemed useful enough to just “git ‘er done” on a busy day and delegate to the writing-machine.
]]>