> Depending on how the code is being served, cloaking is a big problem for scanners... if you think it's no risk you're probably overlooking the risk. Google pu

> Depending on how the code is being served, cloaking is a big problem for scanners... if you think it's no risk you're probably overlooking the risk. Google put out a report on it and there's lots of papers on it and related topics like VM detection in browsers. Almost all bot/automated test/scanner detection relies on JS in the browser, which is too late to avoid triggering an alert with our approach. The attacker would have to identify us from our network request to load the compromised resource alone, for which we have (so far) effective mitigations. > In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware? We'll alert the client company for any resource that's changed - you can't trust that any third party resource change is okay, especially if the reputational and legal cost of a breach can exceed 10's or 100's of millions. Most third party code from reputable companies, including tracking tagging, doesn't change that often, and client security/ops teams tend to be horrified by the ones that do. Each time some third party silently replaces code that they're serving, it introduces new opportunities for bugs, breakages, and attacks. I really disagree with you about SRI. SRI isn't sufficient to prevent all client-side attacks, but it is very effective, and when enterprise customers demand it, third-party services almost always find a way to support it.