¶ SAP BTP Security Assessment
The RedRays SAP Business Technology Platform (BTP) security assessment reads the design-time content of a customer's Integration Suite, API Management and Cloud Foundry accounts, using credentials the customer supplies, and reports the security defects written inside it.
- Reads only, deploys nothing
- Every run is explicitly asked for
- No finding is ever withheld
It answers a narrow question on purpose: what is inside your integration content, and what does the credential you gave it reach. It reads integration flows, API proxies and deployed application bundles as artifacts - the thing that was built and deployed, not the messages that later flowed through it. A password written into a script does not make a message fail, so message monitoring has no reason to look at it.
Open findings and the objects nobody managed to read sit on the same screen, so a short list of defects cannot be mistaken for a clean account.
¶ What is an SAP BTP security assessment?
An SAP BTP security assessment is an inspection of the content deployed into a BTP account - integration flow scripts, API proxy policies and application bundles - for defects such as hardcoded credentials, missing authentication policies, sensitive data written to logs and internal detail disclosed in responses.
It is not a review of your subaccount members or their role collections. The assessment authenticates as the credential it was given and sees exactly what that credential's authorisations allow. If you need to know which people can reach your integration content, that question is answered by identity and access tooling and not by this capability.
The assessment sees exactly what the credential it was given allows, and an object that credential could not list never becomes a run, so it is in no coverage figure and on no screen.
¶ What does it connect to?
Three BTP services, connected one tenant at a time. They do not share an inventory, they do not share a way in, and the assessment does not invent one that spans them.
| Service | How the scanner is let in | What one run reads |
|---|---|---|
| Integration Suite (Cloud Integration) | Client id and client secret from a subaccount service key, plus the token endpoint and the API address | One integration flow: the artifact is downloaded, unpacked, and the Groovy and JavaScript inside it analysed |
| API Management | The same four values, issued from an API Portal service key | One API proxy, read as a graph of policies, endpoints, flows and file resources. Nothing is downloaded |
| Cloud Foundry | No service key exists. A UAA address, a named technical user and that user's password, with an optional org and space | One deployed application bundle |
Cloud Foundry is the one place in the product that asks for a password, because the platform offers no service key for it and the only way in is a password grant. The form says so where it asks. Use an account created for nothing else, with read-only access to the org and space you want scanned. Connecting a BTP tenant sets out what each field is and what it decides.
Each connection is one credential against one tenant of one kind, and a tenant whose credential has not answered reads as unknown rather than as nothing.
¶ What does one finding say?
One finding is one defect class, in one file, of one scanned object, on one connection. It is never a tenant, never a person and never a run. The finding names where it is, what was seen there, and what to do about it, and it carries the evidence so that somebody who did not run the scan can check the claim.
A finding is identified by the cloud service, the connection, the object as the tenant identifies it, the file, the defect class and the defect title. The line number is deliberately not part of that identity, because code moves and the defect does not: adding an import above a hardcoded credential shifts the printed line but leaves the same finding, the same first-seen date and the same recorded verdict attached to it. What one BTP finding is about sets out the consequences of that choice.
¶ Where does the analysis run?
The product is installed on the customer's own infrastructure, and connections, scan history and findings stay there. API proxy policy analysis runs entirely inside that installation. Integration flow scripts and application bundles are sent to a RedRays analysis service to be analysed and the findings returned; the model performing that analysis runs inside that deployment and sends nothing to any model vendor. Deployment and where data goes states the whole arrangement, for this capability and the others.
¶ What it does not do
- It does not enumerate who can reach a tenant. No subaccount members, no role collections, no service instances. It reports what one credential could see when it last answered.
- It does not scan on a schedule. Every run is started by an explicit request and records the account that asked for it. Nothing spends your BTP API quota unless somebody asked it to.
- It does not test a running proxy or endpoint. A missing authentication policy is read from the deployed policy content, not by calling the proxy. A backend that enforces its own authentication is outside what is read.
- It cannot count what a credential was never shown. An object the credential could not list never becomes a run, so it is in no coverage figure and on no screen. Coverage and what was not assessed states that boundary rather than hiding it behind a percentage.
- It has no suppression. Nothing is withheld from the findings list on the strength of a recorded decision, and no scan deletes a finding.
A named object read in full and producing no findings is not the same statement as an account being clean, and the product keeps the two apart deliberately.
¶ Start here
¶ FAQ
¶ Does the assessment need a BTP global account administrator?
No. It needs a credential that can list and read the content you want assessed - a service key for Integration Suite or API Management, or a read-only technical user for Cloud Foundry. It sees what that credential's role collection allows and nothing else.
¶ Does scanning affect production integration content?
It reads. It downloads an integration flow artifact, walks an API proxy, or fetches an application bundle, and it deploys nothing and changes nothing. It does spend your tenant's own API quota while it reads, which is why scanning is a separate permission from viewing.
¶ Can it tell me my BTP account is clean?
It can tell you that a named object was read in full and produced no findings. That is not the same statement as an account being clean, and the product keeps the two apart deliberately. An object whose run failed was never assessed, and an object nobody queued is not counted at all.
¶ How does it handle the credential I give it?
The secret is encrypted on the way in and is never returned afterwards, in any form, masked or otherwise. It cannot be read back by an operator or recovered by support. Rotating it means entering it again.
¶ Is SAP BTP covered by the same scanning as custom ABAP?
They are separate capabilities over separate content. ABAP code security scanning covers code written inside an SAP system; this covers content deployed into a BTP account. The defect classes overlap, but the objects, the credentials and the coverage rules do not.