¶ What SAP BTP Does Not Tell You
The SAP Business Technology Platform (BTP) cockpit lists which integration packages, API proxies and applications exist in an account, but it does not read what is written inside them, which is the gap the RedRays BTP security assessment is built to close.
Customers usually arrive at this question because an auditor asked first, and the question has two halves. Who can reach our integration content, and what is inside it. BTP holds the ingredients for both and assembles neither.
¶ Why does the BTP cockpit not answer what is inside your integration content?
Because the cockpit is an inventory and a runtime, not a reader of source. An integration flow is a deployable artifact containing Groovy and JavaScript; an API proxy is a set of policy documents; a Cloud Foundry application is a bundle. What is inside those files is not something the platform inspects, scores or alerts on.
The consequence is specific rather than general. A basic authentication header assembled from a user name and password written into an integration flow script does not make a message fail. It makes the message succeed, on into whatever system the credential opens, for as long as the credential lives. Message monitoring watches for failures, so it has no reason to look at this at all.
¶ Why is design-time content the part nobody looks at?
Design-time content is copied in ways runtime secrets are not. An integration package is exported, attached to a ticket, moved between subaccounts and handed to a partner. Anybody holding one of those copies holds whatever was written into the scripts inside it. Rotating such a credential is not a configuration change either: it means editing a script, redeploying the flow, and accounting for every other copy of the package.
The same argument applies one service across. An API proxy that publishes with no policy enforcing authentication on the request path is a deployed fact about a document, discoverable by reading the proxy and not by watching traffic through it.
¶ Why is this hard to do by hand?
Three services, three object models, three ways to get at the code, and no shared inventory across them.
| Service | What a manual review has to do | What it leaves behind |
|---|---|---|
| Integration Suite (Cloud Integration) | List packages, list artifacts, download an artifact, unpack it, read every script inside | A folder of downloads |
| API Management | Walk the proxy, one request after another, and read the policy documents that come back | A scrollback of requests |
| Cloud Foundry | Pull an application bundle and read it | Another folder |
That is three tools, three credentials and one repetition per object. None of those records which objects did not arrive, and that omission is the whole problem. See what one BTP finding is about for the unit the assessment records instead.
¶ Why is an empty findings list the trap?
Because two different things produce it. An object that could not be fetched produces no findings. An object that was fetched, read in full and found clean also produces no findings. In a list of findings, both are nothing.
The absence of a finding is not the absence of a defect. A failed run is not a clean run, a run that has not finished is not either, and an object a credential was never allowed to list does not appear anywhere at all. The assessment is arranged around keeping those apart on screen: objects that were never read are named above the figures they qualify, coverage prints its numerator and denominator rather than a percentage, and an empty filtered list says in words that it is not a statement that nothing is wrong. Coverage and what was not assessed is the whole of that argument.
Filtered to a scope with nothing recorded, the list refuses to congratulate the reader and names the screens that say which objects were never assessed.
¶ What this capability still does not answer
The first half of the auditor's question - who can reach our integration content, in the sense of naming people - is not answered here, and cannot be. The assessment authenticates as the credential the customer supplied and sees exactly what that credential's authorisations allow, with no view of what any other credential could reach. It can say which tenants an installation is connected to, which credential each connection carries, and what that credential could see when it last answered. That is a narrower statement, and it is stated narrowly.
¶ FAQ
¶ Does SAP BTP have a built-in scan for integration content?
The platform provides monitoring, alerting and transport tooling around integration content, and role-based control over who can edit it. It does not perform a security analysis of the scripts and policy documents inside a deployed artifact, which is why this is a separate exercise.
¶ Would runtime monitoring catch a hardcoded credential?
Not by design. Runtime monitoring reports what went wrong with a message. A credential written into a script is not a failure condition, and the messages using it complete normally.
¶ Is this the same problem as custom ABAP?
It is the same shape of problem in a different place: code the customer wrote, which no vendor patch or Security Note covers. See why no SAP patch covers custom ABAP for the equivalent argument inside an SAP system.
¶ Can one credential cover a whole BTP landscape?
No. Each service is connected separately with its own credential, and the scope of each is set by the role collection behind the key or the entitlements of the technical user. Connecting a BTP tenant explains what each connection asks for and what it decides.