Which solution should be used to meet these requirements?
Encrypt the password using AWS KMS. Store the encrypted password in the buildspec.yml file as an environment variable under the variables mapping. Reference the environment variable to initiate scanning.
Import the password into an AWS CloudHSM key. Reference the CloudHSM key in the buildpec.yml file as an environment variable under the variables mapping. Reference the environment variable to initiate scanning.
Store the password in the AWS Systems Manager Parameter Store as a secure string. Add the Parameter Store key to the buildspec.yml file as an environment variable under the parameter-store mapping. Reference the environment variable to initiate scanning.
Use the AWS Encryption SDK to encrypt the password and embed in the buildspec.yml file as a variable under the secrets mapping. Attach a policy to CodeBuild to enable access to the required decryption key.
Explanations:
Storing sensitive information, even if encrypted with AWS KMS, directly in thebuildspec.ymlfile as an environment variable exposes the sensitive data. This is not a secure practice.
AWS CloudHSM is an advanced option for cryptographic operations and is overkill for this use case. Storing a password in CloudHSM and referencing it inbuildspec.ymlis unnecessarily complex and does not fully align with AWS best practices for storing secrets securely.
Storing the password as a secure string in AWS Systems Manager Parameter Store ensures that the sensitive data is encrypted at rest and can be securely accessed by CodeBuild. Referencing the secure string in thebuildspec.ymlfile is a best practice for secret management in AWS.
The AWS Encryption SDK is a tool for client-side encryption, and embedding sensitive data in thebuildspec.ymlfile still poses a security risk. Additionally, managing encryption keys separately from AWS services like SSM Parameter Store introduces unnecessary complexity.