While most IT Executives, Program Managers, and technical staff are well-versed in both Agile and DevOps methodologies, many development projects consider security to be a post-development, test-and-correct function that frequently requires backtracking and remedial development. Obsidian’s  DevSecOps approach “shifts security to the left” in part by ensuring that developers are trained, experienced, and disciplined in producing code developed to industry security standards that is validated to be free of security defects as code is being developed. Our approach encompasses the entire Software Development Lifecycle (SDLC) and includes agile development, continuous integration, continuous testing, and continuous delivery while providing continuous security testing throughout every phase of the lifecycle. 

 

Automation is a critical component of Obsidian’s DevSecOps approach, and the tools in this space continue to rapidly advance. Our successful approach is agnostic to a specified toolset and customizable based on customer preference or investment in tools. The key steps for automation that enable our DevSecOps include:

1. Daily Code Commit. Our Developers check-in code on a daily basis into a central source code repository. SAST tools are run every time code is committed and attempt to highlight vulnerabilities within static source code using techniques such as Taint Analysis and Data Flow Analysis.

2. Automated Builds. A Continuous Integration (CI) server is continually polling the source repository for changes; when a change occurs, the code is checked out of the repository and built. The built software is stored in a repository manager by the CI server.

3. Automated Testing. The code is automatically unit tested; code quality tested; code static, dynamic, and interactively security tested; smoke and UI tested; and performance tested. DAST tools are run on operating code to detect issues with interfaces, requests, responses, scripting (i.e. JavaScript), data injection, sessions, authentication, and more. IAST tools are run using knowledge of application and data flow to create advanced attack scenarios.

4. Automated Delivery. The built version is deployed using provisioning tools that treat infrastructure as code and is integrated into the CDM testing tools, monitoring tools, and processes that may include Splunk, Nessus, McAfee ePO, New Relic, etc.

 

Continuous Integration (CI) and Continuous Delivery (CD) are designed to create an automation environment for the entire end-to-end release process so that every change to the application results in a releasable, security-validated version that is built automatically. Applications are built from a very early stage in the development process at specific frequent intervals or every time our developers commit code. This effectively eliminates the need for integration testing because the code is incrementally being integrated. The enablement of frequent incremental builds and an automated testing process also allows our developers to detect problems early, ensuring higher application quality and security.