In my previous post, DevSecOps and Release Coordination, I introduced the idea of four key players in the DevSecOps mediated release management process. The idea is to consolidate the validation and approval steps from a “gated” process, and shift the actual work of validation earlier in development. In this post, we will explore the role of the Security Architect in the overall development, testing and release of the software. To aid teams in understanding this role better I created a persona. This is a first-person description of the role, the responsibilities, tooling, and key artifacts.
I am therefore pleased to introduce you to Sanghita, your Security Architect.
Security Architect Persona
As the Security Architect, I am responsible for assuring that all appropriate corporate security policies are defined, communicated, followed, and that the product is compliant with regulatory, corporate, and industry security best-practices.
My primary responsibility is to ensure compliance with security policy and that the application is built using secure coding practices. I also ensure the vetting of third-party component integrations for risks. My involvement is throughout the development process, starting with the Product Owner for review of user stories impacting regulatory compliance. Then, with the Development Lead to determine potential systematic vulnerabilities in the application and to ensure that the test team has created appropriate functional security test cases. When the Product Owner schedules a candidate release for production, I am asserting that security test cases have passed and all appropriate security controls/mitigations are in place.
Figure 1. The security architect is one of the four key roles in release coordination.
Before the actual production deployment, there are four required key release readiness states (Figure 2). These four product statuses provide confidence to the release team that the production candidate release is ready for prime time. The team consists of the Product Owner, Operations Coordinator, Security Architect, and the Release Coordinator. This team represents the sole deciders for what is, and is not, releasing to production. The decision is influenced by product quality, compliance, and organization’s readiness to support. Each member of the release team is responsible for one of these states. This role ensures the production release preparation for the organization. During regularly scheduled release meetings, the team reviews each scheduled product release and capture the four readiness states. The product release moves forward with approval of all readiness states.
Release Readiness States
Figure 2. Release readiness states with owning personas
In this approach, only four reviewers/approvers exist for any given product release. The full authority for that release is also born by these four roles. This greatly improves both the speed of release approval and clearly assigns the ultimate responsibility for release success.
Tool Use and Workflow Responsibilities
The Security Architect utilizes multiple automated tooling to perform much of the “heavy-lifting” for security and compliance review of candidate releases. Of these, the code and component scanning (e.g. Nexus IQ, Veracode, etc.) are of the highest value. This permits the Security Architect to provide direct feedback on security policy violations early in the development effort, thereby facilitating correction or mitigation of the vulnerability. Finally, as part of ‘attack surface modeling,’ the Security Architect provides useful guidance to the development teams on where to focus application security hardening efforts.
Figure 2. The security architect utilizes automation tooling to accomplish many of her workflow responsibilities
The Security Architect’s responsibilities include:
- Review of all scanning results (i.e. static code, dynamic application, component vulnerabilities)
- Recommendations for remediation or compensating controls
- Review of security and compliance policy (especially for automated tooling)
- Governance over secure coding best-practices
- Periodic review of regulatory compliance requirements with the development groups
The Security Architect verifies that all security functional testing has completed successfully. She also ensures mitigation or control of all discovered vulnerabilities.
Key Artifacts
There are several key artifacts that the Security Architect either uses, tracks, or otherwise manages:
- Security Checklist – A brief description of common security vulnerabilities for use during the review of new business requests.
- Third-Party Component Policy – Automated policy statements (e.g. via Sonatype Nexus IQ) to ensure the enterprise is using secure open source components. These policies require periodic review and update to ensure newly found exploits are controlled.
- Development Security Policy – A collection of security policies designed to aid development teams in remediation/control for commonly found vulnerabilities.
- Code and Application Scan Results – Compiled results from the various automated security tools. Used to communicate with the Development team for vulnerability remediation/mitigation.
Conclusion
The Security Architect’s role in release coordination primarily focuses on secure code creation. This includes identification and mitigation of potential vulnerabilities and the assertion of release readiness. Readiness states are based on the audit results of automated and manual security reviews. As the point person for security, the Security Architect works closely with the team members to ensure the delivery of a highly secure product.
