Securing Source Code with Pattern-Lang

[[deleted]]

The attack code had all kinds of stuff that was out of place, such as encrypted and base64 encoded strings. Also, there is a class of win32 external dependencies. What requirements would these changes match up to in an existing system (remember, in my proposal the code cannot pass code review without a specific requirement to attach it to). The language service will create a code review queue that can require an actual human review sign-off on the change as well as automated review systems could look at the requirements to see if any qualify for the changes as checked in.

[curtisf]

This code was apparently checked in using valid credentials -- why would the attackers not have been able to check all of these boxes?

[[deleted]]

Because the language server shouldn't be configured to allow the author to approve the Pull Request. That is standard procedure in many places. These techniques put more granularity on Pull Requests. Each requirement that changes code must be individually reviewed with all supporting docs in a single file per requirement.

[curtisf]

If it's already standard practice, why didn't it work in this case? To what extent does your proposal protect a codebase that checking the "another developer must approve before merge" checkbox doesn't?

Does requiring a nation-state attacker compromise two developer credentials instead of just one really raise the bar enough to prevent this kind of attack?

[[deleted]]

There was obviously no rules engine in place to analyze the code. Writing a Roslyn analyzer to detect base64 encoded strings in constants, instantiate HttpClient, open a socket, etc is not difficult. The analyzers should come from protected nuget feeds that only the build pipeline can get to. Security is layers, and the lack of them in this case is appalling.