GitHub CI/CD could be subverted to reveal PII and secrets

[JFWooten4]

Access, managing IAM workflows, and documentation are all on GitHub. They are the production behavior of our systems and can be amended through pull requests.

A critical example of this attack is changing a public API endpoint from its Gateway Lambda handler to cease using its team authorizer. That, or just return a new function call which returns information the handler processes but does not return.

It should be easy to see when this happens, since it'd need to be in the return stream, presuming call logging stays unpublished. But there's the risk of subtle weakness injection by modifying complex arithmetic like hashing, which could hide rainbow-tree-able customer information.

[JFWooten4]

Right now we don't have the Codex connector or even Copilot set up to automatically review PRs in the API repos. A possible mitigating step could be to configure that with explicit instructions to highlight any changes which touch secrets or the legacy/PII databases.

We could also look into custom socket bots that examine function dependency or authorizer changes. This would make it easier to efficiently review PRs and keep collaboration default-open.

I've tried to minimize the reviewability burden and injection risk by keeping the functions and endpoints as small and simple as possible. I have also actively axed operating handlers in the past which exceeded a reasonable couple hundred lines of code.

[JFWooten4]

AWS has their own centralized version of this through GuardDuty and Inspector, which run on the Lambda functions themselves. The ops here can extend to API Gateway logs (and anything else from CloudWatch) under their Security Hub. Unsurprisingly, that product feeds into their "Security Incident Response" service.

Those would be really good options if we used a proprietary internal codebase, or had a much larger reliance on foreign package imports. Thankfully, right now the only thing we rely on heavily is the stellar-sdk from Overcat as a Python Lambda layer. But I don't think they entirely align with our open-source standards and usage values, exemplified in the move away from Persona as a proprietary service provider.

Don't get me wrong, these six or so AWS products are incredibly cheap, if not free in almost half the cases, for very generous usage. For me, it's a question of whether we put our time, efforts, and attention into the "internal" AWS setup, which only a few can manage, or whether we force towards more collaborative tools. I'd rather get half the quality and twice the cost if it means a GitHub app that sparked further member participation, since the diverse views of humans are really what'll make our design flow stand above... the other orgs building capital markets.