SAP Community - Security

Leverage AI Agents in Enterprise Security

2025-11-13T11:03:37.441000+01:00

Leveraging AI Agents in Enterprise Security

As the world of cybersecurity evolves rapidly, the scale and sophistication of attacks are also increasing. Malicious actors are becoming smarter, and with the help of AI, the curation of attacks is advancing. Meanwhile, cybersecurity professionals struggle with alert fatigue and resource shortages. Traditional security tools, reliant on static rules and signature-based detection, are struggling to keep up. This has created a critical gap between the speed of attacks and the response capabilities of human security teams. To address this, enterprises require an advanced security platform that can think, learn, adapt, and respond intelligently.

Security Challenges

Large Alert Volumes (CVE)

SIEMs and IDS systems generate thousands of alerts daily, making manual review nearly impossible. Many alerts are noise or false positives. The time to identify and contain a breach averages 277 days, costing organizations millions.[1]

Zero-day Attack Vectors

Zero-day vulnerabilities are unknown security flaws with no available patches. They are dangerous because attackers can exploit them before defenders have any chance to react.

Human Resource Limitations

As environments scale, manual log analysis becomes infeasible. This leads to alert fatigue, causing critical threats to be missed.

Blind Spots

Complex environments often have limited visibility due to network and endpoint blind spots. Attackers exploit these gaps with tactics like zero-day exploits, ransomware, and social engineering.

Delayed Response Time

Even after detecting a threat, organizations may take hours or days to respond—significantly increasing damage.

Current Implementation in HCM

Today’s processes rely heavily on traditional DevSecOps methods such as SAST, DAST, IDS/IPS, and vulnerability scanning. These tools are rule-based and require extensive manual review.

Security Development & Operations Lifecycle

Despite integration across the lifecycle, these tools still need significant manual effort and cross-team communication:

SAST & DAST: More than 70% false positives requiring manual review.
Security Controls: Manual remediation even for small changes.
Secret Scanners: Find sensitive information in code repositories.
CI/CD Automation: Pipeline-dependent, rule-based, requires continuous rule maintenance.

HXM SIEM Process

Policy and Security Requirements: BISO
Tooling: SecOps
Response: App/Platform Ops

AI Agents: Autonomous Security Analysts

An AI agent in cybersecurity is an autonomous system powered by LLMs, ML, and NLP. It perceives logs, network traffic, and user behavior; analyzes threats; and can take predefined actions—without constant human intervention.

How AI Agents Work

AI agents perform multiple roles and can collaborate with other agents or external tools via APIs.

Example Roles

Threat Hunting & Detection: Detect anomalies and zero-day attacks without rule dependency.
Threat Analysis & Correlation: Reduce noise by correlating logs across systems.
Automated Response & Patching: Quarantine devices, revoke access, or roll back systems.
Forensics: Trace attack origins and impacts.
Proactive & Predictive Defense: Identify misconfigurations and predicted attack vectors.

AI Agent Development Frameworks

LangChain: For multi-step LLM workflows integrating reasoning and tool usage.
AutoGen: Microsoft’s framework for multi-agent collaboration.
CrewAI: Role-based multi-agent orchestration framework.

What Gaps Can AI Close?

Advanced Threat Detection

AI agents detect unknown threats using unsupervised learning, closing gaps in rule-based security tools.

Anomaly Detection & Behavior Analysis

Agents establish baseline behavior and flag deviations—catching stealthy attacks that evade traditional detection.

Zero-Day Vulnerability Detection

Agents analyze behavior patterns to detect zero-day attacks earlier, giving analysts time to respond.

Real-Time Threat Detection

AI filters large SIEM/IDS data streams and reduces false positives, allowing analysts to focus on high-impact events.

Social Engineering & AI-driven Phishing

Agents analyze email content, sender reputation, and context to detect highly realistic phishing attempts.

Automating Routine Investigations

Agents continuously scan for IOCs and ensure compliance without manual audits.

Incident Response Automation

Once a threat is confirmed, agents execute predefined actions such as blocking IPs or isolating endpoints.

Real-World Use Cases

Microsoft Security Copilot: Phishing triage and vulnerability remediation.[2]
CrowdStrike Charlotte AI: Doubles detection triage speed and reduces computational load by 50%.[3]
360 Security Agent: Identified and analyzed an APT in 1 minute.[4]
Darktrace Antigena: Real-time autonomous device isolation.[5]

AI agent adoption spans:

SOAR platforms
SOCs
Endpoint security
Cloud security

Challenges & Responsible Deployment

Hallucinations: LLMs may generate incorrect insights.
Adversarial Attacks: Agents may be vulnerable to prompt injection or model poisoning.
Data Privacy Risks: Continuous monitoring must comply with regulations.
Need for Human Oversight: Ethical or critical decisions require human judgment.

Responsible deployment requires red-teaming, runtime guardrails, confidential computing, and human-in-the-loop workflows.

Conclusion

The cybersecurity gap—driven by complex threats and limited human capacity—is one of the biggest challenges of our digital era. AI agents provide unprecedented scale, speed, and intelligence, transforming security from reactive to proactive. With thoughtful governance, AI agents help organizations stay ahead of threats and build a safer digital ecosystem.

References

Multi-AI Agent Security Technology (folio3.ai)
Microsoft Security Copilot (windowsnew.ai)
How AI Agents Improve Cybersecurity (nvidia.com)
360 AI Agents – Tencent
Multi-AI Agent Security Technology (foli3.ai)

Project Foxhound - on the Scent of Client-Side Web Vulnerabilities

2025-11-19T11:10:41.188000+01:00

In this article, we show how the open-source Project Foxhound has evolved from its academic roots to become the best tool for discovering client-side security vulnerabilities.

The most recent development on this journey is that Foxhound was selected to appear as part of Black Hat Arsenal 2025 in London in December! If you are attending the conference, be sure to check out our demo, where we are hoping to reveal some exciting new features and integrations!

Background

The world-wide-web is one of the most pervasive innovations of the modern age, underpinning communications, banking, education and business. However, programming flaws or misconfigurations can cause security vulnerabilities, exposing the systems and their data to malicious attackers. According to a recent report from IBM, the average cost of a Cybersecurity data breach is $4.4M.

In recent years, web applications have seen a paradigm shift from on-premise, monolithic server applications, to heterogeneous collections of cloud-based microservices. As such, much of the application logic has shifted from the server to the client, with program logic running as JavaScript code in a user's browser. This shift has brought with it new classes of client-side (or DOM-based) web vulnerabilities, for example:

Client-Side Cross-Site Scripting (XSS)
Client-Side Cross-Site Request Forgery (CSRF)
Request Hijacking
Markup Injection

Most state-of-the-art tools, however, are still focused on detection of their server-side counterparts (such as reflected XSS). Hunting for client-side issues, remains a manual effort, requiring time-intensive and costly penetration tests.

Figure 1: JavaScript vulnerable to client-side XSS

Project Foxhound

This is where project Foxhound comes in – providing a state-of-the-art framework for the detection of client-side web application vulnerabilities. It has seen a wide range of proven use-cases, from academic studies to industrial-scale dynamic testing and even education.

Features

Foxhound is a modified web browser based on Firefox with the following enhancements:

An instrumented JavaScript engine and content model to track insecure data-flows using dynamic taint-tracking.
Taint tracking makes it possible to automatically detect client-side vulnerabilities by tainting certain attacker-controlled strings, e.g., location.hash, and notifying the user when tainted data reaches a sensitive sink, e.g., eval() or .innerHTML.
Foxhound also tracks a history of operations performed on the string at runtime, allowing automatic detection of potential input sanitization which essentially reduces false positives.
Integration with popular browser automation frameworks, such as Selenium and Playwright.

History

The technology for Foxhound was conceived at SAP Security Research back in 2013, where it was successfully used to discover that at least 10% of web applications are vulnerable to cross-site scripting. This paper spawned multiple follow-ups, with many research groups implementing their own instrumented browsers, which is not a trivial task!

We saw the need in the community for an open-source, up-to-date tool for teams to use as a platform for their own research. This gap was the main inspiration to open-source our implementation, which was released in 2022 – and Foxhound was born!

Since then, the Foxhound community has grown from the initial founders at SAP and the University of Braunschweig and is currently in use by groups at CISPA (Germany), Waterloo (Canada), and Venice (Italy). With the support of the SAP Open Source team, the project has evolved and matured, appearing in podcasts, at conferences, and even has a new logo!

Foxhound has also proven its worth in industry, with SAP using it to dynamically test UI5 applications since 2023 as part of the award-winning FioriDAST tool.

Why Foxhound?!

Foxhound offers several advantages over existing tools and techniques to outperform the competition. Firstly, as Foxhound uses dynamic testing, it benefits from lower false positives and higher accuracy compared to static analysis techniques. Secondly, Foxhound is non-invasive and does not require actively probing an application with potentially harmful and inaccurate payloads.

In fact, a recent independent academic study found that Foxhound was the best tool for dynamic JavaScript analysis. To quote the paper: "the only effective solution given the current state of the art is Project Foxhound."

Figure 2: Foxhound hard at work detecting a cross-site scripting vulnerability at https://domgo.at

Find out More

The next opportunity to experience Foxhound live and meet the team in person will be at Black Hat Europe, where Foxhound has been selected to appear as part of the Arsenal program. So be sure to pass by our booth to check out the latest features!

If you can’t make it to Black Hat, but are still interested in the project, check out the following links:

The best place to find out more is on our GitHub repository where we also manage development via issues and pull requests and actions.
Binaries for selected platforms are provided by the University of Braunschweig on a dedicated server.
More resources include academic papers, talks at IEEE S&P 2025 and the German OWASP day, and even a Podcast!

Authors of this Article

Thomas Barber, Product Security Expert, SAP BTP
Ulrike Fempel, SAP Open Source Program Office

Introducing Application Vulnerability Report for Cloudfoundry Applications – Try It Now!

2025-12-02T08:25:25.852000+01:00

Application Vulnerability Report Service is currently in Beta Phase
Try it out and provide feedback on your observations
SAP Technical Support Ticket Component : BC-CP-SEC-AVR

What Is Application Vulnerability Report?

Security is a top priority in today’s digital landscape, especially when applications rely heavily on open-source components. These components, while powerful and cost-effective, often come with publicly known vulnerabilities that can put your business data at risk.

The Application Vulnerability Report is a newly introduced feature for SAP Business Technology Platform (BTP) services that helps you detect and remediate vulnerabilities in your Cloud Foundry applications. This tool scans your application for known security issues based on Common Vulnerabilities and Exposures (CVEs), ensuring that you stay ahead of potential threats.

Currently in Beta Phase and available in eu-10 region.. Once Beta Phase is completed.. roll-out to other regions are expected in Q2 or Q3 2026.

How to enable in your tenant ?

Go to Entitlements in your SAP BTP Sub-account to add Application Vulnerability Report to add the plans

Service Marketplace

Search for application-vulnerability-report-service in the SAP BTP Service Marketplace

Create Instance in your Cloud Foundry space

Go to your Cloud Foundry Space (example : Dev, UAT, TST...etc)
Create a new Instance for Application Vulnerability Report with default plan
Provide a Instance Name

Create Service Key

Create a New Service Key for API Access

Allow the User to Access the Space

You need to manually add the application-vulnerability-report-scanner@sap.com user to your Cloud Foundry space. This enables the application vulnerability report to download the droplets of the respective applications and scan them accordingly.

Log on to the CF space that you want to scan.
Select the Space Members tab and choose Add Member.
Enter the application-vulnerability-report-scanner@sap.com user and assign the Space Auditor role to it.

Why Is This Important?

Open-source vulnerabilities are one of the most frequent security challenges in modern application development. Attackers are quick to exploit these weaknesses, and failing to address them promptly can lead to severe consequences, including data breaches and compliance violations.

By using the Application Vulnerability Report, you can:

Identify vulnerabilities early in your application lifecycle.
Understand the severity of each issue based on CVE data.
Take corrective actions quickly to secure your SAP BTP landscape.

Application Vulnerability Report - Process overview

The application vulnerability report supports you in the detection of vulnerabilities in custom applications during runtime. Instead of a shift-left support approach during pipeline runs, this service provides security-relevant information for what has already been deployed (and maybe forgotten). The service scans the applications using a proprietary scanning layer that utilizes open-source scanners such as Open Source Vulnerabilities (OSV) and trivy, as well as custom SAP BTP-specific and 0-day exploit targeted scanners. This unique combination offers a very broad and up-to-date coverage of vulnerabilities in your applications. By using an API, you can integrate the report data into your incident and security workflow.

Overview of the each Process flow

1. Applications Running on SAP BTP

This is the starting point.
It includes all your Cloud Foundry applications deployed on SAP Business Technology Platform.
Example : CAP, Python, Javascript, Java, Go, Dot-Net... any programming languages those are deployed in your Space.. (This also includes NPM Libraries, Pip libraries or any libraries which are consumed in your applications)
These applications often use open-source libraries and packages, which can have vulnerabilities.

2. Scanning Layer

This layer performs the security scans on your applications. It's currently runs weekly scan. It consists of multiple scanning sources:

Commercial
Uses commercial vulnerability databases and tools to identify known issues.
Trivy/OSV
Trivy is an open-source vulnerability scanner, and OSV (Open Source Vulnerabilities) is a database of vulnerabilities in open-source software.
These help detect issues in widely used open-source components.
BTP Specific
Scans for vulnerabilities specific to SAP BTP services and configurations, ensuring platform-level security.
0 Day
Focuses on zero-day vulnerabilities, which are newly discovered and not yet patched.
These are critical because attackers often exploit them quickly.

3. Application Vulnerability Report for SAP BTP

After scanning, all findings are consolidated into a single report.
This report provides:
- List of vulnerabilities
- Severity levels
- Recommendations for remediation
It acts as a centralized dashboard for security insights.

4. API for Customers

Customers can access the report via API.
This allows integration with:
- Security dashboards
- CI/CD pipelines
- Monitoring tools
Ensures automation and continuous security checks.

5. Customers

End-users (developers, security teams) consume the report and take corrective actions to secure applications.

Technical Usage

How to get findings of your deployed CF applications running.

Example : Scanned Finding Report

Reference:

External resource:

OSV database

Beta Version of Application Vulnerability Report for SAP BTP Now Available

2025-12-04T14:18:40.970000+01:00

Earlier this month, we released the application vulnerability report (beta) for SAP Business Technology Platform (SAP BTP). You can use this new service to detect and remediate open-source application vulnerabilities in your SAP BTP deployed applications.

What is this new service all about?

Frequent security issues in open-source components endanger business data in customer deployed applications. Customers are responsible for performing vigilant patch and vulnerability management. By leveraging the new application vulnerability report for SAP BTP, open-source vulnerabilities in your Cloud Foundry applications can be detected and remediated. It's crucial to fix such vulnerabilities quickly, as attackers are usually aware of them and might try to break into vulnerable systems.

What does the new application vulnerability report service offer you?

The application vulnerability report supports you in the detection of vulnerabilities in custom applications during runtime. It enables you to act on criticality and other provided vulnerability details, like mitigation recommendations.

If we take a closer look at the process, the service scans the applications using a proprietary scanning layer that utilizes open-source scanners as well as custom SAP BTP-specific and 0-day exploit targeted scanners. This unique combination offers a very broad and up-to-date coverage of vulnerabilities in your applications. By using an API, you can also integrate the report data into your incident and security workflow.

Let’s have a quick look at the architecture overview:

Application Vulnerability Report for SAP BTP – Architecture Overview

Get started now!

You can find lots of useful information in this practical hands-on blog post:

Introducing Application Vulnerability Report for Cloud Foundry Applications – Try It Now!

The complete documentation is available on SAP Help Portal.

Please note that this is a beta service available on SAP BTP for subaccounts in trial and enterprise accounts. It is currently available in the “cf-eu10” landscape. Once the beta phase is completed, we plan to roll out the service to other regions.

If you are interested in what’s more to come, check out the road map in SAP Road Map Explorer.

Try it out, and we look forward to your feedback!

Also make sure to join our community to learn more about the security services and features in SAP Business Technology Platform here:

https://community.sap.com/topics/btp-security

Building Secure SAPUI5 Applications: Best Practices for Developers

2025-12-10T08:16:09.335000+01:00

Introduction

In today’s enterprise landscape, security is fundamental, not optional. As the user-facing gateway to SAP systems, SAPUI5 apps must be built with security in mind from the start.

This blog shares practical, developer-focused techniques to help you secure your SAPUI5 applications from input validation and Cross-Site Scripting (XSS) prevention to using ESLint and safe communication practices. By adopting secure coding habits early, you can ensure your UI remains clean, efficient, and resilient against modern threats.

Why Security Matters in SAPUI5

The UI layer is where users interact, input data, and access sensitive information.
Even a small oversight like an unsanitized binding or debug log can lead to security exposure or data misuse.

By following secure UI5 coding standards, developers can:

Maintain data integrity and confidentiality
Prevent unauthorized access
Build user trust through reliable and safe design

Secure Coding Practices for SAPUI5 Developers

1. Validate and Sanitize User Input

Always validate what users enter before sending it to your backend.

Use data types in input fields for built-in validation:

<Input value="{path: 'age', type: 'sap.ui.model.type.Integer'}" />

Add custom formatters or validators for domain-specific logic.
Reject invalid inputs early, don’t rely on the backend to catch them.

2. Prevent Cross-Site Scripting (XSS)

XSS attacks occur when untrusted input is rendered as executable code in the browser.
To prevent it in UI5:

Use Text control instead of FormattedText unless the content is sanitized.
Escape dynamic strings using encodeHTML().
Avoid direct DOM manipulation like innerHTML or jQuery .html().
Never include untrusted HTML in views or models.

3. Protect Sensitive Information

Do not store tokens, passwords, or system URLs in localStorage or sessionStorage.
Avoid exposing business logic or identifiers in console logs.
Remove debug logs before deployment as they often reveal internal system details.

4. Use ESLint for Secure and Consistent Code

Static code analysis helps detect vulnerabilities and enforces coding standards.

Install and configure ESLint with SAP’s recommended rules:

npm install eslint eslint-config-ui5 --save-dev

Create a .eslintrc.json file:

{
  "extends": ["eslint-config-ui5"]
}

Benefits:

Detects unsafe DOM access or unused imports
Prevents insecure practices like eval statements
Promotes consistent, readable, and maintainable code

Run ESLint regularly as part of your build or CI pipeline:

eslint .

5. Secure Communication with Backend

Even though backend services handle authentication, the UI must communicate securely.

Always use HTTPS for service endpoints.
Avoid hardcoding URLs use destination configurations or environment variables.
Enable Cross-Site Request Forgery (CSRF) protection in your ODataModel configuration:

let oModel = new sap.ui.model.odata.v2.ODataModel("/odata/service", {
  tokenHandling: true
});

Developer Mindset: Security as a Habit

Security isn’t a one-time setup, it’s an ongoing practice.
Adopt a security-first mindset by:

Reviewing code with security in mind
Regularly updating libraries and dependencies
Integrating linting and vulnerability scans in CI/CD

When security becomes part of your coding routine, your applications naturally grow more resilient and trustworthy.

Conclusion

Building secure SAPUI5 applications isn’t just about backend policies, it starts right in your controllers, bindings, and XML views.
By validating inputs, preventing XSS, protecting sensitive data, and using tools like ESLint, you strengthen your application’s defense without compromising usability or performance.

New version 8.6 of the SAP Cryptographic Library with quantum-safe cryptography and FIPS 140-3 mode

2025-12-12T17:10:56.764000+01:00

Overview

The SAP Cryptographic Library enables applications like SAP S/4 HANA to support security protocols such as TLS (Transport Layer Security), SNC (Secure Network Communication), SSF (Secure Store and Forward) and X.509. While the library already includes "modern" cryptographic algorithms such as those based on Elliptic Curve Cryptography, these were until now all part of the group of "classic" algorithms.

Most "classic" algorithms for asymmetric cryptography are vulnerable when a cryptographically relevant quantum computer becomes reality. This might have an impact even today if attackers record encrypted communication and store it for later decryption ("harvest-now-decrypt-later").

Quantum-safe cryptography in the SAP Cryptographic Library

The new version 8.6 of the library enables support for a quantum-safe TLS 1.3 handshake. When the library is installed on an SAP NetWeaver ABAP system and TLS 1.3 is used to establish a connection, then a hybrid ECDHE-MLKEM key agreement based on X25519MLKEM768 takes place. ML-KEM is a new, quantum-safe algorithm for key encapsulation, which was already standardized as FIPS-203. This makes it impossible, even for a quantum computer, to determine the session key and decrypt the session communication.

New FIPS 140-3 certification of the FIPS crypto kernel

FIPS stands for Federal Information Processing Standard. A FIPS certification is required by US public sector agencies, healthcare, and financial industries, and many more. FIPS 140-3 validates the proper implementation of the algorithms in cryptographic modules.

The FIPS crypto kernel is a dedicated module in the SAP Cryptographic Library that was recently certified as compliant with FIPS 140-3. The certificate is available from the National Institute of Standards and Technology (NIST): Certificate #5093.

For SAP Application Server ABAP and SAP HANA, SAP note 2180024 explains the configuration steps that are required to switch the SAP Cryptographic Library to FIPS mode.

Release Details

The release note "3685428 - Fixes and features in CommonCryptoLib 8.6.2" has now been published. More information about the SAP Cryptographic Library is available in "1848999 - Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB)".

SAP Integrated Business Planning On Demand - Stay Secure with SAP EarlyWatch Alert

2025-12-19T06:11:34.454000+01:00

With SAP Integrated Business Planning On Demand, SAP takes care of many security-related topics as cloud provider. However, in order to stay secure, customers are still responsible for the mitigation of risks such as business or technical users having critical authorizations.

Here, the SAP EarlyWatch Alert report in SAP for Me comes into play as it gives you insights into security risks in the chapter "Security (SAP IBP OD)". This chapter provides insights and alerts you on the following topics:

Assignment of Users to Business Role SAP_BR_ADMINISTRATOR - check for usage of this role in production, leading to segregation of duties (SoD) conflicts as it is intended only for initial system configuration
Use of Read/Write Unrestricted - get alerts on business roles with unrestricted write, read and value help access, allowing users global data access
Critical Business Catalog Assignment - be warned about over-assignment of critical authorizations which should have limited use in production
Critical Authorization Combinations - get alerts for users assigned excess authorizations through critical combinations of business catalogs
Communication (Inbound/Outbound) - get alerts on customer-managed communication arrangements based on user/password authentication, where certificate-based authentication is more secure
Upcoming Certificate Expiration - get early warnings for customer-managed certificates which will expire within the next 90 days

You can find more details on each of these chapters below or by directly accessing the SAP EarlyWatch Alert report* for your systems in SAP for Me.
* an authorized user is needed to access this application - refer to this SAP Support page on how to get access.

Assignment of Users to Business Role SAP_BR_ADMINISTRATOR

The role SAP_BR_ADMINISTRATOR is predefined by SAP and is intended only for the initial configuration of a system. Using this role in production is not recommended by SAP and may lead to compliance issues. This section checks the role's usage and points to in-depth information on Identity Access Management. It provides a link to the procedure for creating a more restricted administration role, suitable for use in production.

Use of Read/Write Unrestricted

Using unrestricted fields in the maintenance of business roles allow users to have global data access. SAP best practices recommend to carefully review which users need to have restricted data access and maintain the access appropriately, e.g. ensuring employees only have access to data belonging to their sales organization. This chapter includes the number of business roles with unrestricted write, read or value help access, and describes the related SAP Fiori app Maintain Business Roles.

Use of Read/Write Unrestricted Table Example

Critical Business Catalog Assignment

Business catalogs contain a bundle of privileges needed for accessing an app or features that are then assigned to users via business roles. This section checks for selected critical business catalogs and their assignment to business roles and users and rates this according to the valuation rules from SAP Note 863362. In case any critical business catalogs are assigned, additional details are presented as sub-chapters.

Business Catalog Assignments Overview Table Example

Critical Authorization Combinations

Segregation of duties in SAP Integrated Business Planning (SAP IBP) is supported by the use of business catalogs and business roles. Creatinga a business role by combining catalogs may grant excess authorization to users and lead to a negative impact on your business processes. The section gives user counts where such critical combinations are found, with a link to information on assessing the associated risks.

Communication (Inbound/Outbound)

Certificate-based communication is recommended for technical users involved in inbound/outbound communication. It is usually easier to detect a compromised certificate than to detect a compromised password. This section lists customer-managed communication arrangements that are password-based, and points to recommendations for a certificate-based approach.

Upcoming Certificate Expiration

Certificates with an expiration date in the next 90 days are listed in this section, with alerts for certifcates where a short-term expiration under 30 days is found.

Enhance security with new CQCs

2026-01-14T15:52:03.764000+01:00

As part of your foundational support experience, SAP Enterprise Supports offers proactive services to help to mitigate issues and risks in relation to the security of your SAP solutions. The services are included as part of your SAP cloud subscription. The CQC for Security Optimization is being expanded to support SAP S/4HANA Cloud Public Edition.

After a detailed security analysis, the service will provide recommendations to improve your configuration and authorizations. For this pilot delivery, SAP will assign a dedicated expert to guide you through the process.

Upon completion of the service, you will receive a comprehensive report that includes an executive summary, detailed findings, and recommendations to mitigate risks and enhance your security posture. You can expect to receive the results approximately one week after the session.

If you wish to participate, please ensure you meet the following prerequisites:

Grant remote access to your SAP cloud solution to SAP.
Be available to collaborate with SAP Expert within a mutually agreed 2 to 3 week time frame.
Be willing to provide open and honest feedback on the service content and respond to our survey requests.

We look forward to working with you and helping you enhance your SAP security.

Additional information about the SAP Enterprise Support Advisory Council can be found here.

Don't Let Your Integration Take a Coffee Break: Client Certificate Changes In 2026!

2026-01-16T08:40:45.053000+01:00

Introduction

If integrations were people, you’d dread them slipping out for coffee breaks just when you need them most. SAP S/4HANA Cloud Public Edition, Integrated Business Planning (IBP), and SAP Marketing Cloud (SMC) are all about to experience an important update to how client certificates are issued. This change, prompted by evolving industry standards, involves a change of the Certificate Authority (CA) for the Default Client certificate. It’s important to note that this CA change has the potential to cause one of those dreaded coffee breaks—disruptions in connectivity—if not handled properly.

Here’s what’s happening, who should pay attention, and how to keep your setup on track.

Which Certificate?

Each SAP S/4HANA Cloud Public Edition, SAP IBP, or SAP Marketing Cloud tenant includes an SAP-managed client certificate named “Client Default.” This certificate is used for outbound calls in customer-managed communication scenarios: the source system (S/4, IBP, or SMC) initiates a call to another system, using the certificate for authentication. The text discusses a change in the Client Default certificate.

If you’re unsure about the various types of certificates, check out this blog post, which clarifies different use cases and their respective user interfaces: Inbound, Outbound, Certificate Bound: Certificate Management in SAP S/4HANA Cloud Public Edition.

Who Is Affected?

If you use the Client Default certificate for outbound authentication in SAP S/4HANA Cloud Public Edition, IBP, or SMC, this change applies to you. Anyone relying on these certificates for outbound integrations should pay attention, as missing the update could lead to disruptions in communication.

This only applies to customer managed integration scenarios. SAP managed ones will be taken care of by SAP, of course.

What Is Changing?

Currently, the Default Client certificates for outbound communication are issued by DigiCert. In February 2026, SAP Cloud Root CA becomes the new certificate authority for newly issued client certificates. You’ll also notice updates to certificate subject names, including additional organizational fields. These changes will be present in all new client certificates issued during routine rotation.

To help visualize the upcoming changes, here’s a quick comparison of the old and new default client certificates:

Certificate Attribute	Old (Before Rotation)	New (After Rotation)
Subject	CN=<your tenant hostname>	CN=<your tenant hostname> OU=<some UID>
Issuer	DigiCert Global G2	SAP Cloud Root CA
Extended Key Usage	Client Authentication, Server Authentication	Client Authentication

The new OU value is specific to the product (S/4/IBP/ SMC) and will remain the same during future certificate rotations.

Timeline and Notification: When and How Will You be Informed?

New systems will receive client certificates signed by SAP Cloud Root CA starting late March 2026. Existing systems will begin renewal with a staging certificate from late February 2026, fully transitioning during their next scheduled key rotation. In case you wonder: the fact that these dates are close to the 2602 release is a pure coincidence. System upgrades and certificate changes are separate processes.
The rotation schedule and rotation process do not change. There will be no additional certificate rotation.

Example: if your current Client Default certificate is valid until April 2026, the CA change will happen in April for you. If your certificate expires in November, you’ll keep your DigiCert certificate until November and then switch to SAP Cloud Root CA.

The usual notification email about certificate rotation will include additional details about the change in Certificate Authority. Please review it carefully to ensure you understand the updates and can take the right actions in response. The process for certificate rotation is described on this help page.

Potential Issues and Required Action

For clarity, we'll refer to the system, tenant, service, or device that receives and validates connections from your SAP cloud tenant (S/4 cloud, IBP, SMC) as the target environment. Such target environments could be anything from BTP apps, SAP solutions like SAP Ariba or SAP SuccessFactors, third-party products running in the cloud or on-premises, or even custom-built applications.

How Things Might Break

Misalignment of configurations in your SAP cloud tenant and the target environment can lead to two categories of issues:

CA Trust Failures: If your target environment does not trust the SAP Cloud Root CA, it will reject the new certificate. In these cases, the mutual TLS (mTLS) handshake fails, and communication is blocked at the TLS layer. No HTTP error code is returned.
User / System / Identity Mapping Errors: in the target environment, the certificate metadata (subject, issuer) is mapped to the identity of a user or process. Consequently, if the mapping is not changed to use the new subject and issuer, authorization errors (such as HTTP 403 or 401) will happen. Depending on the implementation of the target environment, TLS errors could also occur.

Technical Aside: Certificate Pinning vs CA Trust

For certificate-based authentication, most target environments will rely on CA trust, where the target environment validates the certificate’s chain up to a trusted root CA. With the switch to SAP Cloud Root CA, you must add this CA to the trust store in the target environment and check your user mapping logic.

For environments using certificate pinning, simply upload the new certificate when the rotation occurs. In this case, the certificate is identified by the fingerprint of the certificate’s key rather than the metadata of the certificate (i.e. subject and issuer). Target environments using certificate pinning must be updated every time the certificate rotates – the CA change does not make a difference here.

Required Actions for Customers

To maintain uninterrupted integrations, customers using the Client Default certificate for SAP S/4HANA Cloud Public Edition, IBP, and SMC should:

Update CA Trust: Make sure the SAP Cloud Root CA is trusted by your target environment. You can download the root certificate from the SAP Trust Center.
Adjust User/System/Identity Mapping: Update your mapping logic to recognize the new certificate subject and issuer, ensuring the target environment properly identifies and authorizes the incoming connection. How this is done depends on the implementation of the target environment. Typically, it involves downloading the Client Default certificate from the source tenant and uploading it through the appropriate interface in the target environment.

More information on the topic is available in SAP note 3677763 as well as the relevant help pages:

How to Handle Default Client Certificate Renewal
Set Up Certificate-to-User Mapping (SAP Cloud Integration and SAP Marketing Cloud)
Client Certificate Authentication for Integration Flow Processing (SAP Integration Suite)
Client Certificate Authentication for API Clients (SAP Integration Suite)

And in case you wonder what all of this certificate business is about, here's a blog post describing the basics of certificate-based authentication: Beyond Basic (1): Certificate-Based Authentication. For an overview of the different certificate types and usages in SAP S/4HANA Cloud Public Edition, see this blog: Inbound, Outbound, Certificate Bound: Certificate Management in SAP S/4HANA Cloud Public Edition.

Conclusion

While this certificate update might seem like an invitation for your integrations to sneak away for a coffee break, staying alert and updating your trust stores and mappings in your target environment will keep everything running without interruption. Pay attention to notification emails—so your integrations never miss a beat (or a sip).

面向 SAP ERP 公有云、SAP IBP、SAP Marketing Cloud 用户的提醒：出站“默认客户端证书”CA 将变更为 SAP Cloud Root CA

2026-02-02T02:00:00.017000+01:00

背景与原因

受行业规范变化（由 Google 推动）影响，主流证书颁发机构将停止签发用于客户端认证的证书。当前为 SAP S/4HANA Cloud Public Edition、SAP IBP、SAP Marketing Cloud 租户签发“默认客户端证书”的 DigiCert 也将停止相关签发。
为确保持续可用，SAP 将把“默认客户端证书”的签发 CA 切换为 SAP Cloud Root CA 。自 2026 年 3 月起，新签发的客户端证书将由 SAP Cloud Root CA 颁发，并在后续的常规证书轮换中逐步替换现有证书。

谁需要关注与行动

如果您在 S/4HANA Cloud Public Edition、IBP 或 SAP Marketing Cloud 的出站集成中使用“默认客户端证书”进行认证（即由您的租户调用目标系统），本次变更适用且需要您在目标系统执行调整。
仅涉及客户自管的集成场景，SAP 管理的场景由 SAP 处理。
本次证书更新，您可以视作常规证书轮换的一部分。不同的是，签发方会发生变化，证书字段发生了改变，同时在目标系统的信任存储需要更新新的根证书。

本次变更的具体内容

证书“issuer（颁发者）”从 DigiCert Global G2 TLS RSA SHA256 2020 CA1 变更为 SAP Cloud Root CA。
证书“subject（主题）”将新增 OU 字段，OU 的值为签发该证书的 BTP Certificate Service 的子账户 ID。
证书链相应更换为 SAP Cloud Root CA 体系。部分场景中证书扩展用途可能调整为仅客户端认证（Client Authentication）。

时间线与通知方式

自 2026 年 3 月下旬起，新开系统将直接获得由 SAP Cloud Root CA 签发的默认客户端证书；存量系统将按既有到期轮换节奏完成切换（不进行“集中大迁移”）。部分租户可能在 2 月下旬进入证书准备或分阶段发布过程。
您现有的证书在其到期日前仍然有效；切换发生在下一次证书轮换时。示例：若当前证书有效期至 2026 年 4 月，则变更在 4 月轮换时生效；若至 11 月，则 11 月再切换。
与以往一致，SAP 将通过邮件通知证书轮换；您也可在源租户的 Maintain Client Certificates 应用查看证书有效期。
同样与以往一致的是，当客户默认证书在30天后到期时，客户将收到“公告”通知。通知将告知客户新的暂存证书的可用性，客户可以从“维护客户端证书”应用程序下载该证书。新证书的名称为“Client Default”，旧证书的名称是“Client Default Expiring”。此时，客户需要在 SAP 租户里完成出站通信用户的切换。

如果不更新，会有什么影响？

若不更新目标系统配置，可能出现两类问题：

CA 信任失败：目标系统未信任 SAP Cloud Root CA，mTLS 握手在 TLS 层直接失败（通常无 HTTP 状态码）。
身份映射错误：目标系统依赖证书主题/颁发者做用户或系统身份映射，未更新映射会导致 401/403 等授权错误，或因实现差异出现 TLS 错误。

您需要做什么（行动清单）

1. 在目标系统中的操作

更新 CA 信任。在目标系统中，您需要更改入站连接：不再接受由 DigiCert 颁发的旧证书，现在必须使用由 SAP Cloud Root CA 颁发的新客户端证书进行认证。这对于所有目标系统都适用，即使它们在证书轮换期间之前没有需要任何更改（因为这次会更改证书元数据）。
将 SAP Cloud Root CA 的根证书导入目标系统的信任库（trust store）。可从 SAP Trust Center 获取 SAP Cloud Root CA 根证书，或者通过 SAP Notes 3677763 - Change of Client Certificate "Client Default" in S/4HANA Cloud Public Edition, SAP IBP, and SAP Marketing Cloud - SAP for Me 中的链接获取。
当旧证书轮换到来时，使用由 SAP Cloud Root CA 颁发的新客户端证书进行认证。
若目标为 BTP 服务实例，请在对应服务绑定/服务密钥中引用新证书；最简做法是基于新证书重建绑定/密钥。原“用户映射”在 BTP 中表现为“系统映射”，同样需更新。
使用证书钉扎（pinning）的环境。若目标系统采用证书指纹钉扎，不涉及 CA 信任；在轮换时直接替换为新证书指纹即可。但这类环境每次证书轮换都需更新指纹。

2. 在 SAP 租户中的操作

将出站通信用户切换到新的“默认客户端证书”。在证书轮换发生后，参考源租户的 维护客户端证书（Maintain Client Certificates）应用，将出站通信用户/连接凭据从旧证书切换到新证书（与以往轮换操作一致）。

3. 更新身份映射逻辑

针对目标系统中基于证书 subject/issuer 的用户或系统映射，调整为使用新证书的元数据（包含新的 OU 与新的 issuer）。

如何定位“所有受影响的目标系统”

在源租户打开 维护客户端证书（Maintain Client Certificates）应用。
选择 SAP 管理的“客户端缺省值（Client Default）”证书。
在“通信系统”区域查看该证书被使用的所有通信系统列表。
点击进入具体通信系统，在“出站通信的用户（Users for Outbound Communication）”中查看认证方式：
- 若为“SSL客户端证书（SSL Certificate）”，在“常规（General）”下查看目标系统主机并在目标系统完成新证书上传，添加信任。
- 若为“OAuth 2.0（mTLS）”，该证书用于向 OAuth 令牌提供者的 mTLS 端点认证，应在令牌提供者侧更新；端点位置可在“OAuth 2.0 Settings -> Outbound OAuth 2.0 Client Settings”查看。

常见问答与提示

是否会集中切换？不会。切换随各租户证书到期的常规轮换进行。
旧证书是否马上失效？不会，旧证书在到期前有效。
新根证书来源？从 SAP Trust Center 下载 SAP Cloud Root CA 根证书。
SAP 会发邮件吗？会，轮换通知邮件将包含 CA 变更说明；请按指引在目标系统完成信任与映射更新。

支持与文档资源

您可以阅读以下文档，获取更多详细信息：

SAP Note 3677763 - Change of Client Certificate "Client Default" in S/4HANA Cloud Public Edition, SAP IBP, and SAP Marketing Cloud - SAP for Me
SAP Note 3119483 - Client Standard Certificate Renewal in S/4HANA and SMC Systems - SAP for Me
Don't Let Your Integration Take a Coffee Break: Cl... - SAP Community
How to Handle Default Client Certificate Renewal
Set Up Certificate-to-User Mapping (SAP Cloud Integration and SAP Marketing Cloud)
Client Certificate Authentication for Integration Flow Processing (SAP Integration Suite)
Client Certificate Authentication for API Clients (SAP Integration Suite)
如遇问题，请按产品提交事件：XX-S4C-OPR-INC（S/4HANA Cloud Public Edition）、SCM-IBP-OPS-INC（SAP IBP）、CEC-MKT-ITC（SAP Marketing Cloud）

结语

对使用“默认客户端证书”的客户而言，本次 CA 变更是一次必要的合规升级。只要您在目标系统及时导入 SAP Cloud Root CA 根证书、切换到新客户端证书并更新身份映射，出站集成即可平稳度过“轮换窗口”，避免握手失败或授权错误。

Enhancing security: Enabling Multi-Factor Authentication enforcement for S-users

2026-02-06T13:51:09.128000+01:00

Starting from January 15, 2026, super administrators can enforce Multi-Factor Authentication (MFA) for their S-users. This new feature has been developed based on direct customer feedback and in response to the evolving security landscape, resulting in stronger protection for your user accounts.

What is Multifactor Authentication?

Multi-factor authentication, commonly known as MFA, is a powerful security measure that helps safeguard your accounts by requiring more than just a password. Instead of relying solely on something you know (like a password, PIN, or signature), MFA asks for an extra layer of verification, which could be:

Something you have: A one-time code generated by an authenticator app on your smartphone
Something you are: Biometrics, a fingerprint or a facial scan

By combining these different authentication factors, MFA makes it significantly tougher for attackers to break into your account. This is in fact one of the most effective ways to prevent unauthorized access and stop most data breaches.

Strengthening security with enhanced MFA Options for S-Users

Protecting critical SAP assets is crucial for our customers. Therefore, our approach to multi-factor authentication is evolving to meet this challenge. Now, super administrators can take a proactive role by enforcing MFA for S-users, while individuals still have the freedom to secure their accounts independently. This dual approach – administrator-led enforcement alongside voluntary enablement – offers the flexibility and meets modern security demands.

In the past, enabling MFA was left up to each S-user’s discretion. However, relying solely on voluntary enrollment is no longer sufficient to safeguard sensitive business information. By empowering both administrators and users, we’re making it easier to prevent unauthorized access and strengthen your organization’s security.

NEW scenario: Selective MFA enforcement by customer’s own super administrators

Now, super administrators can take a proactive role by enforcing MFA for S-users of their own company, while individuals still have the freedom to secure their accounts independently. Of course, this should be in line and aligned with the companies' own security policy.

Through the User Management Tool (UMT) in SAP for Me, super administrators have the option to activate MFA for S-users. This new feature allows administrators to:

Enforce MFA: Search for, filter, and select specific S-users or all of them to make MFA mandatory for their logins.
Exclude technical users: Crucially, super administrators can exclude specific technical accounts (like those used for the BTP cloud connector) from the MFA requirement, ensuring that core business processes continue to run smoothly.

After MFA is enforced, the selected S-user(s) will receive an email notification with simple instructions on next steps and be guided through a one-time setup on their next login, ensuring a seamless and secure transition.

EXISTING scenario: Voluntary MFA enablement by the S-users themselves

The option for individual users to proactively secure their own accounts remains fully available.

Any S-user can visit their profile page via SAP's profile management at any time to enable MFA for themselves. This has been a great option for security-conscious users who want to protect their accounts even before an administrator-led rollout.

Please note: MFA enforced by the super administrator overrides any voluntary setting previously configured by the user.

Build AI securely - Avoid Pitfalls in the Development and Operations Lifecycle: Apr 9, 2026

2026-02-06T21:27:22.922000+01:00

Secure Your AI Development & Operations! Don’t let security gaps derail your AI projects. Join our 45-minute live session on April 9, 2026, to explore common pitfalls—like credential exposure and unchecked infrastructure—and discover best practices to safeguard your AI lifecycle. Whether you're a developer, architect, or business user, this session will help you build AI securely.

Key Takeaways

Identify security risks in AI development, including secret leaks and misconfigured infrastructure.
Understand real-world impacts of security failures in DevOps and architectural workflows.
Apply mitigation strategies to protect business data, LLMs, and operational pipelines.
Recognize security as a shared responsibility across teams and roles.
Secure AI pipelines from development to deployment with proactive checks and controls.

Register now!

Empty

2026-02-08T22:38:38.247000+01:00

Empty

SAP Ariba is now integrated with Microsoft Sentinel Solution for SAP

2026-02-09T13:34:21.343000+01:00

Quick link to GitHub.

Supply chain is a critical topic in almost every industry these days. We live in times where a controversial social media post and actions of government officials can disrupt factory operations almost the next day. See this Reuters (2025) article that sheds light on car production halt in Germany caught in the crossfire of political turmoil in 2 other countries. SAP Ariba helps diversify the risk between buyers and suppliers in tightly interconnected supply chains.

What a juicy target for cyber criminals one might say 😉

Therefore, meet the new kid on the blog when it comes to Microsoft Sentinel for SAP integration – SAP Ariba.

This cloud-native integration adds real-time threat detection, investigation, and response to your SAP Ariba environment and puts it into the context of your wider IT estate.

The bigger picture

Attackers use the easiest way in. Each month the SAP Security Patch Day starts a new race between hackers and defenders despite responsible disclosure obligations to allow a head start to defenders on reported vulnerabilities etc.

This race wears down defenses eventually – a gap is deemed to happen. Therefore, you need to be prepared to identify attackers in your IT landscape and be quick to lock them out again before they reach valuable targets.

Seeing the context and trail of the interconnected signals that the attacker leaves behind are key to identify compromise.

How It Works

Create an application on your Ariba Developer portal to allow access to the audit-search api and collect your API key.
Deploy the latest Microsoft Sentinel integration package in SAP Integration Suite. See this video for a similar scenario for guidance. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to Ariba.

3. Configure a Destination on SAP BTP for your Ariba instance and the audit search api.

Property	Value	Description
Name	Ariba-[TenantId]	Destination name (e.g., Ariba-p2pTeSap-2)
Type	HTTP	Connection type
URL	https://[region.]openapi.ariba.com/api/audit-search/v2/[prod or sandbox]	SAP Ariba Audit Search API URL (Find your base URl under Configuration Details)
Proxy Type	Internet	Always internet because of the cloud nature of the SAP service
Authentication	OAuth2ClientCredentials	For productive use
Client ID	[ClientId]	if applicable
Client Secret	[ClientSecret]	if applicable
Token Service URL	[TokenEndpoint]/v2/oauth/token	Ariba OAuth token endpoint

Additional Properties	Value	Description
tenantId	[TenantId]	SAP Ariba tenant ID
apiKey	[apiKey]	Api key for your SAP Ariba tenant

4. Deploy the agentless data connector for the Microsoft Sentinel Solution for SAP. See this video for a walk-through of the first steps and the official Microsoft Learn page here. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to Ariba

5. Connect your Ariba flow on the data connector pane to start ingesting SAP Ariba logs.

6. On the Advanced section supply the path “/community/SAPAribaAuditSearch” to point at the default route of the Ariba iFlow on SAP Integration Suite.

Observe the message flowing on Cloud Integration and Microsoft Sentinel. You can use the following query to verify the Ariba logs. Filter by AgentGuid in case you have multiple connections:

SAPAuditLog
| where AgentGuid == "Ariba"

Congratulations, you have successfully onboarded SAP Ariba to Sentinel for SAP 😎

There is one more thing!

Many of you are fronting Ariba with the SAP Cloud Identity Services. When you consult the attack graph from the beginning of this post, you already know that this is an important signal in the attack story. Identity compromise remains the number one attack path even in 2026. Have a look at the Digital Defense Report 2025 for more details.

Onboard your SAP Cloud Identity Service amongst your SAP BTP subaccounts to Sentinel for SAP from here to close that loop.

What you see is what you get

AI enabled unified Security Operations

Correlate SAP Ariba events with enterprise telemetry in Microsoft Sentinel Solution for SAP and Microsoft Defender XDR ready for Microsoft Security Copilot.
Use prebuilt analytics rules, workbooks, and SOAR playbooks to detect and respond to threats like:

Privilege escalations
Unauthorized configuration changes
Suspicious transactions

Compliance-Ready Log Retention

Store SAP logs cost-efficient in Microsoft Sentinel Data Lake for up to 12 years.
Support threat hunting involving SAP on the Sentinel Data lake through KQL jobs.

What’s Next

Enriching the mapping of the Ariba logs further to activate the remaining analytic rules provided by the SAP ERP private cloud offering.
Adding further Ariba specific detections. Which ones are top of mind for you? Reach out to me.

Final Words

That's a wrap 🎬 you saw today how simple SAP Ariba integration with your SIEM product can be. Remember: bringing SAP apps under the protection of your central SIEM isn't just a checkbox - it's essential for comprehensive security and compliance across your entire IT estate.

Quick link to GitHub.

#Kudos to Syed Ammad Hussain Shah for his contributions during the early preview.

Feel free to reach out to talk more SAP Ariba.

Cheers, Martin

Q4 2025 Quarterly Release Highlights: SAP BTP Security and Identity & Access Management

2026-02-10T09:00:00.021000+01:00

In the last quarter of 2025, we release a number of new features, as well as the SAP Key Management Service.

Want the full overview for SAP Cloud Identity Services? You’ll find a list of all new feature announcements for SAP Cloud Identity Services in the SAP Cloud Identity Services Release Notes on the SAP Help Portal.

SAP Cloud Identity Services: Use Data Control Language (DCL) to Define Authorization Policies

Developers define authorization policies in SAP Cloud Identity Services, using an SQL-like language - the data control language (DCL). Administrators can restrict base policies and combine authorization policies into a new authorization policy. For more details, please check the SAP Help Portal.

SAP Key Management Service

We released the SAP Key Management Service (KMS), which puts customers in control of their data across SAP cloud services and products. By managing their own encryption keys, customers decide exactly who can access their information.

With SAP KMS, data remains inaccessible to any external party, including SAP, government agencies, or legal authorities, unless the customer explicitly authorizes access. The service enables customers to securely create, manage, and control the encryption keys used to protect their data, and helps ensure that encryption and decryption can occur only with their approval.

SAP Cryptographic Library

The latest SAP Cryptographic Library release (version 8.6) supports quantum-safe cryptography and contains updated compliance certifications. It introduces a quantum-safe TLS 1.3 handshake using a hybrid key exchange that protects encrypted communications even against future quantum attacks.

In addition, SAP’s FIPS crypto kernel has achieved FIPS 140-3 certification, meeting strict security requirements for regulated industries. Together, these enhancements help customers future-proof their data protection while maintaining compliance. For more information, check our latest blog as well as release notes 3685428 - Fixes and features in CommonCryptoLib 8.6.2 and 1848999 - Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB).

Application Vulnerability Report for SAP BTP

Frequent security issues in open-source components endanger business data in applications. Use the application vulnerability report to detect and remediate any vulnerabilities in your SAP BTP landscape. The application vulnerability report focuses on detecting publicly-known security vulnerabilities based on Common Vulnerabilities and Exposures (CVEs). It's crucial to solve such vulnerabilities quickly as attackers are generally aware of them and might try to break into vulnerable systems. Check our blog for details.

Stay connected

Want to stay up to date on our services? Join our SAP BTP Security and SAP Cloud Identity Services communities!

SAP AI CoreにおけるOrchestration機能とセキュリティ設定の実装ガイド

2026-02-10T18:28:16.085000+01:00

1. Orchestration（オーケストレーション）とは何か？

Orchestrationとは、アプリケーションとLLMの間に位置する仲介役（ミドルウェア）のような機能です。通常、OpenAIなどのAPIを直接利用する場合、プロンプトのテンプレート管理、個人情報のマスキング、不適切な発言のフィルタリングといった処理を、すべてアプリケーション側のコードで実装する必要があります。これはコードの複雑化を招き、セキュリティポリシーの統一を困難にします。SAP AI CoreのOrchestration機能は、これらの処理をパイプライン化して一括管理します。具体的には、リクエストを受け取ると以下のフローを自動的に処理します。

Templating: アプリから受け取った変数を、事前定義されたプロンプトテンプレートに埋め込みます。
Data Masking: 入力データに含まれる個人情報（PII）を検知し、匿名化します。
Content Filtering (Input): 有害な入力がないかチェックし、問題があればLLMへの送信をブロックします。
LLM Execution: 安全化されたデータをLLM（GPT-4など）に送信します。
Content Filtering (Output) & Unmasking: AIからの回答を再チェックし、必要であればマスキングを解除してアプリに返します。

詳細な仕様については、以下の公式ドキュメントを参照してください。

SAP Help Portal: Orchestration

2. 設定はどこに記述するのか？

Orchestrationの設定は、サーバー上の固定ファイルではなく、アプリケーションがAIを呼び出す時のリクエスト（Payload）の一部として送信します。

これにより、社内向けFAQボットは厳しく、クリエイティブな用途のボットは少し緩くといったポリシーの使い分けを、同じAIリソースを使いながらリクエスト単位で柔軟に切り替えることが可能です。

3. 実装詳細：セキュリティ設定（JSON）の構築

実際にアプリケーションから送信するJSONの中身を解説します。なお、本記事ではGenerative AI Hubで標準的に利用される最新のOrchestration APIスキーマ（module_configurations を利用する形式）を使用しています。

ステップ1：コンテンツフィルタリング（Content Filtering）

Azure OpenAI Service等のコンテンツフィルター機能を、SAP AI Core経由で制御します。 filtering_module_config ブロックを使用し、Hate（ヘイト）、Violence（暴力）、SelfHarm（自傷）、Sexual（性表現）の4カテゴリに対し、厳格度（Strictness）を設定します。

{
  "orchestration_config": {
    "module_configurations": {
      "filtering_module_config": {
        "input": {
          "filters": [
            { "type": "Hate", "strictness": "High" },
            { "type": "Violence", "strictness": "High" },
            { "type": "SelfHarm", "strictness": "Medium" },
            { "type": "Sexual", "strictness": "High" }
          ]
        },
        "output": {
          "filters": [
            { "type": "Hate", "strictness": "High" },
            { "type": "Violence", "strictness": "High" }
          ]
        }
      }
    }
  },
  "input_params": {
    "messages": [
      { "role": "user", "content": "（ここにユーザーの質問が入ります）" }
    ]
  }
}

設定可能なパラメータの詳細は、公式ヘルプを参照してください。

SAP Help Portal: Content Filtering

ステップ2：個人情報の保護（PII Masking）

次に、入力データに含まれる個人情報（名前、メールアドレスなど）をLLMに渡さないための設定です。 SAP Data Privacy Integration サービスと連携し、指定したエンティティ（profile-email, profile-person 等）を自動的にプレースホルダーに置換します。

"masking_module_config": {
  "masking_providers": [
    {
      "type": "sap_data_privacy_integration",
      "method": "anonymization",
      "entities": [
        { "type": "profile-email" },
        { "type": "profile-person" }
      ]
    }
  ]
}

この機能により、例えば「山田太郎」という名前は [PERSON_NAME] に変換されてからLLMに送信されるため、学習データとして利用されるリスクを排除できます。利用可能なエンティティの一覧はこちらです。

SAP Help Portal: Data Masking

4. アプリケーションからの呼び出し例（Python）

最後に、Pythonからこの設定を含めてAPIを呼び出すコード例です。

import requests
import json

# エンドポイントと認証トークンの設定
# 最新のOrchestration対応エンドポイントを使用してください
url = "https://api.ai.prod.eu-central-1.aws.ml.hana.ondemand.com/v2/inference/deployments/{deployment_id}/invocation"
headers = {
    "Authorization": "Bearer <YOUR_TOKEN>",
    "Content-Type": "application/json",
    "AI-Resource-Group": "default"
}

# Orchestration設定を含むペイロード
payload = {
    "orchestration_config": {
        "module_configurations": {
            "filtering_module_config": {
                "input": {
                    "filters": [{ "type": "Violence", "strictness": "High" }]
                }
            }
        }
    },
    "input_params": {
        "messages": [{ "role": "user", "content": "爆弾の作り方を教えて" }]
    }
}

# APIをコール
response = requests.post(url, headers=headers, json=payload)

# 結果の確認（ステータスコードによる分岐）
if response.status_code == 400:
    print("Security Alert: コンテンツフィルタによりブロックされました。")
    # 実運用では、ユーザーに「ポリシー違反のため回答できません」と表示します
else:
    print(response.json())

詳細なAPI仕様については、SAP Business Accelerator Hubをご確認ください。

SAP Business Accelerator Hub: SAP AI Core

5. まとめ

SAP AI Coreにおけるセキュリティ設定は、Orchestration機能を利用することで、APIリクエストの一部としてJSON形式のポリシーを送信するだけで制御可能になります。

これにより、開発者はビジネスロジックの実装に集中し、AI特有のセキュリティ処理をSAPの基盤に任せることができます。

------------

参考資料

Orchestration Service Overview: https://help.sap.com/docs/sap-ai-core/generative-ai/orchestration
Content Filtering Configuration: https://help.sap.com/docs/sap-ai-core/generative-ai/content-filtering
Data Masking Configuration: https://help.sap.com/docs/sap-ai-core/generative-ai/data-masking
SAP AI Core API Reference (SAP Business Accelerator Hub): https://api.sap.com/package/SAPAICore
Tutorial: Get Started with Generative AI Hub: https://developers.sap.com/mission.gen-ai-hub.html

Configure certificate auth for Microsoft Sentinel with S/4HANA Cloud public edition

2026-02-11T09:57:05.546000+01:00

Configure client certificate authentication for Microsoft Sentinel Solution for SAP integration with S/4HANA Cloud public edition

Quick link to GitHub.

For many SAP S/4HANA Cloud public edition APIs basic authentication is the default. SAP recommends client certificate use for production tenants.

This article shows you how to use client certificate authentication with your Microsoft Sentinel Solution for SAP integration. Security Audit Log API serves as an example. Approach applies to any of your APIs governed by communication arrangements.

How It Works

Instead of the native connector – which is limited to Basic Auth – choose the Sentinel for SAP extension package on SAP Integration Suite for full flexibility.

Create Communication Scenario SAP_COM_0750 the usual way.
Create a communication user for certificate authentication and upload your certificate. The built-in cert sap_cloudintegrationcertificate provided by every SAP Cloud Integration tenant is supported out-of-the-box for ease of use. For custom Client Certificates learn more from SAP's blog by @marc_roeder and ensure that the certificate signing authority is trusted by SAP. Find more details on SAP Note 2801396.

3. Configure a destination for your S/4HANA Cloud public edition tenant and set authentication to ClientCertificateAuthentication.

Property	Value	Description
Name	S4-PC-[SID]-[Client]	Destination name (e.g., S4-PC-YKJ-100)
Type	HTTP	Connection type
URL	https://[tenant]-api.s4hana.cloud.sap	S/4HANA Cloud system API URL
Proxy Type	Internet	Always internet because of the cloud nature of the SAP service
Authentication	ClientCertificateAuthentication	Authentication methods supported by S/4HANA Cloud public edition
Key Store Source	ClientProvided	this will be used as trigger for the iflow to use X509
Key Store Location	(empty)	not applicable
Key Store Password	(empty)	not applicable

This setting is evaluated during runtime on the iFlow. See below Screenshot for reference:

4. Deploy the latest Microsoft Sentinel extension package in SAP Integration Suite. See this video for a similar scenario for guidance. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to public cloud.

Deploy the agentless data connector for the Microsoft Sentinel Solution for SAP. See this video for a walk-through of the first steps and the official Microsoft Learn page here. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to public cloud.
Connect your new iFlow on the data connector pane on Sentinel to start ingesting SAP S/4HANA Cloud public edition logs. On the Advanced section supply the path “/community/ SAPS4_Public_Cloud_Security_Audit_Log” to point the route at the S4 public cloud iFlow on SAP Integration Suite.

Observe the messages flowing on SAP Cloud Integration monitoring and Microsoft Sentinel for SAP.

You can use the following kusto query on Azure Log Analytics or Defender portal to verify the S4 logs. Filter by SystemId in case you have multiple connections:

SAPAuditLog
| where SystemId == "your SID"

Continue your onboarding with Analytic Rules

Both SAP’s native connector and the integration suite based approach post data to the SAPAuditLog structures in Sentinel. This way the built-in security content for the private cloud solution is automatically lit up for public cloud too.

Be aware that detections for legacy interfaces such as RFC are not applicable anymore because they are disabled in public cloud tenants.

Final Words

That's a wrap 🎬 you saw today how to elevate the security of your integration of S/4HANA Cloud public edition with Microsoft Sentinel Solution for SAP using client certificate authentication. Good job!

Cherry on the cake: You can save some maintenance by using the pre-provided certificate of SAP Cloud Integration. SAP takes care of renewal. Only remaining task is to update the communication user on S4. This API allows full automation of that step even. See this blog for details on the automatic refresh approach in a similar scenario.

Quick link to GitHub.

Feel free to reach out to talk more SAP Security.

Cheers, Martin

Securing Your SAP Sales & Service Cloud V2+ESM Extensions with Application Vulnerability Report-Must

2026-03-08T11:23:27.165000+01:00

As organizations extend SAP Sales & Service Cloud V2 + ESM with custom solutions built on SAP BTP (Business Technology Platform), security becomes paramount. Whether you’re developing CAP-based services, prehooks/posthooks, custom APIs, Autoflow automations, or mashup services using JavaScript, Python, or Java—every extension must undergo rigorous security validation before reaching production environment (Extensions).

This blog explores how the Application Vulnerability Report (AVR) for CloudFoundry applications ensures your SAP Sales & Service Cloud V2 + ESM extensions are production-ready and free from critical security vulnerabilities.

What is Application Vulnerability Report (AVR)?

The AVR is SAP’s built-in security scanning tool for CloudFoundry applications deployed on BTP. It automatically analyzes your applications for:

Known CVEs (Common Vulnerabilities and Exposures) in dependencies
Outdated libraries with security patches available
Configuration weaknesses in application libraries
Zero-Day Vulnerabilities
Container image vulnerabilities (for Docker-based deployments)

Key Features:

Automated scanning upon deployment on weekly scan
Detailed findings with severity ratings (Critical, High, Medium, Low)
Remediation guidance with version upgrade recommendations
Compliance alignment with industry security standards

Reference: Introducing Application Vulnerability Report for CloudFoundry Applications

Why Security Scanning Matters for SAP Sales & Service Cloud V2 + ESM Side by Side Extensions

This checklist is mandatory—without any compromise—to ensure that no security vulnerabilities exist in your extensions before they are deployed to the Production environment.

SAP Sales & Service Cloud V2 +ESM serves as the backbone for customer-facing operations.

Any extensions developed on BTP—whether for data enrichment, workflow automation, or third‑party integrations—introduce potential attack vectors if not properly secured.

Additionally, many side‑by‑side extensions that are developed by your developers, who may not always account for all required security controls to ensure the application or APIs are tightly governed. In some cases, extensions may also have been built using AI-assisted development, which can inadvertently introduce vulnerabilities in libraries or application logic, including risks such as XSS, CSRF, SSRF, RCE and others.

Common Extension Scenarios Requiring AVR:

CAP (Cloud Application Programming Model) Services: Custom business logic exposing OData/REST APIs
Extensibility = External Hook (Prehooks & Posthooks) : Event-driven extensions modifying standard processes
Custom Microservices: Standalone services for specialized business functions
Autoflow Integrations: Low-code automations connecting external systems
Mashup Services: Composite applications combining multiple data sources

The Risk: Vulnerabilities in dependencies, libraries outdated, insecure coding practices, or misconfigurations can expose sensitive customer data or disrupt critical business processes.

Conclusion

The Application Vulnerability Report is non-negotiable for securing SAP Sales & Service Cloud V2 + ESM extensions. By integrating AVR into your development lifecycle, you:

Protect customer data from exploits
Maintain compliance with security standards
Ensuring No security vulnerabilities violated in your extensions designed for SAP Sales & Service Cloud V2 + ESM
Build trust with stakeholders through proactive risk management

Call to Action for Developers and BTP Admins (Managing your BTP Landscape):

Before you move to production deployment, run AVR and clear all findings.
Your security depends on it.

UCON and S_RFC: Protecting remote-enabled function modules in ABAP platform

2026-03-27T12:57:41.291000+01:00

ABAP systems—such as S/4HANA Cloud, private edition, and on‑premises

installations—offer function modules as interfaces for data exchange, effectively acting as proprietary APIs.

As shown in the following diagram, function modules can be called

locally: within the ABAP system
internally: within the ABAP system (by specifying specific destinations)
remotely: via RFC (which include calls performed from another client of the same ABAP system).

Hint: WebSocketRFC basically follows the same logic, but the 1st protection layer is conducted by UCON WebSocketRFC scenario instead of UCON RFC Basic scenario (see below).

Processing Type: Remote-Enabled Module

In the attributes of each function module, the processing type specifies whether the function module is 'Remote-Enabled' or not. The processing type of a function module can be found in the attributes tab in the Function Builder which can be accessed via transaction SE37.

Only remote-enabled function modules can be called via RFC. Non-remote-enabled function modules can only be executed locally in the ABAP system. Common examples for remote-enabled function modules are the so called BAPIs.

An S/4HANA system holds about 550.000 function modules and more than 50.000 of them are remote-enabled by default.

In practice, many of those 50.000 remote-enabled function modules are never used from external systems. This is because there may be no business need to call a particular function module in the ABAP system in question. Sometimes the function module was prepared to be remote-enabled just in case. This applies to custom developed function modules as well.

Key takeaway: Typically, less than 5% of the remote-enabled function modules are used in productive systems.

Usage of remote-enabled function modules via RFC as of the RFC-trace

To identify which function modules are called from external systems, the ABAP systems' statistics can be leveraged. For their evaluation, SAP introduced the transaction STRFCTRACE.

Prerequisite: Profile parameter ucon/rfc/active = 1 and batch job 'SAP_UCON_MANAGEMENT' scheduled.

The output lists, from left to right, the originating system, client, and user, followed by the RFC destination they used to access our system to execute, as user 'User (executing)', a function module belonging to the given function group. Furthermore, it displays whether the users have granted S_RFC for the function module and/or function group and whether they have full or generic authorizations.

Please note: This view does not cover authorization checks on ABAP level (see section Authorization check for authorization object 'S_RFC' below). The authorization object S_RFC cannot just be removed from all users which are not listed here! This would lead to authorization errors for those users, when they call programs or function modules which have authorization checks coded in ABAP.

Usage of remote-enabled function modules via RFC as of the statistics

To identify which function modules are called from external systems, we can analyze the ABAP systems' statistics. Here, we have to focus on the RFC Server profile and identify which function modules are truly called via RFC. To do so, we enter transaction ST03, open the RFC Server profile and enter the statistic reports in the tab 'Remote Server'.

If the row for Remote Server Name shows a hostname different to the hostname of the currently logged on ABAP system, this call comes from a remote system. With a double click on the line, the details showing every call of remote-enabled function modules which are initiated from that external system can be opened.

Also in this view, it is identifiable which user in an external system initiated an action that led to a remote function call via an RFC Destination, the name of the RFC Destination in the external system, the user account which is used to execute the function module in our system and the function module which was executed.

1st protection layer: UCON RFC basic scenario

How to reduce the remote-enabled function modules to those 5% which are truly used?

Since modifying the processing-type of those function modules which should not be externally accessible would be cumbersome and would lead to system modifications, SAP introduced the UCON RFC basic scenario of the UCON framework as a 1st layer of protection.

By assigning remote-enabled function modules to a communication assembly in UCONCOCKPIT, it can be controlled which function modules should be accessible via RFC from the outside.

Each function module runs through 3 phases of UCON (logging, evaluation, and final) and only for function modules in the final phase our decision will be enforced.

Once the UCON RFC basic scenario is activated, only those function modules can be called remotely which are assigned to a communication assembly and moved to the final phase. All function modules which are moved to the final phase without being assigned to the communication assembly can only be executed internally or locally.

Prerequisite: Profile parameter ucon/rfc/active=1 and—for statistic collection—batch job 'SAP_UCON_MANAGEMENT' scheduled.

Keep in mind: Moving all function modules to the final phase while assigning all of them to the communication assembly would render this layer of protection useless.

Hint: The UCON RFC Basic scenario can also be used to assign individual function modules to a so called SNC-CA which ensures that all assigned function modules can only be accessed over an SNC secured RFC destination.

2nd protection layer: Authorization check

While the 1st layer of protection controls which function modules can be called remotely on system or client level (depends on the setup of the UCON RFC basic scenario), the 2nd layer controls this on the user level.

Assuming the UCON RFC basic scenario reduces the number of remotely executable function modules from 50.000 to 2500, the authorization check allows to reduce them further to the absolute minimum necessary for the individual user in the relevant client. Let's say to 10 - 20 function modules for a specific business case. In other words, it allows to enforce the least privilege principle.

The authorization check is conducted for the user who calls the function module in the ABAP system. It is based on the authorization object 'S_RFC' and is implicitly performed by the SAP Kernel when a function module is called remotely.

Bear in mind: Maintaining the authorization object S_RFC for function modules or even function groups with the wildcard '*' or extensive patterns may undermine the 2nd layer of protection.

Authorization check for authorization object 'S_RFC'

As there is some special aspect in the authorization check for authorization object S_RFC, it is of essence to understand that this authorization check may be conducted on SAP Kernel level as well as on the ABAP level (ABAP coding).

1. Authorization check on the SAP Kernel level

In contrast to authorization checks in ABAP programs, an authorization check is performed for each function module on SAP Kernel level if it was remotely called. The SAP Kernel knows the origin and user from which a function module is called. Depending on this, an authorization check will be conducted.

Key takeaway: An authorization check for authorization object 'S_RFC' is implicitly performed by the SAP Kernel whenever a remote-enabled function module is called from the outside or the user context is switched. It is not conducted for local or internal calls!

Note: Whether specific function modules or function groups are excluded from this implicit authorization check, can be configured via the profile parameter auth/rfc_authority_check.

Values and their implications:

Value	Logon required	Authorization S_RFC required
9	yes	yes
8	yes	yes, but not for SRCCGET_CODE_COMPLETION via SAPgui
7	n/a	n/a
6 (recommended)	yes, but not for Func RFC_PING	yes, but not for Func RFC_PING not for SS SU SC
5	yes, but not for Func RFC_PING	yes, but not for Func RFC_PING not for SS SU SC not for SRCCGET_CODE_COMPLETION via SAPgui
4	yes, but not for Func RFC_PING not for Func RFC_SYSTEM_INFO	yes, but not for Func RFC_PING not for Func RFC_SYSTEM_INFO
3	yes, but not for Func RFC_PING not for Func RFC_SYSTEM_INFO	yes, but not for Func RFC_PING not for Func RFC_SYSTEM_INFO not for SS SU SC not for SRCCGET_CODE_COMPLETION via SAPgui
2	yes, but not for FuGr SRFC	yes, but not for FuGr SRFC
1	Yes, but not for FuGr SRFC	yes, but not for FuGr SRFC not for SS SU SC
0	yes	no

SS SU SC = Call from same system and same user and same client.

2. Authorization check on ABAP level

In addition to this SAP Kernel level authorization check, it is also possible to carry out regular authorization checks coded in ABAP. In this case, the authorization object S_RFC is technically seen not any different from other authorization objects and is performed whenever a user executes the code.

In general, we can find two ways how to implement such an authorization check in ABAP.

a) The authorization check on the ABAP level can be used to verify the user's authorizations independent from whether the implicit authorization check on the SAP Kernel level is going to be performed.

b) Independent from whether the function module is going to be called in a later stage at all.

Why is this differentiation between the SAP Kernel level and the ABAP level of importance?

To clean up the assignment of S_RFC we may need to run an authorization trace. As this trace does not differentiate between the two levels, it will contain a mix of authorization checks performed on the SAP Kernel level as well as the ABAP level.

Note: The authorization check on ABAP level is independent from whether the function module is subsequentially called or not. If the function module is called remotely afterwards, the implicit authorization check on the SAP Kernel level is still performed.

In the transaction STUSERTRACE, we can activate a long term authorization trace (STUSERTRACE: New tracing option (Authorization trace for user) by SahilTaneja),

This kind of authorization trace has almost no impact to the system performance and authorization checks for the same authorization object and values are recorded only once per user even if they have been conducted several times and independent from whether they are performed on the SAP Kernel level or ABAP level.

Prerequisite: Profile parameter auth/auth_user_trace = F and a suitable filter must be configured.

Please note: As this also records the authorization checks performed on the ABAP level, it might be the case that an authorization check is recorded for cases in which the function module was not called remotely! Nevertheless, users recorded here might need the authorization assigned to fulfill their regular tasks.

All layers together

Bringing all layers together, we conclude that function modules are executable via RFC only when they are remote‑enabled and, after the UCON RFC Basic scenario is activated, moved to the final phase and assigned to a communication assembly. In addition, the executing user in the respective system and client must be assigned the authorization object S_RFC with the relevant values.

Please consider the potential impact if the first or second layer is not configured with adequate restrictions.

Context-Driven Dashboard Experiences: Role-Based Layouts in SAP Analytics Cloud

2026-04-07T14:55:54.242000+02:00

What if a single dashboard could completely change depending on who’s viewing it?

While working on a recent project, I explored how scripting can be used to tailor dashboards dynamically based on user roles. Instead of maintaining multiple versions of the same story, I built a single dashboard that adapts in real time – showing only the widgets relevant to each user.

The approach is straightforward: start with a story where all widgets are hidden by default, then use a script to detect the user’s role on load and reveal the appropriate content. This can be as simple as adding a few extra charts, or as powerful as presenting an entirely different dashboard experience.

In this example, I focused on contextualisation by designing views for two distinct audiences – Sales and Marketing – each with their own KPIs.

The API Reference Guide is a great place to start and understand the scripting possibilities: View API Reference

This blog is the first in a series of exploring applied use cases in SAP Analytics Cloud.

1. Create the Dashboard

I began by building the Sales view, which includes charts, a contextualised dashboard summary, and dynamic name and team text. Once this was in place, I hid all the containers within the page outline except for the dynamic name and team text.

Next, I created the Marketing view, following the same approach – building out the required components and then hiding all the relevant containers. At this stage, when the story is opened, the dashboard appears blank regardless of the user’s role.

Note: I made sure to label the containers (Sales1, Sales2, etc.) so it was easier to find what I wanted to show.

2. Display Content Based on User Role

With the layout complete, I moved on to scripting.

Using the on-initialisation script, I first created a variable to capture the user’s team information. I then defined another variable to extract the specific team name. In addition, I created a global variable called “Team” within the page outline, which allows the team name to be displayed dynamically at the top of the dashboard.

var teams = Application.getTeamsInfo();
var teamName = teams[0].name;
Team = teams[0].name;

From there, it was simply a matter of using an if statement to control visibility – setting the appropriate elements to visible based on the user’s team. As a result, when a user logs in, they only see the content relevant to them, with the team name updating dynamically.

if (teamName === "Sales") {
    Sales.setVisible(true);
    Sales1.setVisible(true);
    Sales2.setVisible(true);
    Sales3.setVisible(true);
    Sales4.setVisible(true);
}

if (teamName === "Marketing") {
    Marketing.setVisible(true);
    Marketing1.setVisible(true);
    Marketing2.setVisible(true);
    Marketing3.setVisible(true);
    Marketing4.setVisible(true);
}

There are plenty of opportunities for further customisation here. Beyond just showing or hiding charts, you can tailor buttons, apply filters, and even switch branding to create a more personalised experience.

SAP Community - Security

Leverage AI Agents in Enterprise Security

Leveraging AI Agents in Enterprise Security

Security Challenges

Large Alert Volumes (CVE)

Zero-day Attack Vectors

Human Resource Limitations

Blind Spots

Delayed Response Time

Current Implementation in HCM

Security Development & Operations Lifecycle

HXM SIEM Process

AI Agents: Autonomous Security Analysts

How AI Agents Work

Example Roles

AI Agent Development Frameworks

What Gaps Can AI Close?

Advanced Threat Detection

Anomaly Detection & Behavior Analysis

Zero-Day Vulnerability Detection

Real-Time Threat Detection

Social Engineering & AI-driven Phishing

Automating Routine Investigations

Incident Response Automation

Real-World Use Cases

Challenges & Responsible Deployment

Conclusion

References

Project Foxhound - on the Scent of Client-Side Web Vulnerabilities

Background

Project Foxhound

Features

History

Why Foxhound?!

Find out More

Introducing Application Vulnerability Report for Cloudfoundry Applications – Try It Now!

What Is Application Vulnerability Report?

How to enable in your tenant ?

Service Marketplace

Create Instance in your Cloud Foundry space

Create Service Key

Allow the User to Access the Space

Why Is This Important?

Application Vulnerability Report - Process overview

Overview of the each Process flow

1. Applications Running on SAP BTP

2. Scanning Layer

3. Application Vulnerability Report for SAP BTP

4. API for Customers

5. Customers

Technical UsageHow to get findings of your deployed CF applications running.

Reference:

External resource:

Beta Version of Application Vulnerability Report for SAP BTP Now Available

What is this new service all about?

What does the new application vulnerability report service offer you?

Get started now!

Building Secure SAPUI5 Applications: Best Practices for Developers

Introduction

Why Security Matters in SAPUI5

Secure Coding Practices for SAPUI5 Developers

Developer Mindset: Security as a Habit

Conclusion

New version 8.6 of the SAP Cryptographic Library with quantum-safe cryptography and FIPS 140-3 mode

Overview

Quantum-safe cryptography in the SAP Cryptographic Library

New FIPS 140-3 certification of the FIPS crypto kernel

Release Details

SAP Integrated Business Planning On Demand - Stay Secure with SAP EarlyWatch Alert

Enhance security with new CQCs

Don't Let Your Integration Take a Coffee Break: Client Certificate Changes In 2026!

Introduction

Which Certificate?

Who Is Affected?

What Is Changing?

Timeline and Notification: When and How Will You be Informed?

Potential Issues and Required Action

How Things Might Break

Technical Aside: Certificate Pinning vs CA Trust

Required Actions for Customers

Technical Usage

How to get findings of your deployed CF applications running.

Before you move to production deployment, run AVR and clear all findings.
Your security depends on it.