# defense in depth Published articles for defense in depth. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Redesigning Kubernetes Workqueues and Resyncs to Reduce Thundering Herd Effects DevFeed: [Redesigning Kubernetes Workqueues and Resyncs to Reduce Thundering Herd Effects]() Original publisher: [Read original article]() Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Kubernetes](), [systems](), [Concurrent Programming](), [Latency](), [Maintainers]() Tags: [architecture](), [concurrent](), [defense-in-depth](), [failover](), [goroutines](), [kubernetes](), [latency](), [maintainers](), [reconciliation](), [thundering-herd]() ### AI overview This article explains how Kubernetes controllers can experience thundering herd effects when restarts, leader failovers, or periodic resyncs cause many keys to enter an in-memory workqueue at once. It describes the queue and informer behavior behind the problem and introduces Chainguard's redesign of workqueues and resyncs to improve reconciliation under these conditions. ### Source excerpt The thundering herd is an architecture problem. See how Chainguard redesigned workqueues and resyncs to keep reconciliation running smoothly. ## Mastering IAM in Ceph: Multi-Tenancy, Access Control, and Why ACLs Must Die DevFeed: [Mastering IAM in Ceph: Multi-Tenancy, Access Control, and Why ACLs Must Die]() Original publisher: [Read original article]() Author: Daniel Alexander Parkes, Anthony D'Atri Published: 2026-01-24T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [IAM](), [Authorization](), [Security](), [Multi-tenancy](), [Amazon S3](), [Amazon Web Services](), [Architecture & Design]() Tags: [access-control](), [aws](), [blog-post](), [ceph](), [defense-in-depth](), [en-article](), [en-blog-post](), [iam](), [identity](), [multi-tenancy](), [operations](), [production](), [rgw](), [s3](), [security]() ### AI overview This article explains why ACLs in Ceph Object Gateway should be disabled in favor of centralized IAM policies. It discusses S3 permission failures, multi-tenant access problems, AWS's ACL-disabled defaults, and defense-in-depth measures such as Block Public Access and explicit denies for ACL operations. ### Source excerpt Introduction ¶ Introduction: When Security Theater Becomes a Real Disaster ¶ In March 2017, a misconfigured S3 bucket at Verizon exposed the personal information of 14 million customers. The root cause wasn't a sophisticated attack; it was a simple oversight in access permissions. The bucket was set to be publicly accessible due to S3 permission misconfiguration, and no one noticed because ACLs were managed separately from the company's centralized IAM policies. The security team had implemented careful, identity-based access controls, but a resource-level ACL silently bypassed them by granting access to "All Users." This scenario repeats constantly across the industry: ACLs creating invisible access paths that security teams don't know exist, buckets accidentally exposed to the public internet, and contractors uploading data that the bucket owner cannot reliably read or administer, while still consuming capacity. Between 2017 and 2019, major companies exposed hundreds of millions of records via misconfigured S3 permissions (ACLs and/or bucket policies): Verizon (2017): 14 million customers - An AWS S3 bucket configured for public access exposed names, addresses, account PINs Facebook (2019): 540 million records - Third-party apps stored user data in publicly accessible S3 buckets Instagram (2019): 49 million records - Marketing firm left influencer database unprotected in AWS S3 The AWS response was clear: since April 2023, all new S3 buckets default to "ACLs disabled" (BucketOwnerEnforced) and Block Public Access enabled. AWS strongly recommends disabling ACLs on existing buckets and migrating to a pure policy-based model with IAM Accounts architecture. If you're running the Ceph Object Gateway (RGW), you have access to the same IAM Accounts model introduced in Ceph Squid 19.2.0. This post explains why ACLs must be disabled immediately and how to implement modern, secure access control with IAM policies. Do This First (Quick Security Wins) Before reading further, ## Strengthening cyber resilience as AI capabilities advance DevFeed: [Strengthening cyber resilience as AI capabilities advance]() Original publisher: [Read original article]() Published: 2025-12-10T12:00:00Z Content type: opinion Language: en Sources: [OpenAI News]() Topics: [Cybersecurity](), [AI Models](), [OpenAI](), [Resilience](), [Artificial Intelligence](), [Security](), [Machine Learning, Security Attacks]() Tags: [ai](), [ai-models](), [code](), [ctf](), [cybersecurity](), [defense-in-depth](), [models](), [openai](), [security](), [vulnerabilities]() ### AI overview OpenAI describes its investment in stronger safeguards and defensive capabilities as AI models become more capable in cybersecurity. The article explains risk assessment, misuse prevention, defense-in-depth safeguards, and tools for workflows such as code auditing and vulnerability patching. ### Source excerpt OpenAI is investing in stronger safeguards and defensive capabilities as AI models become more powerful in cybersecurity. We explain how we assess risk, limit misuse, and work with the security community to strengthen cyber resilience. ## Mitigating prompt injection attacks with a layered defense strategy DevFeed: [Mitigating prompt injection attacks with a layered defense strategy]() Original publisher: [Read original article]() Author: Kimberly Samra (noreply@blogger.com) Published: 2025-06-13T16:03:00Z Content type: opinion Language: en Sources: [Google Online Security]() Topics: [prompt injection](), [ai security](), [Generative AI](), [Google](), [Artificial Intelligence]() Tags: [ai](), [ai-security](), [defense-in-depth](), [generative-ai](), [google](), [none](), [prompt-injection](), [red-teaming](), [security]() ### AI overview Google describes a layered defense strategy for mitigating indirect prompt injection attacks in Gemini. The approach combines model hardening, machine-learning classifiers, adversarial training, sanitization, user confirmations, and security notifications across the prompt lifecycle. ### Source excerpt Posted by Adam Gavish, Google GenAI Security Team With the rapid adoption of generative AI, a new wave of threats is emerging across the industry with the aim of manipulating the AI systems themselves. One such emerging attack vector is indirect prompt injections. Unlike direct prompt injections, where an attacker directly inputs malicious commands into a prompt, indirect prompt injections involve hidden malicious instructions within external data sources. These may include emails, documents, or calendar invites that instruct AI to exfiltrate user data or execute other rogue actions. As more governments, businesses, and individuals adopt generative AI to get more done, this subtle yet potentially potent attack becomes increasingly pertinent across the industry, demanding immediate attention and robust security measures. At Google, our teams have a longstanding precedent of investing in a defense-in-depth strategy, including robust evaluation, threat analysis, AI security best practices, AI red-teaming, adversarial training, and model hardening for generative AI tools. This approach enables safer adoption of Gemini in Google Workspace and the Gemini app (we refer to both in this blog as "Gemini" for simplicity). Below we describe our prompt injection mitigation product strategy based on extensive research, development, and deployment of improved security mitigations. A layered security approach Google has taken a layered security approach introducing security measures designed for each stage of the prompt lifecycle. From Gemini 2.5 model hardening, to purpose-built machine learning (ML) models detecting malicious instructions, to system-level safeguards, we are meaningfully elevating the difficulty, expense, and complexity faced by an attacker. This approach compels adversaries to resort to methods that are either more easily identified or demand greater resources. Our model training with adversarial data significantly enhanced our defenses against indirect prompt in ## Mitigating a rsync Vulnerability: A Lesson in Compiler Hardening DevFeed: [Mitigating a rsync Vulnerability: A Lesson in Compiler Hardening]() Original publisher: [Read original article]() Published: 2025-03-19T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Compiler](), [chainguard](), [Security](), [c/c++](), [vulnerability]() Tags: [c](), [c-plus-plus](), [chainguard](), [compiler-flags](), [compiler-hardening](), [cves](), [defense-in-depth](), [hardening](), [linux](), [llvm](), [product-security](), [rsync](), [security](), [x86-64]() ### AI overview Chainguard describes how compiler hardening in its C/C++ toolchain helped protect against an rsync vulnerability before public disclosure. The article presents compiler hardening flags as layers of defense for memory-unsafe software and discusses Chainguard's implementation of recommendations from OpenSSF and GCC. ### Source excerpt Chainguard's defense-in-depth security strategy protected against multiple rsync CVEs before they were even reported. See how we did it, using compiler flags. ## An Ode to Defense in Depth DevFeed: [An Ode to Defense in Depth]() Original publisher: [Read original article]() Published: 2025-03-17T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [supply-chain-security](), [GitHub](), [Security](), [Open Source](), [Maintainers]() Tags: [2025](), [automation](), [awareness](), [chainguard](), [defense-in-depth](), [github](), [maintainers](), [open-source](), [pull-requests](), [renovate](), [secrets](), [security](), [software-supply-chain-security](), [spoof](), [supply-chain](), [supply-chain-security](), [team]() ### AI overview Chainguard describes how a March 14, 2025 supply chain attack compromised tags in the tj-actions/changed-files GitHub repository, causing a malicious commit to dump action-runner memory and potentially expose secrets. The article outlines Chainguard's defense-in-depth response, including blocking affected updates, suspending some automation, checking affected repositories, contacting customers and maintainers, and treating build systems like production systems. ### Source excerpt Chainguard's defense in depth approach to security helped protect it from the recent tj-actions/changed-files GitHub repository compromise. Learn more about how. ## Could IPFS Have Prevented the Bybit Hack? DevFeed: [Could IPFS Have Prevented the Bybit Hack?]() Original publisher: [Read original article]() Author: Daniel Norman Published: 2025-02-28T00:00:00Z Content type: opinion Language: en Sources: [IPFS]() Topics: [IPFS](), [Security](), [Web](), [smart contract]() Tags: [aws-s3](), [defense-in-depth](), [ipfs](), [object-object](), [s3](), [security](), [smart-contract](), [social-engineering]() ### AI overview The article examines the Bybit hack, in which a malicious Safe frontend led multisig owners to sign a harmful transaction. It argues that IPFS content addressing and local verification could have provided an additional preventive layer for dapp frontends, while noting that the exact method of AWS S3 access was unclear. ### Source excerpt The Bybit hack revealed several security failures, this post examines whether IPFS could have helped prevent the hack and practical solutions for dapp developers. ## Audited least privilege DevFeed: [Audited least privilege]() Original publisher: [Read original article]() Published: 2024-05-13T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Security](), [Access Control](), [IAM](), [Authorization](), [identity and access management](), [Cloud](), [SIEM, Security, Observability](), [supply-chain-security]() Tags: [access-control](), [audit](), [cloud](), [defense-in-depth](), [ephemerality](), [identity-and-access-management](), [identity-management](), [least-privilege](), [logs](), [minimalism](), [security](), [software-supply-chain](), [software-supply-chain-security](), [supply-chain](), [trust]() ### AI overview The article presents audited least privilege as a cloud security model that complements fine-grained IAM grants with fine-grained IAM audit log policies. It emphasizes minimizing access by level, scope, and duration, then monitoring resource access to verify that only expected identities use provisioned resources. ### Source excerpt Strengthen your software supply chain security with audited least privilege. Learn how Chainguard's approach minimizes risk and enhances trust. ## Defense in Depth DevFeed: [Defense in Depth]() Original publisher: [Read original article]() Author: Daniel Berman Published: 2024-02-29T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Cybersecurity](), [Security](), [Application Security]() Tags: [application-security](), [article](), [attacks](), [awareness](), [cybersecurity](), [defense-in-depth](), [executive](), [megawatt](), [security](), [vulnerability]() ### AI overview This article explains defense in depth as a cybersecurity methodology that combines multiple layers of security and mitigation techniques. It emphasizes preparing for the failure of individual tools or controls so that additional layers continue to hinder attackers, including in application and service environments. ### Source excerpt Defense in depth is a cybersecurity approach that focuses on making it as difficult as possible for attackers to succeed by combining numerous security measures. ## Server-side sandboxing: An introduction DevFeed: [Server-side sandboxing: An introduction]() Original publisher: [Read original article]() Author: Hongyi Hu; Max Serrano Published: 2023-10-24T00:00:00Z Content type: article Language: en Sources: [Figma Blog]() Topics: [Security](), [Vulnerabilities](), [Architecture & Design](), [Image processing](), [C++](), [Software]() Tags: [architecture](), [article](), [c-plus-plus](), [defense-in-depth](), [engineering](), [image-processing](), [infrastructure](), [security](), [security-engineering](), [vulnerabilities]() ### AI overview This introduction to server-side sandboxing explains why image processing, parsing, compression, and thumbnailing workloads can create security risks, especially when they depend on memory-unsafe software such as C++ libraries. It presents application-level sandboxing, or workload isolation, as a defense against vulnerabilities and outlines the challenge of choosing among available isolation techniques and balancing their trade-offs. ### Source excerpt In this three-part series, our security engineering team shares practical tips for deploying and operating application sandboxing techniques. First up: evaluating the many sandboxing options, and how to think about the trade-offs between them. ## Conquering your Build Horizon DevFeed: [Conquering your Build Horizon]() Original publisher: [Read original article]() Published: 2023-10-10T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Automation](), [rego](), [CI/CD](), [Security](), [Vulnerabilities](), [GitHub Copilot]() Tags: [architecture](), [automation](), [base-images](), [build-horizon](), [chainguard-images](), [config](), [container-images](), [defense-in-depth](), [dependencies](), [github-action](), [rego](), [security](), [vulnerability]() ### AI overview The article presents Build Horizon, a policy that limits how long build artifacts such as binaries and container images may remain in production before being rebuilt. It explains how freshness controls, dependency automation, and policy checks can reduce risks from outdated software and long-lived builds. ### Source excerpt "Build Horizon" is a practice that imposes a maximum age on build artifacts. Learn more about how it works and see an example in action! ## Phishing Defenses DevFeed: [Phishing Defenses]() Original publisher: [Read original article]() Author: Adam Published: 2023-06-07T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Security](), [Architecture & Design](), [Users](), [Testing]() Tags: [cost](), [defense-in-depth](), [email](), [people](), [phishing](), [security](), [training]() ### AI overview This commentary examines phishing defenses and argues that telling users to avoid bad links and relying on defense in depth may impose costs without necessarily being effective. It considers user behavior, suspicious-email reporting, and the value of security training. ### Source excerpt Phishing behaviors, as observed in the wild. ## Remediating AWS IMDSv1 DevFeed: [Remediating AWS IMDSv1]() Original publisher: [Read original article]() Published: 2021-08-11T16:16:23Z Content type: tutorial Language: en Sources: [Latacora]() Topics: [Amazon Web Services](), [Amazon EC2](), [AWS IAM](), [Exploit](), [vulnerability](), [Amazon Simple Queue Service (SQS)](), [DynamoDB]() Tags: [aws](), [bugs](), [credentials](), [defense-in-depth](), [dynamodb](), [ec2](), [exploit](), [iam](), [infrastructure](), [sqs](), [technical](), [vulnerability]() ### AI overview This technical article explains why AWS Instance Metadata Service version 1 is risky. Applications vulnerable to SSRF, XXE, or RCE may allow attackers to obtain temporary IAM role credentials from EC2-hosted applications and use them to access AWS services. The article presents defense in depth as a way to limit the impact of application vulnerabilities, although the supplied text ends before the remediation details. ### Source excerpt 2024-12-17 Updated to include Declarative Policies Compute resources in AWS (for example, EC2 instances, ECS tasks/services, etc.) get access to AWS credentials, such as temporary instance role credentials, via the Instance Metadata Service (IMDS). The compute resources use these credentials to access other AWS services such as SQS, DynamoDB and Secrets Manager. Introduction: Problems with IMDSv1 # There was originally only one version of IMDS, now called "v1," which unfortunately many people still use. The technical risks and high profile incidents (the Capital One breach comes to mind) associated with v1, as well as the existence of v2 are well-documented. When an application hosted on an EC2 instance is vulnerable to SSRF, XXE or RCE, attackers can likely steal the temporary AWS credentials of the IAM role configured for the instance. This service is a particularly interesting target for attackers: