Software Security Assurance Maturity Self-Assessment

HPE Security Products

Take this short self-assessment to evaluate your company's existing software security program. And get recommendations to help you reach your security goals

Software Security Policy

1: We have completed an inventory of our organization's entire software portfolio (including in-house development, COTS, third-party development, etc.)

2: We have classified all applications in our portfolio according to type of data stored or handled.

3: We have completed a risk exposure analysis of our business-critical applications.

4: We maintain per-project data for the cost of software security activities.

Software Security Policy (continued)

5: We document our security processes, and communicate expectations to project stakeholders.

6: Our organization has one designated group or team responsible for Software Security Assurance.

7: We have documented and communicated secure coding standards to everyone involved in software development.

8: We systematically audit projects and/or teams for compliance with published security practices and/or regulatory requirements.

9: Our software suppliers and development partners are contractually required to demonstrate a process to find and fix security vulnerabilities in development.

Software Security Policy (continued)

10: We have a role-based security education program in place.

11: We have an internal certification program available for developers to support application security awareness.

12: We periodically test all of our software developers for application security knowledge.

Secure Development & Testing

13: We maintain a library of permitted application frameworks/versions that are allowed into new applications during the design process.

14: We have a documented process to track the usage and security impact of third-party and/or open-source software components in our products.

15: We maintain secure coding guidelines for all programming languages in use by our development team(s).

16: We regularly verify that the secure coding guidelines are being followed.

Secure Development & Testing (continued)

17: We regularly document potential threats and create attack trees.

18: Our threat modelling activity covers third-party software?

Secure Development & Testing (continued)

19: We conduct security code reviews on all code check-ins.

20: Development teams regularly perform automated source code analysis, prior to check-in, as part of their workflow.

21: Stakeholders regularly review the results or metrics from the security code review activities.

22: Evidence of the security code review process is routinely required as a part of software release.

23: Project teams document the attack surface of new applications.

24: Do your organization's project stakeholders have an etablished process to request a security design review?

25: Is there an established release gate or project audit item for documented design reviews?

26: We have an established security gate to identify vulnerabilities in all releases.

27: We have an established security gate and go/no go decision agreement in place before software goes into production.


28: We order/perform penetration testings on software releases and routinely on applications in production.

Deployment (Continued)

29: Development teams in our organization routinely document their applications' deployment environment requirements.

30: Projects in our organization routinely utilize some form of automation in production to monitor application health.

31: We routinely document security exception handling for our organization's projects sent to production.

32: We routinely and consistently use code signing in deployment of our applications.

33: We actively monitor applications running in production to collect and respond to threat intelligence.

34: In addition to application security activities during software development, we wrap high-risk applications in a protective environment such as a monitored sandbox or application firewall in deployment.

Deployment (continued)

35: Projects sent to production have a designated security point of contact (or vulnerability response team).

36: We have a complete feedback loop to share incidents and identified vulnerability information back to development and design teams.