Back

How BlueOptima Supports DevSecOps

leave a reply | January 31 2018

DevSecOps, put simply, is the emphasis of security in the operations surrounding the development and deployment of software which is otherwise known as DevOps. Is it necessary to propagate yet another portmanteau buzzword? While DevSecOps has been an important part of DevOps best practice before the term existed, it serves to draw attention to important considerations. BlueOptima supports enterprises to this end.

DevSecOps involves the inclusion of threat modeling, risk assessment, automation of security engineering tasks, and an emphasis on development team collaboration around software security considerations. The chief objective of DevSecOps is for security engineering considerations to become ingrained in regular operational processes because application security cannot be retrofitted; it must be a primary consideration of all software engineers at the point of originally authoring, enhancing, or refactoring code. Ultimately, a successful DevSecOps strategy should facilitate the contribute of "value" to the software development process by security engineers with less "friction". What do we mean by "friction"? Traditional application security assurance approaches have very significant limitations in many organisations because they tend to be bureaucratic, involve mandates from a central authority, and be monolithic or 'one size fits all'. These factors hinder resultant security measures in applications as they often focus on insignificant hypotheticals versus actual real-world threats.
There are some key hallmarks of a successful DevSecOps initiative and BlueOptima helps organisations embed those hallmarks into their software development processes as follows:

1. Automate security invocation - BlueOptima provides commit level automation of analysis and reporting into security considerations of security insights as changes are delivered by engineers.
2. Integrate to “fail quickly” - BlueOptima provides estate wide monitoring ensuring consistent monitoring across your entire technology stack. Violations are reported in a timely fashion to be fed into daily stand-up meetings.
3. Ensure no false alarms in the process - BlueOptima's approach to security risks is uniquely attuned to the velocity, scope, and context of the Actual Coding Effort delivered into source code. This means that there are fewer false positives which ensures that your engineers are less likely to start ignoring security risk warnings.
4. Build security champions - BlueOptima directs reports to key team members, empowering them to ensure that best practices are adopted within their team. This devolves responsibility for security to the team level, getting to a core objective of DevSecOps; widespread awareness of security.
5. Keep operational visibility - BlueOptima's always-on monitoring of source code repositories and task tracking systems means that security considerations are top of mind through the development process and not just at build and deployment time.

BlueOptima monitors source code change delivered by software engineers for the top 10 OWASP vulnerabilities.1

In addition to OWASP vulnerability scanning BlueOptima uses machine learning and other advanced statistical approaches to the commit histories of source files to identify security hotspots and how they relate to application complexity and maintainability as measured by BlueOptima's ART metrics. This statistical analysis also identifies specific scenarios in which individual engineers who have repeatedly introduced a vulnerability or those have repeatedly fix them or ignore them when subsequently changing files.

BlueOptima provides a capability that is at the heart of the DevSecOps manifesto by providing consistent and timely insights into source code security that are baked into the ongoing operation of delivering software change across the application estate of the enterprise.

1. Java is the only language currently in-scope for 2018. Three of the Top 10 OWASP scanning capabilities will be provided for Java by the end of June 2018. A further three vulnerabilities by end of Q3 of 2018. The remaining four by end of Q4 2018.

Next
Comments
No comments yet. Be the first.
Archives