The Zensai Secure Development Lifecycle (SDLC) is inspired by Microsoft's Security Development Lifecycle Practices and is made up of a set of practices that support Zensai developers in building more secure software. The practices lessen the number and severity of software vulnerabilities and, hereby, ensure our platform fulfills compliance requirements and can assure customers and partners that security has been embedded into the development process of our products.
In this article, we will describe the set of practices in the Zensai SDLC.
In this article
- Secure code training
- Security quality level standards and reporting
- Management of security and license risk of third-party components
- Static Analysis Security Testing (SAST)
- Dynamic Analysis Security Testing (DAST)
- Penetration testing
- Quality Assurance
- Framework security controls
- Separate environments
Secure code training
It is important that the people building the Zensai platform understand security basics and is aware of how to build security into software to prevent attempts from attackers and create a more secure product.
At least annually, Zensai software engineers participate in secure code training covering the Open Web Application Security Project (OWASP) top 10 security risks, common attack vectors, and Azure security controls.
Security quality level standards and reporting
The Zensai platform has defined levels of security quality to have a set standard for the minimum acceptable level of security quality and to have exact routines of how to respond to security vulnerabilities of different severity. This helps our team identify and address security defects appropriately and in due time, and to deliver a consistently high standard of security quality throughout all development phases.
Security defects and security work items are registered and clearly labeled allowing for clear tracking and reporting of work related to security.
Management of security and license risk of third-party components
A vulnerability of a third-party component can impact the security of the larger system the component is integrated into.
Zensai has an accurate inventory of third-party components employed. Open source dependencies for known vulnerabilities are found and updated recommendations for the third-party libraries are provided, when required to avoid vulnerabilities.
Static Analysis Security Testing (SAST)
To ensure secure coding policies are being followed, the source code is scanned and analyzed directly within the Integrated Development Environment (IDE) Visual Studio and the Azure DevOps build pipeline, used by the Zensai development team, prior to compilation.
Providing automated feedback and preventing any known security vulnerabilities from being added to the Zensai environment, this is a scalable method of security code review that helps spot flaws at an early stage.
Dynamic Analysis Security Testing (DAST)
An automated penetration and continuous scanning of the packaged software, configurations, and settings, is running regularly as part of the Zensai software release cycle to test the security when all code is integrated and running.
The test engine stays up to date on the behavior of hackers and cybersecurity patterns to identify any new potential risks.
Penetration testing
In a penetration test, skilled security professionals will simulate the behavior of a hacker to discover potential exploitable vulnerabilities.
Automated and manual penetration tests are performed on Zensai applications and underlying web applications to uncover potential coding errors, configuration flaws, or other weaknesses that can create a vulnerability in the Zensai platform.
Quality Assurance
Our Quality Assurance (QA) department reviews and tests our codebase. Dedicated application security engineers identify, test, and triage security vulnerabilities in the code.
Framework security controls
Zensai leverages the latest Microsoft .NET Core open-source framework with security controls in place to limit exposure to OWASP top 10 security risks. These inherent controls reduce our exposure to SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF), among others.
Separate environments
Development, testing, and staging environments are logically separated from the Zensai production environments. No customer data is used in any of our development and/or test environments.