Skip to main content

⭐ Repository β†’ πŸ“ Compliance Engine β†’ πŸ“ CloudAware β†’ πŸ“ AWS β†’ πŸ“ ECR

πŸ›‘οΈ AWS ECR Repository Manual Scanning is enabled🟒

  • Contextual name: πŸ›‘οΈ Repository Manual Scanning is enabled🟒
  • ID: /ce/ca/aws/ecr/disable-repository-manual-scanning
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Logic​

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
βœ‰οΈ dec-x-7f041b041

Description​

Open File

Description​

This policy identifies AWS ECR Repositories configured with manual vulnerability scanning. To ensure automated timely detection of security vulnerabilities, it is recommended to enable either Scan on Push or Continuous Scanning.

Rationale​

Automated vulnerability scanning is a critical security control in containerized environments. By scanning images immediately when they are pushed to the registry, security flaws can be detected and remediated early in the development lifecycle. This reduces the likelihood of vulnerable images being deployed to production.

Impact​

Relying on manual scanning increases the risk of deploying container images with known vulnerabilities. If exploited, these flaws could result in security breaches, data exposure, or compromise of systems running the affected containers.

Audit​

This policy flags an AWS ECR Repository as INCOMPLIANT if the Scanning Configuration Rules JSON of the associated ECR Registry does not include any rules enabling either Scan on Push or Enhanced Scanning, indicating that only manual scanning is configured.

Remediation​

Open File

Remediation​

To ensure continuous vulnerability scanning, configure your Amazon ECR registry to use either Scan on Push or Continuous Scanning. This helps ensure that container images are scanned automatically, reducing the likelihood of deploying vulnerable images.

Disable Manual Scanning​

From AWS CLI​

Enable Basic scanning with Scan on Push:

aws ecr put-registry-scanning-configuration \
--scan-type BASIC \
--rules '[{"scanFrequency":"SCAN_ON_PUSH","repositoryFilters":[{"filter":"*","filterType":"WILDCARD"}]}]'

Enable Enhanced scanning with Continuous Scanning:

aws ecr put-registry-scanning-configuration \
--scan-type ENHANCED \
--rules '[{"scanFrequency":"CONTINUOUS_SCAN","repositoryFilters":[{"filter":"*","filterType":"WILDCARD"}]}]'

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
πŸ’Ό AWS Foundational Security Best Practices v1.0.0 β†’ πŸ’Ό [ECR.1] ECR private repositories should have image scanning configured11no data
πŸ’Ό Cloudaware Framework β†’ πŸ’Ό Threat Protection28no data
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό RA-5 Vulnerability Monitoring and Scanning (L)(M)(H)678no data
πŸ’Ό FedRAMP Low Security Controls β†’ πŸ’Ό RA-5 Vulnerability Monitoring and Scanning (L)(M)(H)28no data
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό RA-5 Vulnerability Monitoring and Scanning (L)(M)(H)48no data
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό GV.SC-10: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement1no data
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό ID.IM-01: Improvements are identified from evaluations21no data
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό ID.IM-02: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties34no data
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities35no data
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό ID.RA-01: Vulnerabilities in assets are identified, validated, and recorded27no data
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό ID.RA-08: Processes for receiving, analyzing, and responding to vulnerability disclosures are established1no data
πŸ’Ό NIST SP 800-53 Revision 5 β†’ πŸ’Ό RA-5 Vulnerability Monitoring and Scanning111no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.2 Buffer overflows.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.3 Insecure cryptographic storage.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.4 Insecure communications.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.5 Improper error handling.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.6 All β€œhigh risk” vulnerabilities identified in the vulnerability identification process.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.7 Cross-site scripting (XSS).1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.8 Improper access control.1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.9 Cross-site request forgery (CSRF).1no data
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 6.5.10 Broken authentication and session management.1no data
πŸ’Ό PCI DSS v4.0.1 β†’ πŸ’Ό 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities.11no data
πŸ’Ό PCI DSS v4.0.1 β†’ πŸ’Ό 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices reviewed and approved by management prior to release.1no data
πŸ’Ό PCI DSS v4.0.1 β†’ πŸ’Ό 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software.1no data
πŸ’Ό PCI DSS v4.0 β†’ πŸ’Ό 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities.11no data
πŸ’Ό PCI DSS v4.0 β†’ πŸ’Ό 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices reviewed and approved by management prior to release.1no data
πŸ’Ό PCI DSS v4.0 β†’ πŸ’Ό 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software.1no data