18 posts tagged with "Security"

Most security findings are fixed with a patch or minor release of the affected dependency. Some need a major version upgrade instead: when a dependency's major release line stops being maintained, its CVEs stay open forever, and every project that pulls it in inherits them. That is where Atmos was: the template engine it embeds, Gomplate, had moved on from the release line Atmos used, and that line depended on the AWS SDK for Go v1, which has reached end of support and carries CVEs no v1 release will ever fix. Atmos never executed the affected code, but no patch or minor release could clear the findings. The CVEs forced our hand: the template engine now runs on Gomplate v5, two major versions ahead, and the end-of-life SDK is gone from the Atmos build entirely.

Structured secrets rarely agree on a single field name, and an ambient Vault token can silently cross an authentication boundary. That combination forces teams to reshape secret documents or wrap Atmos just to pass one short-lived credential into another identity.

Tools often need API tokens from a secret store as environment variables. Copying those values into shell profiles duplicates credentials and makes rotation harder. The official auth-secrets plugin lets an Atmos identity read the configured store and select exactly which values a command receives.

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.