# {{packName}} >*Disclaimer:* *Security and Compliance is a shared responsibility between AWS and the customer. The topics discussed in this document fall on the customer side of the [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/). The supplied rule pack is not comprehensive in declaring the security posture of the code in which it validates; it is but one tool that can be used in the development cycle to increase the confidence of the baseline security of what you are building. Note that the provided information and resources are non-contextual to your workload, use case or your security and compliance goals.* The AWS Prototyping team aim to rapidly assess the viability of solving new and novel business problems for customers using AWS technology. This means that sometimes the prototype is discarded, and others it forms the starting point for the actual workload. A prototype is not a production-grade system, but an enablement tool to catalyse innovation and drive decision making, helping to provide confidence to decision makers that “this is possible” allowing them to start a program of work to build for a production state. A security program for prototyping is multi-faceted, covering people, process and technology that is optimised for the typical prototyping delivery velocity - which is typically in days or weeks. The aim is to make the job of builders easier by using automation, alongside a trusted security subject-matter expert review, to ensure that a prototype meets an organisation’s security bar. Automation that aids the end-to-end prototyping process can include: vending dedicated AWS accounts that have security guardrails built in, using Infrastructure-as-code (IaC) constructs with pragmatic security defaults, automated static analysis of source code and/or IaC linting. IaC linting assists by checking for a set of *potentially* undesirable configuration states, the results of these atomic checks help give developers feedback early in the development cycle on non-contextual configurations that *may* require addressing. In addition, it can aid in communication between developers and security reviewers by guiding the creation of [suppression rules](https://github.com/cdklabs/cdk-nag#suppressing-a-rule) that can be reviewed in the context of the prototype goals during the human security review process. Given the rapid development cycle and that prototypes are not intended for production deployment, certain configuration states relating to operational concerns such as high-availability or observability could be deprioritised (unless they are a key proof point of the prototype) in favour of putting a stronger focus on risks associated with prototyping code that may lack the equivalent depth of security oversight typically associated with production code (e.g. extensive threat modeling, high test coverage, human-led penetration testing). In these scenarios, likelihood of a risk eventuating can be greatly reduced by reducing the exposed attack surface of a prototype to an internet based actor, particular for non-targeted attacks. The AwsPrototyping NagPack has been designed including specific [CDK_nag rules](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md) with the aim of a prioritising attack surface reduction and check for misconfigurations that expose data directly to internet based actors; and a reduced focus on operational concerns typically associated with production systems - e.g. Multi-AZ RDS deployments, logging etc. The *goal* is that the rules that are at the `ERROR` level are intended to occur very rarely and require suppression rules to be written, whilst those at the `WARNING` level have a higher likelihood of requiring additional human derived context to determine whether they should be fixed, or suppressed given that there is a valid use case. The AwsPrototyping NagPack has not been designed with specific prototype goals and security requirements in mind. It should be evaluated and modified to best suit your use case, and you should consider the various stages of the software development lifecycle and the data that is available during each phase. Any findings generated by applying the NagPack should have a trusted security subject-matter expert review and interpret them whilst taking into account organisational and project context. ## How to use it ### PDK users If you use the release >= [0.12.17](https://github.com/aws/aws-prototyping-sdk/releases/tag/v0.12.17) of PDK, you can opt into using the AwsPrototyping pack as follows: ``` import { AwsPrototypingChecks } from "@aws-prototyping-sdk/pdk-nag"; const app = PDKNag.app({ nagPacks: [new AwsPrototypingChecks()] }); // Create stacks ``` ### CDK users If you are not using PDK, but are using CDK you can import the Pack into your CDK project as follows: 1. Install the dependency on pdk-nag. ``` # Installation via yarn yarn add @aws-prototyping-sdk/pdk-nag # Installation via npm npm install @aws-prototyping-sdk/pdk-nag ``` 2. Instrument the lint pack into your application. ``` import { AwsPrototypingChecks } from "@aws-prototyping-sdk/pdk-nag"; const app = new cdk.App(); Aspects.of(app).add(new AwsPrototypingChecks()); // Create stacks ``` ### Suppressing rules To suppress rule violations, use the `NagSuppressions.*` methods. Please refer to the cdk-nag [README](https://github.com/cdklabs/cdk-nag#suppressing-a-rule) for examples. ## Rules {{#sections}} ### {{sectionTitle}} Total: `{{rules.length}}` | Rule ID | Cause | Explanation | | ------------------ | ------------------ | ------------------ | {{#rules}} | {{rule.name}} | {{{info}}} | {{{explanation}}} | {{/rules}} {{/sections}}