Create obligatron mode for AWS infrastructure vulnerabilities

[NovemberTang]

What does this change

Creates a new obligatron mode that collects information about AWS infrastructure vulnerabilities. Currently, it only logs the output and does not write to the table. This is because we are currently not filtering out results that are within SLA. This will need to be done as a separate PR as further work is needed to unify:

1. the various Severity types
2. the calculations we perform on those types to calculate whether a resource is inside or outside SLA

So, that work will be done as a follow up PR. At that point, we will start writing to the DB

Why?

So we can track departmental progress against our obligation to keep our AWS infrastructure compliant with AWS FSBP

How has it been verified?

Verified locally. Added unit tests to confirm expected behaviour

[github-actions]

Deploy build 5626 of deploy::service-catalogue to CODE

All deployment options

• Deploy build 5626 of deploy::service-catalogue to CODE
• Deploy parts of build 5626 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[akash1810]

If these severities were passed via configuration, would it make local development easier?

[NovemberTang]

why would it make local development easier?

[akash1810]

Was thinking of this within cloudbuster

service-catalogue/packages/cloudbuster/src/config.ts

Lines 29 to 31 in eb35b3e

	const severities: SecurityHubSeverity[] = isDev
	? ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW', 'INFORMATION'] // Using all severities in DEV for more data.
	: ['CRITICAL', 'HIGH'];

.

[AshCorr]

This feels like a bit of a spooky typecast! Are we sure that our schema will always match AWSs? Could lead to some annoying to debug errors if not!

We're quite explicit with type checking in the TAGGING job (maybe too much!), I wonder if we could have any shared behaviour for checking the schema matches?

service-catalogue/packages/obligatron/src/obligations/tagging.ts

Lines 40 to 44 in ba13195

	const isFindingResource = (resource: unknown): resource is FindingResource =>
	typeof resource === 'object' &&
	resource != null &&
	'Id' in resource &&
	'Tags' in resource;

[NovemberTang]

as unknown as <CUSTOM TYPE> is a pretty common pattern across the service catalogue, especially in repocop. If we want to move away from it, could that be a separate piece of work?