Mock ECR Enhanced Scan

[volphy]

Is mocking ECR Enhanced Scan supported?

It is not obvious for me when I look at the ECR implementation coverage:
https://github.com/getmoto/moto/blob/master/IMPLEMENTATION_COVERAGE.md#ecr

Looking at the Inspector2 implementation coverage:
https://github.com/getmoto/moto/blob/master/IMPLEMENTATION_COVERAGE.md#ecr

I am guessing that mocking ECR Enhanced Scan is not supported.

Am I correct?

[volphy]

Any ideas?

Shall I create a new GitHub issue?

[bblommers]

This is the right place for questions @volphy - I just hadn't gotten around to answering yet.

No, we don't support Enhanced Scan yet. The Inspector2 service currently does not return any Findings - it's up to users to configure custom responses. See https://docs.getmoto.org/en/latest/docs/services/inspector2.html

If you want to request this integration though, please open a Github Issue with some more information on how this works + how you see this working in Moto.

I'm not familiar with the feature at all, so I can't really say whether it makes sense/is feasible with how Moto works, but maybe we can work something out.

[volphy]

Thanks for pointing me in the right direction.

Let's analyze a specific example - official Docker image of Motoserver 5.0.28:
https://hub.docker.com/layers/motoserver/moto/5.0.28/images/sha256-4604c215c0cd190abc94ea2ec2f1d6eae7280b014f6c4e799448b100c2d48bc5

The results of the ECR Enhanced Scan look as follows:

{
    "imageScanFindings": {
        "enhancedFindings": [
            {
                "awsAccountId": "743601935287",
                "description": "When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain's cache entry, making it end sooner or later than otherwise intended. This affects curl using applications that enable HSTS and use URLs with the insecure `HTTP://` scheme and perform transfers with hosts like `x.example.com` as well as `example.com` where the first host is a subdomain of the second host. (The HSTS cache either needs to have been populated manually or there needs to have been previous HTTPS accesses done as the cache needs to have entries for the domains involved to trigger this problem.) When `x.example.com` responds with `Strict-Transport-Security:` headers, this bug can make the subdomain's expiry timeout *bleed over* and get set for the parent domain `example.com` in curl's HSTS cache. The result of a triggered bug is that HTTP accesses to `example.com` get converted to HTTPS for a different period of time than what was asked for by the origin server. If `example.com` for example stops supporti",
                "findingArn": "arn:aws:inspector2:eu-west-1:743601935287:finding/92ec736dde6c50c668cf5721027ae176",
                "firstObservedAt": "2025-02-03T10:59:46.445000+01:00",
                "lastObservedAt": "2025-02-03T10:59:46.445000+01:00",
                "packageVulnerabilityDetails": {
                    "cvss": [
                        {
                            "baseScore": 6.5,
                            "scoringVector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L",
                            "source": "NVD",
                            "version": "3.1"
                        }
                    ],
                    "referenceUrls": [
                        "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086804"
                    ],
                    "relatedVulnerabilities": [],
                    "source": "DEBIAN_CVE",
                    "sourceUrl": "https://security-tracker.debian.org/tracker/CVE-2024-9681",
                    "vendorSeverity": "not yet assigned",
                    "vulnerabilityId": "CVE-2024-9681",
                    "vulnerablePackages": [
                        {
                            "arch": "AMD64",
                            "epoch": 0,
                            "name": "curl",
                            "packageManager": "OS",
                            "release": "10+deb12u8",
                            "sourceLayerHash": "sha256:416e17e4fbb3912125a75f472458c684de6c08405c5c0d2221649b7feac4f78c",
                            "version": "7.88.1",
                            "fixedInVersion": "NotAvailable"
                        }
                    ]
                },
                "remediation": {
                    "recommendation": {
                        "text": "None Provided"
                    }
                },
                "resources": [
                    {
                        "details": {
                            "awsEcrContainerImage": {
                                "architecture": "amd64",
                                "imageHash": "sha256:9c7d02b8b260fa42b14a85cc1221f942f2029b5bf1132fc300ec479273406f5d",
                                "imageTags": [
                                    "5.0.28"
                                ],
                                "platform": "DEBIAN_12",
                                "pushedAt": "2025-02-03T10:59:31.148000+01:00",
                                "registry": "743601935287",
                                "repositoryName": "prod/cp/motoserver"
                            }
                        },
                        "id": "arn:aws:ecr:eu-west-1:743601935287:repository/prod/cp/motoserver/sha256:9c7d02b8b260fa42b14a85cc1221f942f2029b5bf1132fc300ec479273406f5d",
                        "tags": {},
                        "type": "AWS_ECR_CONTAINER_IMAGE"
                    }
                ],
                "score": 6.5,
                "scoreDetails": {
                    "cvss": {
                        "adjustments": [],
                        "score": 6.5,
                        "scoreSource": "NVD",
                        "scoringVector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L",
                        "version": "3.1"
                    }
                },
                "severity": "MEDIUM",
                "status": "ACTIVE",
                "title": "CVE-2024-9681 - curl",
                "type": "PACKAGE_VULNERABILITY",
                "updatedAt": "2025-02-03T10:59:46.445000+01:00",
                "fixAvailable": "NO",
                "exploitAvailable": "NO"
            },
            {
                "awsAccountId": "743601935287",
                "description": "None Provided",
                "findingArn": "arn:aws:inspector2:eu-west-1:743601935287:finding/9ff1469a4702529c61a8f00661a27576",
                "firstObservedAt": "2025-02-03T10:59:46.445000+01:00",
                "lastObservedAt": "2025-02-03T10:59:46.445000+01:00",
                "packageVulnerabilityDetails": {
                    "cvss": [],
                    "referenceUrls": [
                        "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094730"
                    ],
                    "relatedVulnerabilities": [],
                    "source": "DEBIAN_CVE",
                    "sourceUrl": "https://security-tracker.debian.org/tracker/CVE-2025-24528",
                    "vendorSeverity": "not yet assigned",
                    "vulnerabilityId": "CVE-2025-24528",
                    "vulnerablePackages": [
                        {
                            "arch": "AMD64",
                            "epoch": 0,
                            "name": "krb5",
                            "packageManager": "OS",
                            "release": "2+deb12u2",
                            "sourceLayerHash": "sha256:951ef04389205caf59aa51717bdd03e0765e97a42bd488de11ebe7b05db2b525",
                            "version": "1.20.1",
                            "fixedInVersion": "NotAvailable"
                        }
                    ]
                },
                "remediation": {
                    "recommendation": {
                        "text": "None Provided"
                    }
                },
                "resources": [
                    {
                        "details": {
                            "awsEcrContainerImage": {
                                "architecture": "amd64",
                                "imageHash": "sha256:9c7d02b8b260fa42b14a85cc1221f942f2029b5bf1132fc300ec479273406f5d",
                                "imageTags": [
                                    "5.0.28"
                                ],
                                "platform": "DEBIAN_12",
                                "pushedAt": "2025-02-03T10:59:31.148000+01:00",
                                "registry": "743601935287",
                                "repositoryName": "prod/cp/motoserver"
                            }
                        },
                        "id": "arn:aws:ecr:eu-west-1:743601935287:repository/prod/cp/motoserver/sha256:9c7d02b8b260fa42b14a85cc1221f942f2029b5bf1132fc300ec479273406f5d",
                        "tags": {},
                        "type": "AWS_ECR_CONTAINER_IMAGE"
                    }
                ],
                "score": 0.0,
                "severity": "UNTRIAGED",
                "status": "ACTIVE",
                "title": "CVE-2025-24528 - krb5",
                "type": "PACKAGE_VULNERABILITY",
                "updatedAt": "2025-02-03T10:59:46.445000+01:00",
                "fixAvailable": "NO",
                "exploitAvailable": "NO"
            }
        ],
        "imageScanCompletedAt": "2025-02-03T10:59:46.445000+01:00",
        "vulnerabilitySourceUpdatedAt": "2025-02-03T10:59:46.445000+01:00",
        "findingSeverityCounts": {
            "MEDIUM": 1,
            "UNTRIAGED": 1
        }
    },
    "registryId": "743601935287",
    "repositoryName": "prod/cp/motoserver",
    "imageId": {
        "imageDigest": "sha256:9c7d02b8b260fa42b14a85cc1221f942f2029b5bf1132fc300ec479273406f5d",
        "imageTag": "5.0.28"
    },
    "imageScanStatus": {
        "status": "COMPLETE",
        "description": "The scan was completed successfully."
    }
}


How should I mock the above-mentioned scan result using a mocked Inspector2 client?

[volphy]

Any ideas?

[bblommers]

Let me see if I understand the scenario first:

1. First an image is uploaded to ECR
2. Scanning is enabled on that registry (using put_registry_scanning_configuration)
3. The scan results (that you posted here) are then available from ECR::describe_image_scan_findings

I'm assuming this is correct (if simplified) - please call out anything I've missed.

So far this is all contained to ECR itself, so I'm a little confused why Inspector2 is mentioned in the docs.

Two questions:

1. Can you see the same results when calling Inspector2::list_findings in AWS itself?

2. Do you use ECR:describe_image_scan_findings in your application, or Inspector2 (or both)?

[volphy]

Let me start from explaining my production scenario:

1. ECR Private Registry is configured to scan-on-push using ECR Enhanced Scan
2. Docker image is pushed to one of ECR Repositories in the ECR Private Registry
3. Lambda function is triggered
4. That Lambda function waits until the results of ECR Enhanced Scan is complete
5. As soon as the scan result are ready, the Lambda function looks at critical and high severity vulnerabilities
6. if critical/high severity vulnerabilities found, interested parties are informed

My test scenario I would like to achieve (simplified a bit as compared to the production scenario):
1. ECR Private Registry is configured to scan manually using ECR Enhanced Scan
2. Docker image is pushed to one of ECR Repositories in the ECR Private Registry
3. Scan of the newly pushed Docker image is invoked
4. As soon as the results of the scan are available, critical/high severity vulnerabilities are looked for
5. If found, interested partied are informed

For the purpose of testing, I am fine with slight deviations of test scenario as compared to production scenario (see marked points above).

In my production code I do not call Inspector2 explictly.

I call 'ecr.describe_image_scan_findings' via its paginator:
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecr/paginator/DescribeImageScanFindings.html

In order to test both positive (test-to-pass) and negative (test-to-fail) scenario I would like to be able to mock results that are returned by 'ecr.describe_image_scan_findings'. Ideally, I would like to be able to mock the results returned by describe_image_scan_findings paginator.

[volphy]

@bblommers
Any ideas?

[volphy]

As expected (see CHANGELOG.md) the issue still persist in 5.1.1.

[bblommers]

Moto 5.1.2 now exposes an API to configure the results of ECR describe_image_scan_findings. Please see the documentation for more information:
https://docs.getmoto.org/en/latest/docs/services/ecr.html

A more complete example can be found here, in our internal tests:
https://github.com/getmoto/moto/blob/master/tests/test_ecr/test_ecr_scan_results.py