This blog post is part of a blog series outlining on the processes and tools that we at SAP apply for a secure handling of our open-source supply chain. If you haven’t read the introductory blog post, you may want to read it first here. Find below the references to the correlated blog posts:
- Introduction to SAP tools supporting the secure development process with Open Source
- Support the selection of Open Source by security ratings
- Performing security scans early in development (the current article)
- Perform more accurate vulnerability reviews by code-centric analysis
Introduction: "Define once, run everywhere" principle of Project "Piper"
In the first article we compared the software deployment/delivery process to the manufacturing production line in the automobile industry. This time we look in particular into the quality assurance process. In software development the production line is called Continuous Integration and Continuous Delivery (CI/CD) pipeline. Automation is crucial to assure all deliveries are compliant to the corporate quality criteria in a short evaluation cycle. Evaluating the security qualities of the delivery, as part of a dedicated security stage in the pipeline, has become state-of-the-art. Project “Piper” started as an Inner Source project at SAP and is meanwhile available to the community as an open-source project. It supports continuous delivery including all security aspects for Jenkins-based pipelines. Its Go-reimplementation meanwhile also brings the same features to any other pipeline. It reduces the maintenance effort by applying the principle to store all pipeline configuration in your code repository (Configuration-as-Code). “Piper” provides numerous pipeline step implementations that allow you to integrate a wide variety of open-source and commercial tools for security, license, unit tests and beyond with just a few lines for configuration[1].
Sample pipeline steps visualization
Efficient issue resolution is key in an environment where attack patterns are constantly enhancing and the mean-time-to-exploit for profitable vulnerability disclosures is shrinking. Wherever there is delay in reporting identified issues or there is the need for manual and error-prone triaging we see that the efficiency of developer teams decreases significantly.
“Piper” CLI, as the Jenkins-independent implementation, is SAP’s solution to improve developer efficiency. It is designed for ease of usage requiring just a Linux-runtime (or the WSL-runtime on Windows) and a Go-runtime environment. It reuses the step configuration of the Jenkins-based implementation and comes with a similar set of supported steps. That allows every developer to run quality checks on the local machine before the coding is committed to the repository. Integrating “Piper” CLI into your development environment (IDE) can further improve the user experience. In addition, “Piper” was enhanced by a GitHub Action. The GitHub Action applies the same general principles, thereby enabling quality scans in your GitHub-based project is a matter of seconds.
How does it all link together, making the secure development process easy instead of overloading development teams? The most efficient resolution is done by the developers during the time that someone is developing. Though, running a full set of quality checks might take too much time. Using the configure-once, use-everywhere principle of “Piper” the following procedure is most advisable:
- Project “Piper” CLI[2] lets the individual developer perform the most critical checks, avoiding critical findings to break the pipeline and thereby cause disruption to the whole team.
- Project “Piper” GitHub Action[3] allows you to constantly check the composition of the code changes by all team members with the enhanced set of checks, timely reporting issues to the corresponding commit author.
- Project “Piper” for Jenkins[4] or its Jenkins-independent Go-implementation act as the final delivery validation running the full set of quality and compliance checks. Findings that deviate from the defined security standards may break the build process, requiring interaction by the development before final delivery.
Conclusion
Inheriting open-source in your project requires you to continuously evaluate the quality and security of the components. The appliance of checks throughout the development process safes you from any hick-ups during or after the delivery. Project “Piper” allows you to run the same set of quality and security checks using one configuration in your IDE, your code repository and as part of the pipeline. Write your configuration once and apply it everywhere!
Try it out, the usage of “Piper” is easy and brings the value of highly decreased operation and training costs with the ability to enhance the solution to your own needs!
[1] https://sap.github.io/jenkins-library/configuration/
[2] https://sap.github.io/jenkins-library/cli/
[3] https://github.com/SAP/project-piper-action
[4] https://sap.github.io/jenkins-library/
- SAP Managed Tags:
