How proactive is your software security initiative?

A proactive software security initiative protects your organization. Does your software security measure up? Take our 12-question quiz to find out.

The bad news is that software gets hacked. The defects and vulnerabilities that attackers take advantage of to hack software can be introduced by an organization internally or by their vendors or partners.

The good news is that remediation methods to resolve these defects and vulnerabilities are well known. Organizations with a mature software security initiative (SSI) have processes and guidance in place that go beyond a basic “penetrate and patch” approach. These processes contribute to a prevention approach that stops some defects from ever being created and ensures others are fixed during development rather than right before, or even after, release.

So how proactive is your software security initiative? How do you even measure software security?

Sponsorships Available

Sponsorships Available

Sponsorships Available

The questions below are inspired by the Building Security In Maturity Model (BSIMM) and highlight the 12 most common software security activities observed in real initiatives. They weren’t thought up in a classroom or around a conference table. Instead, they’re being performed by real companies who consider security a worthwhile investment. Take the quiz to establish a basic measure of your own software security initiative.

Quiz: How does your software security initiative measure up?

1. Privacy obligations

Does your organization analyze your privacy obligations?

Privacy is a hot topic. The decision to collect, or not collect, personally identifiable information (PII) data can be a big one. By accepting certain pieces of information, your organization may be opening itself up to additional risk.

86% of BSIMM10 participants identify PII obligations and define best practices surrounding PII.

2. Pre-built security features

Does your organization maintain a repository of pre-built security features?

Some problems are best solved only once. After a while, teams and organizations will start solving standard problems with standard solutions, whether internally built or integrated commercial off-the-shelf (COTS).

80% of BSIMM10 participants have pre-approved solutions available for developers.

3. Security feature failures

When designing applications, does your team review how security features might fail or be bypassed in the application?

Security features are tools, and the hammer that pounds the nail can easily crush your thumb. Development teams and security-aware architects should ensure that the security features they use can’t be easily bypassed by attackers.

84% of BSIMM10 participants perform reviews to see how their security features might fail or be implemented incorrectly.

4. Security checkpoints in the SDLC

Does your organization’s SDLC include security checkpoints for software development projects?

When developers know when the test will be, they can be better prepared. Organizations should perform tests at regular stages of development to ensure that they’re developing software securely.

88% of BSIMM10 participants set security gates and check security-related artifacts during the SDLC.

5. Functional testing and more

Does your organization go beyond standard functional testing?

Secure software is quality software. Testing how an application responds when it encounters unexpected behavior is the first step toward ensuring that attackers can’t use erratic behavior to gain entry to an application.

82% of BSIMM10 participants ensure that QA supports edge/boundary value condition testing.

6. Pen testing

Do you use external penetration testers or submit your applications for external review?

Good external penetration testers will approach your application the same way hackers do. By bringing in third-party experts, you are bringing both new expertise and an unbiased eye to your testing efforts.

89% of BSIMM10 participants use external penetration testers to some degree.

7. Defect tracking

Does your organization have a system for tracking defects found by penetration testing?

By now, developers have grown accustomed to automated ticketing workflows. All their work and productivity is driven via tickets. Instead of issuing PDF reports, more organizations are instead pushing findings and defects via the developers’ own ticketing system.

77% of BSIMM10 participants feed pen testing results to their defect management and mitigation system.

8. Defects found in operations

Is there a formal way for operations to report security defects to developers?

Nobody is perfect. Having a good communication flow between developers and the operations team is a great way to close the loop on the bugs that make it past all the safeguards.

83% of BSIMM10 participants have open channels of communication for relaying security defects back to developers and improving processes.

9. Tracking operations fixes

Does your organization track bugs found in operations throughout the fix process?

Another benefit of the ticket-based workflow that drives many developers’ day-to-day activities is that when defects are tracked via that same ticketing system, the organization now has an automated defect tracking system that allows operations and application security to see the status of security issues within the organization.

72% of BSIMM10 participants track software bugs found in operations through the fix process.

10. Environment configuration

Does your organization ensure that application host environments are configured securely?

While a secure network and host aren’t a complete security solution, insecure infrastructure and servers can let hackers access your application in ways you never intended. Ensure that servers, networks, and other infrastructure follow approved environment and configuration guidelines for additional depth of defense.

91% of BSIMM10 participants analyze server and network configurations to prevent vulnerabilities at those levels.

11. Incident response

Does your organization have an incident response plan?

Even if an organization isn’t growing a DevOps culture, better communication and integration between Development and Operations can improve how quickly and effectively the organization responds to incidents of all sorts.

84% of BSIMM10 participants create or interface with incident response.

12. Emergency preparedness

Can your organization update your applications quickly in an emergency?

As attacks gain visibility in the news, as well as ever-increasing fines for violating standards such as PCI DSS, being able to respond to an incident with an existing plan leads to quicker and smoother mitigation than an ad hoc effort that has to be built on the spot.

75% of BSIMM10 participants have emergency codebase response.

How do you measure software security?

It takes a village to raise a child, and it takes an entire organization to achieve an emergent property such as software security. Small changes and safeguards can improve software security every step of the way. Not every activity is right for every organization. But if you aren’t doing at least a few of these activities, you’re subjecting yourself to unknown risks that you could easily address. The BSIMM allows you to measure software security in your organization against over a hundred other organizations so you know where you are and can plan where to go next.

This post was originally published Oct. 19, 2015, and refreshed Sept. 30, 2019.