False Positive: aws_compliance.control.foundational_security_lambda_2 : recently added runtimes trigger an alarm

[m-rieke]

Describe the bug The control control.foundational_security_lambda_2 checks whether the Lambda function settings for runtimes match the expected values set for the supported runtimes for each language. The control fails if a Lambda function doesn't use a supported runtime.

For recently added runtimes the lambda consider this as alarm.

Powerpipe version (powerpipe -v) v0.1.3

Steampipe version (steampipe -v) v0.21.8

Plugin version (steampipe plugin list) v0.134.0

To reproduce Create a new lambda in AWS account using nodejs20.x runtime.

Afterwards check it with steampipe: steampipe check aws_compliance.control.foundational_security_lambda_2

ALARM: ExampleLambda uses nodejs20.x which is not the latest version.

According to https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html this runtime should be considered as latest. There are also other runtimes missing comparing the AWS website to the list here

Expected behavior Runtimes will be added continuously from amazon. Currently there is no easy way to distinguish a known runtime (aside it should be considered as latest or deprecated) or an unknown one ( maybe a recently added runtime).

In case of an unknown runtime I expected to get an error.

[m-rieke]

I created a PR for fixing this bug: https://github.com/turbot/steampipe-mod-aws-compliance/pull/780

[khushboo9024]

@m-rieke Thanks a lot for catching this bug and raising the PR. It has already been merged in PR and we will be releasing it shortly.

[m-rieke]

Thanks! My apologies, that I forgot to update the description for control and documentation. What about my suggestion to differentiate between state 'alarm' for known deprecated runtimes and 'error' for not listed (so unknown) runtimes. In current situation it will always produce an alarm for newly released runtimes. Especially for reporting the current situation is not optimal, because you might have to scroll through the list of reported lambdas and have to filter out recently released runtimes yourself.

Next time in November for python 3.12 and nodejs 22. Is there any reason why these should not be added to the list right now ? (ruby 3.3 was added to the list even it was not yet released)

[khushboo9024]

@ m-rieke. We understand your concern. This is a FSBP-specific control, and we strictly adhere to the default runtime parameters outlined in the FSBP documentation. According to the documentation, all the latest released runtimes are listed. As far as the new Python 3.13 and Node.js 22 releases are concerned, they have not been released yet. Once they are released, the FSBP documentation will be updated, and so will our control. Please let us know if you have any other questions or concerns. Thanks !!

[m-rieke]

Thanks for your reply! I am fully fine to list only the runtimes from FSBP documentation. I thought it would make sense to list them for being prepared, when they will be released. (see here )

I am more concerned that currently a ALARM is been reported in case a runtime is not known: In November python 3.12 and nodejs 22 will be released for lambda and at this time the control will report an ALARM, because the runtime is not listed in the list of valid runtimes. This will be a False Positive again (until the query is updated, there is a new release AND the user updated as well).

In Documentation the error state is described as:

Used when an error has occurred in calculating the control state.

In my view this state is more meaningful in this case and it makes sense to differentiate between known runtimes (latest and deprecated) and unknown runtimes (= newly released runtimes) . For last ones I expect an error instead of an alarm.

The reason, why I am reporting this: We used an automatic reporting forcing our developers to fix selected controls in ALARM state. This causes some frustration, because the reported reason didn't fit, because the runtimes were newer than the listed latest ones.

[khushboo9024]

@m-rieke Apologies for being silent on this for so long. We understand your concern. What we can do instead of setting it to an error state is to set it to an info state. Please see the updated query below and let us know if this works for you.

select
  arn as resource,
  case
    when package_type <> 'Zip' then 'skip'
    when runtime in ('nodejs20.x', 'nodejs18.x', 'nodejs16.x', 'python3.12', 'python3.11', 'python3.10', 'python3.9', 'python3.8', 'ruby3.3', 'ruby3.2', 'java21', 'java17', 'java11', 'java8.al2', 'dotnet8', 'dotnet6') then 'ok'
    when runtime in ('java8', 'go1.x', 'provided', 'ruby2.7', 'nodejs14.x', 'python3.7', 'dotnetcore3.1', 'nodejs12.x', 'python3.6', 'dotnet5.0', 'dotnetcore2.1', 'nodejs10.x', 'ruby2.5', 'python2.7', 'nodejs8.10', 'nodejs4.3', 'nodejs4.3-edge', 'nodejs6.10', 'dotnetcore1.0', 'dotnetcore2.0', 'nodejs') then 'alarm'
    else 'info'
  end as status,
  case
    when package_type <> 'Zip' then title || ' package type is ' || package_type || '.'
    when runtime in ('nodejs20.x', 'nodejs18.x', 'nodejs16.x', 'python3.12', 'python3.11', 'python3.10', 'python3.9', 'python3.8', 'ruby3.3', 'ruby3.2', 'java21', 'java17', 'java11', 'java8.al2', 'dotnet8', 'dotnet6') then title || ' uses latest runtime - ' || runtime || '.'
    when runtime in ('java8', 'go1.x', 'provided', 'ruby2.7', 'nodejs14.x', 'python3.7', 'dotnetcore3.1', 'nodejs12.x', 'python3.6', 'dotnet5.0', 'dotnetcore2.1', 'nodejs10.x', 'ruby2.5', 'python2.7', 'nodejs8.10', 'nodejs4.3', 'nodejs4.3-edge', 'nodejs6.10', 'dotnetcore1.0', 'dotnetcore2.0', 'nodejs') then title || ' uses ' || runtime || ' which is not the latest version.'
    else title || ' uses runtime' || runtime || ' which is yet to be released.'
  end as reason
  ${local.tag_dimensions_sql}
  ${local.common_dimensions_sql}
from
  aws_lambda_function;

[m-rieke]

thanks for replying! Info state would be fine in our case as we are updating steampipe/powerpipe frequently. Hopefully the list will still be updated frequently, because there will be no error anymore for newer runtimes (and INFO states are often ignored in day2day business....)

[e-gineer]

Could we at least move the runtime list(s) out to be a variable(s)?

Then we have options:

1. Mod should update the default variable regularly to be accurate and timely.
2. Users can always modify the variable if waiting for a mod release (or wanting to customize the rules).

[khushboo9024]

@e-gineer, thank you for your suggestion. We've incorporated variable support for the Lambda runtime into the control lambda_function_use_latest_runtime in the pull request.

@m-rieke, could you please take a look at it to see if it meets your expectations? Thank you!

[m-rieke]

Looks great. Thanks for solving my issue.

[misraved]

This issue has been addressed in https://github.com/turbot/steampipe-mod-aws-compliance/pull/791

Thanks @m-rieke for all the help 👍 !!