Custom code security is the practice of reviewing, testing, and controlling application code that is built or modified for a specific SAP environment. Weaknesses in custom code can create hidden logic flaws, privilege paths, or validation gaps that standard controls do not automatically catch.
Expanded Definition
Custom code security is the discipline of governing SAP-specific development so that bespoke logic, extensions, exits, and integrations do not bypass the controls that standard functionality would normally enforce. It includes source review, secure design, test coverage, segregation of duties, transport control, and runtime monitoring across code that was written for a particular environment rather than delivered as-is by the platform.
In SAP estates, custom code often sits at the boundary between business process freedom and security assurance. That boundary is where hidden validation gaps appear: an approval rule is skipped, a privilege check is weakened, or a data path is exposed through an integration that was never threat-modeled. Guidance varies across vendors on how much of this should be handled by application security, basis teams, or IAM teams, but no single standard governs this yet. For broader control mapping, practitioners often anchor the practice to NIST Cybersecurity Framework 2.0 and then adapt it to SAP change governance.
The most common misapplication is treating custom code security as a one-time code review, which occurs when teams sign off at go-live and do not reassess the code after transport, patching, or role changes.
Examples and Use Cases
Implementing custom code security rigorously often introduces delivery friction, requiring organisations to weigh faster SAP change cycles against stronger assurance that business logic still enforces access, validation, and auditability.
- Reviewing ABAP custom transactions for missing authorization checks before they reach production, especially where the code calls sensitive tables or privileged function modules.
- Testing user exits and BAdIs for input validation gaps that could allow privilege escalation, data tampering, or unsafe downstream processing.
- Scanning transport packages for embedded secrets or hard-coded credentials, then tracing those findings back to code ownership and remediation workflow.
- Applying secure code gates to custom integrations that move identity or token data between SAP and external services, with reference to the patterns discussed in Analysis of Claude Code Security.
- Mapping code review findings to secure development controls in NIST Cybersecurity Framework 2.0, then using release gates to prevent insecure transports from advancing.
For SAP-focused governance, NHI Management Group notes that long-term credentials are frequently stored directly in code, which turns custom development into an identity risk as well as an application risk. That is why control reviews should not stop at syntax or performance and must also inspect whether code creates hidden execution paths for accounts, tokens, or service identities. Related operational context appears in the Ultimate Guide to NHIs, where code-adjacent secret exposure is treated as a systemic identity weakness.
Why It Matters in NHI Security
Custom code security matters because custom logic often becomes the place where non-human identities are granted convenience without governance. A service account, API key, or technical user may be introduced for an extension, then reused across transports, environments, or automations with little visibility. That creates a path for excessive privilege, poor rotation discipline, and silent persistence even after the original business need has changed.
The NHI Management Group research highlights the scale of this exposure: 30.9% of organisations store long-term credentials directly in code, and 96% store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools. Those conditions make custom code a security boundary, not just a development artifact. In practice, teams need to treat code ownership, secret handling, and access pathways as part of identity governance, using controls that support NHI lifecycle management alongside secure engineering. The issue becomes especially visible after a breach investigation, when an overlooked custom routine is found to have preserved access long after the original credentials should have been revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Custom code often stores or exposes secrets that OWASP NHI treats as improper secret management. |
| NIST CSF 2.0 | PR.DS-1 | Protecting data at rest and in use extends to credentials and sensitive values embedded in custom code. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires every custom path to verify identity and privilege rather than trust the code path. | |
| OWASP Agentic AI Top 10 | Custom code can create unsafe tool access paths similar to agentic execution and privilege escalation risks. | |
| NIST AI RMF | Risk management applies when custom logic introduces integrity, confidentiality, or misuse risk in AI-adjacent flows. |
Scan code and transports for embedded secrets, then remove them from custom logic and rotate any exposed credentials.
