There has been some confusion recently among company departments surrounding the term DevSecOps.
When it’s working well, DevSecOps integrates the best security practices into the DevOps process. The integration comes in leveraging agile development concepts with automation to increase the pace at which new services are introduced via code. It's important to note that this integration must take place through the collaboration of release engineers and security teams to end the siloed environment that fosters bottlenecks in a continuous process of creating new solutions.
The biggest advantage of the DevSecOps approach: it introduces a new development mindset that makes everyone in the organization responsible for securing code by embedding “security thinking” into the entire change process, from the executive board to the individual teams. This universal approach helps bridge the gap between IT and security teams while promoting a faster and safer method to produce new business services. However, enhanced agility, rapid change response, and early code vulnerability identification do require the necessary tools to support the following to ensure effective DevSecOps: continuous monitoring; scanning for security defects; attack detection; and change management and governance.
Security testing against the items mentioned above must stay consistent, but in iterations to not slow down code development and delivery cycles. However, running manual security checks during development can cause significant delays in code delivery. Therefore, security team must implement an automated process to assure any successful DevSecOps endeavor, especially when dealing with an application as integrated and complex as SAP.
Automated SAP DevSecOps
SAP has a very significant footprint inside global corporations. SAP.com posts that SAP customers generate 87% of total global commerce ($46 trillion), 99 of the 100 largest companies in the world are SAP customers, and 85 of the 100 largest companies around the globe are SAP S/4HANA customers. Given the size and importance of these SAP installations, it stands to reason that companies need to think about code security from the very start of any development.
However, SAP poses a challenge because it does not offer the native tools to validate source code for security flaws. In addition, it’s a monolithic system with a tightly-integrated database and application layer. Because of this structure, developers find it difficult to collaborate on the same code set, and often there’s little to no reviewing custom codes or transports because it’s too time-consuming.
To circumvent this time-consumption problem, third-party software tools must scan for potentially vulnerable source code, such as identifying vulnerabilities that allow SQL injections, cross-site scripting, or missing authorization checks in the development process. When dealing with an application as complex as SAP, these additional software tools must have a code vulnerability analyzer to complement standard SAP systems by integrating within the SAP development IDE. Analyzing vulnerabilities from the beginning of code production—within a collaborative team-enabled, agile environment—will ensure that new business functions are deployed without significant security defects. Automating the security checks in the development phase ensures quick code passage into testing. From there, it’s a matter of applying quality gates as a failsafe to prevent the SAP transport management system from moving a source code without proper security validation.
Adopting a DevSecOps philosophy when producing new SAP business functions will ensure security remains a top priority from the very beginning of code production. It’s important to foster and follow an agile process to cut horizontally through any vertical development silos so that teams move forward in a collaborative environment. To ensure speed and quality of code production, teams must apply automated analysis of SAP security settings so that a security dialogue accompanies the new business code as it moves onto the “go-live” phase.
It’s important to note that security teams should not consider the go-live phase the end of the DevSecOps cycle; this phase only defines the handover to the “Keep-System-Running” (KSR) teams. A focus must remain on DevSecOps for SAP, where automated monitoring for attack detection, regular vulnerability assessments, and accurate security patching remains ongoing. To ensure this vigilant focus, many organizations are turning to third-party applications for the automation that helps ensure a timely DevSecOps process.
Christoph Nagy, co-founder and CEO, SecurityBridge
