15 posts tagged with "Security"

We published incorrect artifacts in the 1.233.0 and 1.233.1 releases.

Release engineering controls versions, builds, signatures, provenance, and distribution. Application tests alone do not prove that this process publishes the correct release.

We test the release process in CI alongside Atmos. Tests check release rules, artifact verification, and publication without real releases.

More and more Azure resource roles are handed out as PIM-eligible rather than standing: you hold the role only after you activate it, for a time-boxed window, with a justification. That activation is a multi-step REST dance against Azure Resource Manager - enumerate what you are eligible for, file a self-activation request, then poll until it provisions - and there is no native az command for activating an eligible Azure resource role. So every working session starts with hand-rolled az rest calls or a third-party script before you can actually run anything.

Federal agencies, financial institutions, and healthcare organizations are often required to run only cryptography that's been validated against FIPS 140, the U.S. government's standard for approved algorithms and key sizes. For a command-line tool built on a general-purpose language runtime, meeting that bar has traditionally meant compiling against a separate validated crypto library, or simply hoping the runtime's own TLS and encryption code happens to stick to approved algorithms.

atmos git clone is Atmos's native replacement for actions/checkout. Mirroring the actions/checkout v7 hardening, it now refuses by default to clone untrusted fork content under the elevated pull_request_target and workflow_run events — the classic "pwn request" where fork code would run with your repository's secrets. A grep-able opt-in is available for the rare case you genuinely need it.

Security scanner hooks (Checkov, Trivy, KICS) can now surface findings as inline GitHub annotations on the pull request diff and upload them to GitHub Code Scanning (the Security tab) — natively, with no github/codeql-action step. Custom hooks running any SARIF-emitting tool get the same treatment by adding format: sarif.

Security scanner hooks (Checkov, Trivy, KICS) now write their findings to the GitHub Actions job step summary automatically — so scan results show up in the pipeline run instead of being buried in the atmos terraform plan log stream. The official Atmos Docker image was also updated so Checkov runs without a glibc error.

Atmos now has first-class secrets management: you declare the secrets each component depends on, provision their values per environment, and reference them at runtime with a single YAML function.

The atmos aws security analyze command is the native Atmos command for turning AWS security findings into infrastructure-aware remediation guidance. It reads findings from AWS Security Hub and Amazon Inspector, including Security Hub product findings from services such as AWS Config, GuardDuty, Macie, and IAM Access Analyzer, then uses Atmos component tags and mapping heuristics to connect affected resources back to the stacks and components that manage them.

Those mappings make findings more actionable: instead of stopping at an AWS resource ARN, Atmos can show the owning stack, component path, severity, source service, and remediation context. With new SARIF 2.1.0 and OCSF 1.4.0 output, those findings can now flow into code scanning, SIEM, governance, risk, and compliance workflows without a translation layer.

Atmos toolchain installs now verify downloaded packages before extraction when registry metadata provides checksums, signatures, or attestations.

Provably safe secrets masking with custom patterns, comprehensive output coverage, and configurable replacement strings.

Atmos now supports the aws/assume-root identity kind, enabling secure, centralized management of root access across your AWS Organization using the STS AssumeRoot API.

We've fixed a critical bug in how Atmos handles arguments passed to custom commands via {{ .TrailingArgs }}. This fix improves security and ensures whitespace and special characters are preserved correctly.

We're excited to introduce atmos auth shell, a new command that makes working with multiple cloud identities more secure.

This command launches isolated shell sessions scoped to specific cloud identities. Think of it like aws-vault exec, but for all your cloud identities managed by Atmos—AWS, Azure, GCP, GitHub, SAML, and more.

When you exit the shell, you return to your parent shell where those credentials were never present. It's a simple pattern that helps prevent credential leakage and reduces the risk of running commands against the wrong environment.

Atmos Auth supports flexible keyring backends, giving you control over how authentication credentials are stored. Use your system keyring for native OS integration, file-based keyrings to share credentials across OS boundaries (like between your Mac and a Docker container), or memory keyrings for testing.

We're excited to announce a new authentication command: atmos auth logout. This command provides secure, comprehensive cleanup of locally cached credentials, making it easy to switch between identities, end work sessions, and maintain proper security hygiene.