¶ BTP Security Defects the Scanner Finds
The RedRays SAP Business Technology Platform (BTP) security assessment reports classes of defect that live in deployed design-time content: credentials written into integration flow scripts, API proxies published without an authentication policy, sensitive payloads written to logs, and internal detail returned to callers in error responses.
This page names the classes and says what each one means to a business. It is not a rule list, and the SAP BTP security assessment is not limited to the examples below.
¶ What kinds of security defect are found in SAP BTP integration content?
| Defect class | Where it appears | Why it matters |
|---|---|---|
| Hardcoded credentials (CWE-798) | Groovy and JavaScript inside an integration flow; configuration inside an application bundle | Anybody who can read or export the package holds the credential. Rotation means editing a script and redeploying |
| Missing authentication on a published API (CWE-306) | An API proxy whose request path runs no API key or OAuth policy | Every operation of the backend is reachable by whoever can reach the proxy |
| Sensitive data written to a log (CWE-532) | An integration flow that attaches the whole message body to the message log | Order and payroll payloads carry names, prices and identifiers, readable by everyone with the monitoring role |
| Information disclosure in responses (CWE-200) | Fault rules and error handlers that copy target host names or internal detail into a response header or body | Names an internal system to any caller who can trigger an error |
| Weak or absent transport and certificate handling | Adapters and outbound calls in flows and application code | An integration that accepts any certificate is an integration whose counterparty is not established |
| Missing timeouts and unbounded retries on external calls | Outbound calls in integration flows and applications | One slow counterparty becomes a stalled queue in your own landscape |
| Injection and unsafe dynamic execution | Scripts that build queries, commands or targets from message content | The message decides what the flow does |
¶ What does a hardcoded credential finding actually say?
It says that a named file, in a named object, contains a credential written into the source, and it shows the line it was read from so the claim can be checked.
It does not say the credential is still valid, that anybody has used it, that the package has ever been exported, or that the account it belongs to can do anything in particular. The score attached to it is an assessment of the defect class, not of how that flow is deployed. That is a narrower claim than a reader might assume, and stating it narrowly is the point: a finding you can check is worth more than a finding you have to trust.
The evidence is a verbatim slice of your own integration content, not a paraphrase. That is what makes it checkable, and it is also why the evidence is only shown to an operator who opened a single finding and never put into a list, a link or a log line: it can contain a credential, because a credential is one of the things being looked for.
Opening one finding shows the content it was read from and the fix it suggests, which is what lets somebody who did not run the scan check the claim.
¶ Why is a missing authentication policy a finding about a document?
Because that is what was read. An API proxy is analysed as deployed policy content: whether a policy enforcing authentication runs on the request path is a fact about the proxy's own configuration.
The finding therefore does not claim the backend behind the proxy is unauthenticated, and it does not claim the proxy has ever been called. A target that enforces its own authentication is outside what is read, and the proxy is not called to find out. If your backend has its own control, the finding is still a true statement about the proxy and is a reasonable thing to record a decision against. See triage and recorded decisions.
¶ Why two findings on one object can disagree with each other
Because they are two independent statements and nothing arbitrates between them. A proxy can carry an open finding saying no authentication policy runs on its request path, and beside it a second finding accepted on the recorded grounds that only internal consumers use the proxy. That second reason is a claim about who can reach the proxy, which is exactly what the first finding disputes.
The assessment records both faithfully and reconciles neither. Nothing cross-checks a note against a sibling finding, no screen puts them side by side, and an acceptance carries no expiry date. That is a limit worth knowing before you rely on the notes rather than on the findings.
¶ The case with no finding in it
The most important example in this capability is an object that produced nothing because it was never read.
A run that fails at the download - the credential is not authorised for that package, the route does not resolve, the token is rejected - stores no findings. Every number on a findings screen is a count of stored findings, so that object contributes nothing to any of them. The arithmetic is right and it is also the danger: filtered to that object, the list is empty, and an empty list reads as good news.
So the object appears somewhere else instead. It is named in a panel above the figures it qualifies, with its tenant, the reason recorded against the run, and - in the position a finding count occupies on an object that was read - the words "unknown, not checked" rather than a zero. An object nobody read can never be skimmed as an object with nothing wrong. Coverage and what was not assessed is the rest of that argument.
¶ Limits
- These classes describe what is found in content the credential could read. They say nothing about content it was never shown.
- A defect class is not a severity ranking of your landscape. The band and score come from the analysis of the defect, not from where the object sits in your business.
- Analysis of a deployed artifact cannot see runtime configuration held outside it, such as what a security material entry currently contains or which consumers a published proxy actually has.
¶ FAQ
¶ Does it find defects in standard SAP content?
The subject is the content in your account: the flows, proxies and applications your organisation built or deployed. Standard content that has been copied into your packages is read like anything else, because once it is deployed in your account it is yours to answer for.
¶ Are findings mapped to CWE?
Where a class maps cleanly to a Common Weakness Enumeration (CWE) entry, the class is the recognisable one - hardcoded credentials, missing authentication, log exposure, information disclosure. The finding names the defect class and its title rather than a rule identifier.
¶ Does it check my BTP configuration, such as trust settings or destinations?
No. This capability reads content. Configuration and vulnerability checks against a connected SAP system are a different capability; see what one BTP finding is about for the boundary of this one.
¶ What if a finding is wrong for our deployment?
Record it as a false positive with the reason, and it stays recorded through every later scan of that object. The finding is not deleted and not hidden, because a finding somebody decided about is not a finding that went away.