We should have a way to detemine whether secrets used in codebase actually exist and are accessible

[forabi]

Non-existent or inaccessible secrets are one example of something that could cause runtime errors. We should have some way to check whether secrets accessed in codebase:

• actually exist
• are accessible by the IAM execution role used in the corresponding Lambda

Here's how I think it would work:

• We create a custom ESLint/TSLint rule
• The rule scans the code AST for calls to readAwsSecretStringForStage('<secretName>') or similar calls.
• It checks if <stage>/<secretName> exists (this of course requires AWS credentials)
• It also reads serverless.yml to check for permissions required to access this secret. This can be done statically (no access to AWS is required).

About a month a go, I gave this a try using a custom TSLint rule but the code was too complex. It felt like TSLint does not provider high-level helpers to scan the AST. ESLint, on the other hand, seems to do a better job at this.

This might be a huge time investment for relatively little gain so I'm going to label this as "impact: low", "difficulty: medium".

[forabi]

I gave this a try today with ESLint. The code is not complicated at all but it seems like ESLint does support asynchronous rules. We need to use async functions to fetch the list of secrets, but that just does not seem like something ESLint is designed for. We might have a better luck just parsing the AST with the same tools that ESLint uses internally and having a simple script on CI to check the used secret names against a list of secrets that gets fetched on CI.

[wholesomedev]

We need to use async functions to fetch the list of secrets, but that just does not seem like something ESLint is designed for. We might have a better luck just parsing the AST with the same tools that ESLint uses internally and having a simple script on CI to check the used secret names against a list of secrets that gets fetched on CI.

That sounds like a reasonable solution 👍