A customer demands quarterly external pentests of your build pipeline and 4-hour notice of any dependency CVE — do you agree?

## The judgment being tested This is not a technical question with a right answer; it is a question about who decides, on what basis, and what the decision costs the company for years afterwards. Interviewers use it because the wrong instinct — agree to everything, revenue is waiting — is extremely common and extremely expensive. ## Step one: find the concern under the clause Customers rarely write clauses from first principles. They write them from a framework, a previous incident or a template. Both clauses here have a legitimate concern underneath them: - The pipeline pentest clause is really asking *how do we know your build system cannot be turned against us*. That is the right worry — a build system that produces the artifact they install is a production system pointed at their estate. - The four-hour notification clause is really asking *how do we learn quickly when something we run from you becomes dangerous*. Write those two sentences down. They are what you are negotiating against, and they are usually satisfiable by controls that cost a fraction of the literal clause. ## Step two: price the yes, honestly and across the portfolio The cost of a clause is rarely in the first product; it is in the multiplication. **Four-hour notification, any severity, twelve products.** This is a staffed duty, not an engineering task. It needs a rota that covers nights, weekends and holidays; a paging path; a decision procedure at 3 a.m. about whether a newly published advisory touches a shipped artifact; and a written notification produced under a contractual clock. The volume is dominated by low-severity findings in components the customer's deployment never exercises, which trains them to ignore your notifications — so the clause degrades the very signal it was meant to create. And every missed window is a contractual breach, so you have converted noise into legal exposure. The correct unit for this cost is recurring headcount, not engineer-weeks. **Quarterly external pipeline testing.** Recurring procurement, scheduling, scoping and remediation cycles, four times a year, plus the internal effort to support each engagement. Testing a build pipeline as a black box is also a poor fit for the risk: the interesting weaknesses are configuration and authorisation properties — who can change the pipeline definition, what a fork or an untrusted input can make it run, what credentials a step can reach — which are better established by inspection and enforcement than by a time-boxed external test repeated every quarter. Some clauses fail this test even more obviously. A demand for an annual filmed key ceremony is a genuine control ritual in the specific world of long-lived offline root keys with multiple custodians; imported wholesale into a normal software vendor's contract it buys the customer a video file and buys you a day of theatre. ## Step three: counter-offer something better A refusal without an alternative reads as evasion. Attach a counter-offer that addresses the concern you wrote down: | Their clause | What actually reduces their risk | |---|---| | Quarterly external pipeline pentest | Signed provenance for every artifact they receive, so they can verify what built it; enforced review and change control on the pipeline definition; a scoped pipeline assessment inside the existing annual product test | | 4-hour notice of any CVE, any severity | A fast committed window for findings that are exploitable in the shipped artifact or known to be actively exploited; everything else through a published advisory channel on the normal release rhythm | The second row is the important move: it swaps a severity-blind volume commitment for an impact-based one, which is both cheaper for you and more useful to them. ## Step four: decide it above the deal Three organisational points separate a principal answer from a senior one. **Precedent.** The terms you accept for one customer become the floor for the next twenty, because the next schedule will be benchmarked against what you have already agreed to and because you cannot operate two standards of care. Treat contractual security terms as a product decision with a standard position, not as a per-deal concession. **Authority.** Someone must be empowered to say no when the clause is revenue-blocking, and that person cannot be the engineer who received the spreadsheet. The escalation path — engineering states the cost, the business decides whether the revenue justifies it — has to exist before the deal that needs it. **Honesty of the numbers.** The refusal is only credible if the yes was priced properly. State it as engineer-months to build, recurring headcount to run, and recurring spend, and let the business weigh it against the contract value. Sometimes the answer is genuinely yes, at a price; a principal who never says yes is as useless as one who never says no. ## The failure modes Saying yes to everything and quietly not doing it is the worst outcome: it is a contractual breach waiting to be found, and it corrupts the register other customers rely on. Refusing bluntly with no alternative loses the deal for no gain. Delegating the decision to whoever wants the revenue guarantees the first outcome.