WAF friction, an adjacent host and 180 untested IPs

The Jenkins server is out of scope even though it appears to belong to the client. Ownership does not equal authorization. I would not log in, run anything in the script console, or probe further to confirm the anonymous access; the page already gives me enough to describe the observation. I would stop, record the IP, timestamp, evidence and the ASN/WHOIS/reverse DNS supporting attribution, and notify the client contact the same day. I would ask for a written decision: add the host or range to scope via a signed amendment, or leave it out and accept that it is untested while treating an exposed Jenkins script console as a risk to investigate outside the engagement. I would not 'just check whether it's exploitable' as a favour. If they authorize testing, the constraints go in writing before I touch it. I would also check whether my mapping of the adjacent /24 was itself inside my authorized ranges. If it was not, I need to disclose that and stop that activity too. The self-interested point is the same as the ethical one: unauthorized access to a client-owned but out-of-scope host is still unauthorized access.

I would talk to the SOC rather than try to evade it. I would give them my source IPs, the testing window and a contact number, so their alerts become a coordination channel instead of a block. Then I would test the WAF itself as a finding: what it blocks, what it misses, whether encoding or alternate paths bypass it, and what that means for the client's control claims. Evasion is legitimate only where the ROE authorizes it and where it does not amount to denial of service. Slowing down is not a compromise of the test; it is the correct response to a shared production system. I would reduce concurrency, add delays, cut the most aggressive payloads, and prioritize manual testing on high-value endpoints. If the WAF blocks 80% of automated traffic, that is itself a useful result: the client learns the control works against commodity tooling. But I must not report 'no vulnerabilities' on that basis, and I must not let the WAF's behaviour be mistaken for the absence of a vulnerable application behind it. The SOC interaction and the blocking behaviour belong in the report as environmental context.

Full coverage is not achievable, and I would say so now rather than at the end. I would re-scope with the client in writing: take a risk-based sample - internet-facing web applications, VPN and remote access, mail, anything with an administrative interface - spread across the ranges, and agree the number of hosts I can test properly. Then report exactly which IPs were tested, which were sampled, which were not tested and why, how the sample was chosen, and what the untested set represents. A test of 70 hosts with validated findings and an honest coverage statement is more useful, and more defensible, than a 180-host port scan that 'covered' everything and proved nothing. I would also spend remaining time confirming the findings I already have, because an unconfirmed critical is a liability in a report. The client's expectation of full coverage is a scoping problem that should have been resolved at kick-off. The professional move is to surface it on day two, put the limitation in the report and in the closing meeting, and not let a coverage number become a claim that the test never supported.