Monday,
November 17, 2025

๐Ÿฅ– Palette Cleanser

Alo alo alo,

The most clicked part of this newsletter is the chef's selections. Most of the time, the articles I share are security research, and if they aren't research, they are unique lessons and experiences. Since most regular humans can't justify the time it takes to write unique, interesting stuff, often it comes from vendors (one of whom I work for). This week Rami McCarthy (also works for a vendor) published The Sins of Security Vendor Research, and I'd like to recruit all of you to read it and keep vendors honest about their "research".

"Sin 2: False Novelty" is the most important to me. I try to be the steward of existing research and reference what lineage I know. But if I ever miss anything, please do let me know. Maybe we could even make trips down memory lane its own section in the future. What do you think?

Stay safe out there, and donโ€™t cross the streams.

Have feedback about AWS Security Digest? Tell us here. This issue is also available to share online.

๐Ÿ“‹ Chef's selections

  • How I Overlooked the Problem and Shot Myself in the Foot by Dmytro Sirant

    Dmytro has been doing some migrations from IAM users to SSO. As part of that, heโ€™s been upgrading Terraform files that manage KMS, and he hit some snags. The story is worth reading so you can plan your migration too, but the thing that caught my eye... when he lost access to his KMS key, "The AWS team just granted the required permissions to the key as an additional rule without dropping the existing ones."

  • Things you wish you didn't need to know about AWS service-linked roles by Daniel Grzelak

    Your AWS accounts have these special IAM principals called service-linked roles. They aren't yours. You can't edit them. You can only delete them under certain conditions. And they give AWS services access to do lots of stuff with some not-so-tightly scoped policies. They can also be abused by attackers to figure out what services you use. Lots of juicy details in this one.

  • The log rings donโ€™t lie: historical enumeration in plain sight by Bleon Proko

    Bleon pulls together a bunch of well-known but rarely discussed techniques showing how much attackers can learn just by reading your AWS logs. CloudTrail alone leaks identity info, resource names, request parameters, and even permission states through patterns like "errorCode=AccessDenied". With nothing more than "cloudtrail:LookupEvents", someone can map out identities, resources, and privilege changes across time. A great reminder that log read access in AWS is far more sensitive than most orgs treat it.

Bonus: Farewell ingress-nginx: How Repeated Security Breaches Led to Its Downfall

๐Ÿฅ— AWS security blogs

๐Ÿ› Reddit threads on r/aws


๐Ÿ’ธ Sponsor shoutout

Pleri logo

Meet Pleri: your AI-powered cloud security teammate. Sheโ€™s not a chatbot. Pleri proactively finds meaningful security work and fixes issues before they become problems.

Learn more about Pleri and see her in action.


๐Ÿค– Dessert

Dessert is made by robots, for those that enjoy the industrial content.

๐Ÿง IAM permission changes

๐Ÿช API changes

๐Ÿน IAM managed policy changes

โ˜• CloudFormation resource changes

๐ŸŽฎ Amazon Linux vulnerabilities

๐Ÿ“บ AWS security bulletins

๐Ÿšฌ Security documentation changes

YouTube Twitter LinkedIn