In this blog post series, we will familiarize you with the processes and tools that we at SAP apply for a secure handling of our open-source supply chain. The series will start with an introductory post outlining on agile development stages and principles, followed by 3 posts focusing on the development stages as well as the toolset shared by SAP with the community. Find below the references to the correlated blog posts:
Introduction to SAP tools supporting the secure development process with Open Source (the current article)
Introduction: The challenge of agile and secure development processes
Security has become a major challenge to software development teams nowadays. Agile development requires consistent security activities in short cycles, deprecating traditional models that validate the security of the application in the production state. The challenges of iterative, incremental, and evolutionary development require an agile framework with processes and the joint collaboration of the developers with the corporate and operative stakeholders aiming for state-of-the-art security. The process is supported by tools that either automate parts of the security assurance or help to identify, triage and mitigate security risks closest to the code itself – that’s what we call a DevSecOps toolset.
Different models for the software development process have been established over the last decades. The concept of continuous delivery has, in some instances, been evolved to the extent that every code change results in a new productive version. Experience has shown that the ability to dramatically lower the time-to-deploy goes along with a rising efficiency in meeting customer expectations, if automation is applied to assure product quality metrics. Let me use the analogy of the car manufacturing process as a tangible model for non-techies to outline on the software development principles and the tools that SAP provides to the open-source community:
All software products start with a blueprint that defines how the product should look based on customer needs and the strategic direction of the software company. The blueprint gives a detailed picture of the final product and defines the functional and quality criteria that are applied throughout the remaining product development phases by engineering. Because later changes in the platform and architecture result in high costs, the emphasis is put on reducing engineering changes to a minimum after the design phase. Design decisions therefore need to be well aligned. A wide range of product engineering, manufacturing, purchasing, and sales expertise is incorporated – a concept which Toyota calls the “obeya” (big room).
The development phase of the software is like the car engineering phase in which a first version of the product is assembled based on the concept. The concept is validated several times throughout the engineering process to increase maturity and customer appreciation. Quality issues are resolved in case they show up during assembly and functional tests. The product is tested under real-world conditions and acceptance tests are run. This process may result in minor adaptions and requires a consistent overview of the simulated and real-time measured KPIs of the product, production, technology, the product lifecycle processes and customer feedback for engineers to take the right decisions.
The transition of the prototype to the final product goes along with final quality and compliance checks. What is called a CI/CD pipeline in software development nowadays can be correlated to the production line where cars are assembled by a predefined script. Car manufacturers foresee massive testing of the production, supply chain and maintenance processes. All supplied parts and the final assembled product must go through these tests. The main criteria for the testing procedure have been derived in the design and engineering phase. When in productive usage, cars are consistently monitoring the health state in addition to regular service activities. Likewise, modern software operations implement monitoring and audit controls.
Eclipse Steady is a code analysis tool released by SAP as open-source. It not only allows you to identify vulnerable dependencies, but also analyzes the reachability of the vulnerable code in the given application context. Thereby, developers can derive the actual exposure and have code-centric compatibility information at hand for the ease of mitigation.
The stages of the software development lifecycle are of relevance to all development roles, whether these are software architects, quality managers, DevOps or security experts. Though, software development is an agile process nowadays. Thereby it requires a high level of automation and flexibility to react to continuous product-feature enhancements based on its defined core architecture.
Developing with open-source allows to leverage the solutions by the community but also requires additional measures for secure appliance. SAP, as a major software vendor, is one of the drivers for agile software development. Based on the experience and the expertise of its large developer base, SAP has built its own toolset complementing commercial solutions for quality assurance. In this blog series, we will introduce you to some of the tools that SAP shares with the community as part of an open-source project. The overarching aim of these tools? In the end, we want to help developers write secure software most efficiently with the possibility for you to see how it fits your development processes. Follow us, we would love to hear your feedback on this and on upcoming posts!