Add support for Blueprints

[stevespringett]

A BOM is not overly useful to defenders as they only contain inventory of things and potentially how something was built (e.g. formulation). They do not provide any insight into what the application does or how it does it, which is extremely useful for defending assets.

This proposed core enhancement is to track the support for adding blueprints. The general idea of blueprints is to describe at a high/abstract level, what the application does and the process of how it does it. If done correctly, defense can be automated.

[dariush-griffin]

Can you further define some examples of blueprints? I'm interested in how they could be automated. My initial reaction is that the SBOM includes information in how it is deployed or perhaps lists that it follows certain protocols or has certain WAF rules which would negate a subset of vulnerabilities.

Or we could apply the reverse. When we detect certain vulnerabilities, suggest certain actions that could be recorded in the blueprint.

Is that in line with what you are thinking?

[stevespringett]

1. Take a microservice which takes input via HTTPs, processes it, and persists it to a relational database.
2. That same microservice uses a vulnerable version of log4j.

In this example, CycloneDX described the blueprint of what the application does (1) and what the application contains (2).

Upon analyzing the BOM, it was discovered that input validation was not being performed prior to processing or persisting the data. Therefore, a WAF is automatically deployed with specific rules to guard against malicious input designed to exploit log4j.

I think that's a simple example, but there are likely many more real-world examples we could come up with, some of which may involve changing the configuration of the application itself. But yes, I think we're thinking along the same lines. Runtime platforms that leverage instrumentation may be a good way to capture what the application does in an automated way. @planetlevel

[planetlevel]

Capturing details about what software actually does and how it works can be done with static, runtime, or both. Generally, I'd like to see the blueprint capture 1) the attack surface (entry points both public and internal), 2) security defenses like authn, authz, encryption, escaping, etc...3) dangerous functions (not vulnerabilities), like parsing XML, evaluating expressions, querying databases, starting processes, etc... 4) all connections inbound and outbound.

[smagill]

Interesting idea. Sounds similar to the goals of the DARPA E-BOSS program. Maybe there will be some opportunity for collaboration there.

[planetlevel]

E-BOSS sounds like RASP to me.  Great idea and everyone should use it.  But I think of this effort as capturing an app/API security architecture for use in activities like threat modeling, pentesting, risk rating, and incident response.  Basically everything in appsec is easier and faster with a detailed blueprint.—JeffOn May 14, 2024, at 5:04 PM, Stephen Magill ***@***.***> wrote: Interesting idea. Sounds similar to the goals of the DARPA E-BOSS program. Maybe there will be some opportunity for collaboration there. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jkowalleck]

#670 (comment)

This [#670] may tie into the work in #463 where we're describing behavior.