Security

Reporting Security Issues

To report a potential security issue in the Nx Plugin for AWS itself, please refer to SECURITY.md — do not create a public GitHub issue.

Security Controls

Projects scaffolded by the Nx Plugin for AWS include a number of security controls out of the box. This page provides an overview of those controls and links to the relevant guides for more detail.

Infrastructure Scanning

Infrastructure projects are configured with Checkov as part of the build target, so insecure infrastructure configuration fails the build:

• CDK projects synthesize CloudFormation templates which are scanned by Checkov. See Security Testing for details.
• Terraform projects run Checkov directly against your Terraform code. See Terraform Projects.

Where vended infrastructure suppresses a Checkov rule, the suppression is scoped to the specific resource and annotated with a justification. The shared suppressRules helper requires a reason for every suppression, and we recommend following the same practice in your own code. See Suppressing Checkov Checks.

Container Image Scanning

Projects which build container images (for example agents, MCP servers, and database migration images) include a trivy target which scans images for HIGH and CRITICAL vulnerabilities before they are deployed, failing the build on findings. See Docker Bundling for details, including how to suppress findings with a .trivyignore file.

Credential Scanning

Workspaces include git-secrets pre-commit hooks which scan staged files for AWS credential patterns, preventing accidental commits of access keys and other sensitive values. See the Git Secrets section of the workspace guide.

Authentication

APIs, agents, and MCP servers use AWS IAM (SigV4) authentication by default:

• tRPC, FastAPI, and Smithy APIs default to IAM authentication, with Cognito and custom authorizers available as options. The vended custom authorizer stub denies requests by default.
• Agents and MCP servers deployed to Amazon Bedrock AgentCore Runtime use IAM (SigV4) authentication by default, with JWT-based Cognito authentication as an option.
• The website auth generator vends an Amazon Cognito user pool with multi-factor authentication (MFA) required, a strong password policy, and deletion protection enabled.

Encryption

Vended infrastructure encrypts data in transit and at rest:

• Websites are served via CloudFront with HTTP redirected to HTTPS, and a response headers policy including HTTP Strict Transport Security (HSTS), a Content Security Policy, and other security headers. A WAF with AWS managed rules is associated with the distribution.
• S3 buckets block all public access, enforce SSL-only access via bucket policies, are encrypted (KMS with key rotation for website content), and deliver server access logs to CloudWatch log groups encrypted with customer-managed KMS keys, where they can be queried with Logs Insights and alarmed on.
• API access logs are written to CloudWatch log groups encrypted with customer-managed KMS keys with rotation enabled.
• Aurora databases enable storage encryption with a customer-managed KMS key, generate credentials in AWS Secrets Manager (never hardcoded), and support automatic credential rotation.

Least Privilege

Vended CDK constructs and Terraform modules follow least privilege:

• Constructs expose grant* methods (for example grantInvokeAccess on APIs and agents, grantConnect on databases) so consumers grant only the access they need.
• IAM policies in vended infrastructure are scoped to specific resources and actions. Where a wildcard resource is required by the AWS service (for example ecr:GetAuthorizationToken), it is limited to those actions and scoped with conditions where supported.

Dependency Licensing

The license generator configures automated license header management and dependency license checking against an allowlist of approved licenses, helping you catch problematic transitive dependencies before they ship.

Responsibility

Security and compliance is a shared responsibility. AWS describes this through the Shared Responsibility Model, which distinguishes between security of the cloud (the responsibility of AWS) and security in the cloud (your responsibility as the customer).

The Nx Plugin for AWS helps you address parts of your side of that model. Its generators vend secure foundations and encode AWS best practices within the scope of the code they produce — the controls described above. This reduces the effort required to build securely, but it does not transfer ownership of security to the plugin.

You own the code that is generated into your workspace and remain responsible for its security. Once vended, generated code is yours to modify, extend, and operate, and it must be treated the same as any other code you author.

In particular:

• The scope of the plugin is limited to its generators. The plugin has no knowledge of your application’s business logic, data classification, threat model, or regulatory obligations, and cannot make decisions that depend on them.
• Authentication is configured, but authorization is not. APIs are protected with authentication by default (for example IAM/SigV4), but the plugin cannot determine which authenticated principals should be permitted to perform which operations on which resources. Fine-grained authorization depends on your business logic and must be designed, implemented, and tested by you.
• Generated code is a starting point, not a finished product. As you add functionality, you introduce security considerations the plugin cannot anticipate — input validation, data handling, secrets management, dependency choices, and integrations with other systems.

Accordingly, you should review generated code and the applications you build on top of it in line with your own organisation’s security policies, standards, and review processes, and subject them to the same threat modelling, security testing, and approval gates you apply to any production workload. The controls vended by the plugin are intended to complement those processes, not to replace them.