While reviewing several AWS security scanners—and building one myself—I noticed that many check public access, encryption, and bucket policies but don't check whether S3 server access logging is enabled. Is this mainly because logging is considered lower priority, or is the check more complicated than it appears from the API? I initially thought my scanner had a regional bug when a report skipped a bucket, but the real issue was that the logging check had never been implemented. After adding it, I started thinking about how often security tools simply lack certain checks rather than reporting them incorrectly. Are there other AWS controls you've found that are commonly missing from otherwise comprehensive scanners?
3 Answers
It may also be that access logging is less visible in security tooling because it is a fairly unexciting control until an investigation actually requires it. Public exposure and encryption are easier to explain as universal checks, while logging depends much more on cost, retention, data volume, and what other audit sources are already in place. It would still be useful for scanners to report whether the setting exists, as long as they clearly distinguish an informational gap from a confirmed vulnerability.
I wouldn't assume the feature is absent from every scanner without naming examples. Some tools may cover it under broader audit or compliance checks rather than exposing it as a prominent S3 finding. The useful question is probably not just whether logging is enabled, but whether the bucket's monitoring strategy is appropriate for its sensitivity and traffic profile.
For many environments, skipping this check is a deliberate risk decision rather than a visibility problem. S3 server access logging can create substantial storage and processing costs, especially for environments with petabytes of data and huge numbers of automated requests. If access is already constrained through private networking and monitored with other controls, the added value may be low. A scanner that flags every bucket unconditionally could therefore create a lot of false positives; it should ideally account for the workload, access patterns, and existing monitoring.
That makes sense. The check should probably be treated as context-dependent instead of an unconditional failure, particularly for high-volume private environments. I'll look at documenting those exceptions rather than presenting the result as universally unsafe.
Fair point. I was focusing on the tools and codebases I reviewed, so I should avoid generalizing too broadly. I'll compare against more scanners and make the check's scope and assumptions explicit.