Support evidence for services

[prabhu]

Like components, services can be detected by generator tools like cdxgen. All evidence, such as identity, occurrence, and call stack, can be presented for the detected services. The structure of evidence may have to change slightly to support a data array or specific data identified by name belonging to a service.

[stevespringett]

Can you provide a prototype of what this could theoretically look like?

[prabhu]

Let's assume the following java code, which creates an endpoint.

https://github.com/HooliCorp/vuln-spring/blob/master/src/main/java/com/example/vulnspring/WebController.java#L57

@PostMapping("/login")
public String login(HttpSession session, @RequestParam(name = "username", required = true) String username,
    @RequestParam(name = "password", required = true) String password, Model model) {
  if (loginSuccess(username, password)) {
      logger.debug("Login with: " + username + ":" + password); // Issue - password logged
      session.setAttribute("username", username);
      return "redirect:home";
  }
  logger.debug("Failed login for " + username);
  return "login";
}

Generator tools such as cdxgen can create an entry for services with the identified endpoint as shown:

With the proposed enhancement, the tool can offer the following evidences:

identity

How did the tool identify the service and the endpoints? In case of cdxgen, there is low confidence in the name but high confidence in the endpoints.

field	confidence	methods
services.name	low	source-code-analysis
services.endpoints	high	source-code-analysis

occurrences

The location where the service (bom-ref) and endpoints are defined.

src/main/java/com/example/vulnspring/WebController.java#L38 src/main/java/com/example/vulnspring/WebController.java#L57

callstack

Prove that this endpoint is reachable and allows pass-through.

[
{
  "package": "com.example.vulnspring",
  "module": "com.example.vulnspring.WebController",
  "function": "login",
  "parameters": ["session", "username", "password", "model"],
  "line": 58,
  "column": 0,
  "fullFilename": "src/main/java/com/example/vulnspring/WebController.java"
}
...
]

data

Does this service deal with any sensitive data?

[
{
  "flow": "inbound",
  "classification": "secret, credentials",
  "name": "password",
  "description": "Accepted by the service bom-ref / bom-link"
}
]

Oh, this service is dealing with passwords? Can you prove this with evidence?

identity

How did the tool identify that such sensitive data is being used?

Occurrences

Show the places where this data is used

Callstack

Show how the data flows through the application or service

[jkowalleck]

Let's assume the following java code, which creates an endpoint.

https://github.com/HooliCorp/vuln-spring/blob/master/src/main/java/com/example/vulnspring/WebController.java#L57

@PostMapping("/login")
public String login(HttpSession session, @RequestParam(name = "username", required = true) String username,
  @RequestParam(name = "password", required = true) String password, Model model) {
  if (loginSuccess(username, password)) {
    logger.debug("Login with: " + username + ":" + password); // Issue - password logged
    session.setAttribute("username", username);
    return "redirect:home";
  }
  logger.debug("Failed login for " + username);
  return "login";
}

Generator tools such as cdxgen can create an entry for services with the identified endpoint as shown:

I thought the purpose of bom.services is to show services that are consumed by something, not services that are provided by something. Usually a BOM describes ingredients, not the result. What am I missing?

PS: Services were introduced via #22

[prabhu]

@jkowalleck All services are eventually consumed by the parent component in the same bom or a different component/service in a different sbom. Plus we can detect external service invocations using the same technique so the need for evidence is the same.

Here are couple of examples for microservices repo:

https://github.com/OWASP/crAPI https://github.com/microservices-demo/microservices-demo

Here, a service created by one microservice is consumed by another. So the generator tool will create an entry first and then link to the dependencies based on consumption.

[jkowalleck]

The fact that you can detect an in-bound service makes still no reason to put it in the BOM. If you used CycloneDX for architectural documentation (not BOM), then you will have a hard time due to lack of features.

All services are eventually consumed by the parent component in the same bom [...]

These services are not part of the BOM, as they are no "ingredients" but they are the actual "product"

[...] or a different component/service in a different sbom.

These services need to be documented in the BOM of the "different product", where they are used/consumed/required.

[...] Plus we can detect external service invocations using the same technique so the need for evidence is the same.

This appears to be a good reason to add them to the BOM.

---

A out-bound service that you would consume is hosted somewhere, has an address/port and might even have wrapped security layers and trust zones. It is much more than an in-bound path, which also could be layered and rewritten. The out-bound service that you consume/provide is nothing like the in-bound thing a software like in your examples might provide. To stay at your examples: the only information you might have is that an in-bound thing accepts HTTP request to a certain path. Where is the actual address/ip, the access layers that might be added, the actual path including rewriting and all? I suspect false information being added to the BOM by dump assumptions on scanning source code wrong. I assume some information might not only be wrong, but some should bot be in a BOM at all. To check this, evidences are truly needed.

I agree, there is a good reason for adding evidence for services, so that one can see these "service" claims in the BOM and reason the correctness and value.

---

BTW: Here is a tool that also detects "services": https://owasp.org/www-project-attack-surface-detector/

[prabhu]

I agree, there is a good reason for adding evidence for services, so that one can see these "service" claims in the BOM and reason the correctness and value.

Thank you!

The efficacy of the technique and comparison with other tools is beyond the scope of the specification and could be left to the documentation pages of the generator tools. I agree that the information added to a BoM must be accurate.

[stevespringett]

@prabhu so just for clarification, the proposal is to allow either a frame or a data object to be represented?

Would it be possible to provide a more complete example?

[prabhu]

@stevespringett, I am lacking time. Please consider moving this to 1.7.