Disabling install scripts fleet-wide breaks a third of your builds - is that switch a control?

## The question behind the question An interviewer asking this is not testing whether you know the flag exists. They are testing whether you can distinguish a **mitigation you switched on** from a **control you can be audited against**, and whether you can hold that line in a room where a third of the engineering org has a broken build and wants an exception by lunchtime. ## Why the switch is genuinely worth having Start by conceding the real part. Disabling install-time scripts removes an execution point that is unconditional, early, and available to every package in the resolved tree including the ones nobody chose. That is the cheapest single reduction available in this area, and on a build host it removes execution from the machine most likely to hold deployment or publishing credentials. A candidate who dismisses it looks contrarian rather than senior. ## Why it is not yet a control Four reasons, in the order they matter: **1. It answers the wrong question.** It removes a capability; it does not decide which publishers you are willing to run. The package still installs, still ships whatever code it shipped, and still executes when the build or the application touches it. Trust was never evaluated. **2. It is not enforced, only configured.** A flag that lives in a repository's configuration is advisory: a new repository omits it, a developer's laptop never had it, a container build invokes the installer differently, and another ecosystem in the same monorepo has its own unrelated behaviour. Controls have one enforcement point that a team cannot silently opt out of. **3. Its exceptions are adversely selected.** The builds that break are dominated by packages that compile native extensions or generate code at install - which is to say, packages with the largest install-time capability and the most opaque payload. Left to per-team triage, the exception list converges on exactly the population you were most worried about, and nobody ever sees the list as a whole. **4. It leaves no evidence.** You cannot show an auditor, a customer or your own incident review which repositories are covered, which are exempt, who approved each exemption and when it was last revisited. A control produces that record as a by-product. ## Turning it into one The shape of the answer is standard control design applied here: - **Default-deny at a place teams do not own.** The install configuration comes from the platform's build image or shared configuration, not from each repository, so the safe setting is inherited rather than remembered. - **An explicit allow-list of packages permitted to run install code**, each entry carrying a reason class - native compilation, code generation, vendored binary - a named owner, and an expiry that forces a re-look rather than permanent grandfathering. - **A path off the list.** For most entries there is a way out: consume a pre-built artifact, vendor the built output, or move the compilation into a controlled build of your own. Making the exception uncomfortable and time-boxed is what stops the list from growing forever. - **Measurement that is about exceptions, not about the flag.** 'The flag is on in 98% of repos' is a vanity metric. 'The number of packages permitted to run install code fell from 140 to 30, and every remaining one has an owner' is a control improving. - **A written residual.** Say out loud that build-time and import-time execution are untouched, so that nobody in the organisation concludes that dependency risk has been handled. This is the sentence that keeps the next incident from being a surprise. ## The conversation with the teams The political failure mode is to announce the change, break a third of the builds, and let each team negotiate its own escape. That produces the worst of both outcomes: real friction and no control. Sequence it instead - measure first which repositories actually depend on install-time execution, because it is usually a minority and knowing the number changes the conversation; land the default where it is enforced and where breakage is visible and fixable; publish the allow-list so exceptions are a shared object rather than a private workaround; and only then move to developer machines, where enforcement is weakest and where the flag is most often assumed to be in effect when it is not. ## The one-line version A workaround is something you turned on. A control is something you can prove is on, know the exceptions to, and can say what it does not cover. This switch is worth having, and it becomes a control only when it acquires an owner, an enforcement point, a reviewed exception list and a stated residual.