Application security can make or break entire companies these days. So how can you better secure your product?

The answer to this question is more important than ever. When a company ignores security issues, it exposes itself to risk. Huge amounts of sensitive data are stored in business applications, and this data could be stolen at any time. Businesses that underinvest in security are liable to end up with financial losses and a bruised reputation.

What's more, governments are now legislating and enforcing data protection measures. For example, the European Union's GDPR requires organizations to integrate data protection safeguards at the earliest stages of development. Ignoring these requirements can result in hefty fines.

When end users lose money, they do not care whether the cause lies in application logic or a security breach. Building secure applications is as important as writing quality algorithms. For those who succeed, cost-effective security improvements provide an edge over competitors.

There is a ready-made solution that provides a structured approach to application security—the secure development lifecycle (SDL). It is a set of development practices for strengthening security and compliance. For maximum benefit, these practices should be integrated into all stages of software development and maintenance.

The most important reasons to adopt SDL practices are:

• Higher security. In SDL, continuous monitoring for vulnerabilities results in better application quality and mitigation of business risks.
• Cost reduction. In SDL, early attention to flaws significantly reduces the effort required to detect and fix them.
• Regulatory compliance. SDL encourages a conscientious attitude toward security-related laws and regulations. Ignoring them may result in fines and penalties, even if no sensitive data is lost.

SDL also provides a variety of side benefits, such as:

• Development teams get continuous training in secure coding practices.
• Security approaches become more consistent across teams.
• Customers trust you more, because they see that special attention is paid to their security.
• Internal security improves when SDL is applied to in-house software tools.

Before we discuss how to add SDL practices to software development, let's consider typical development workflows.

The simplest waterfall workflow is linear, with one stage coming after the other:

The agile workflow, by contrast, goes through many cycles, each of which contains the same set of stages:

Other workflows are possible as well. They all consist of the same basic building blocks (application development stages):

1. Concept and planning
2. Architecture and design
3. Implementation
4. Testing and bug fixing
5. Release and maintenance
6. End of life

Most of the measures that strengthen application security work best at specific stages. This is why it is important to plan in advance. Secure development methodologies come in handy here—they tell you what to do and when.

In the following sections, we provide an overview of these software development stages and relevant SDL recommendations.

1. Concept and planning

The purpose of this stage is to define the application concept and evaluate its viability. This includes developing a project plan, writing project requirements, and allocating human resources.

SDL practices recommended for this stage include:

• SDL discovery
  SDL discovery starts with defining security and compliance objectives for your project. Then select an SDL methodology and write a detailed plan of relevant SDL activities. This ensures that your team will address security issues as early as possible.
• Security requirements
  Prepare a list of security requirements for your project. Remember to include both technical and regulatory requirements. Having this list helps to easily identify and fix potentially non-compliant areas of your project.
• Security awareness training
  Training sessions provide essential security knowledge ranging from basic threat awareness to in-depth information on secure development. Basic security training establishes a security mindset for all project participants. Advanced courses teach secure design principles to key project participants.

Adopting these practices improves the success of project planning and locks in application compliance with security standards. This stage also allocates the necessary human resources with expertise in application security.

2. Architecture and design

The purpose of this stage is to design a product that meets the requirements. This includes modeling the application structure and its usage scenarios, as well as choosing third-party components that can speed up development. The result of this stage is a design document.

SDL practices recommended for this stage include:

• Threat modeling
  Threat modeling consists of identifying probable attack scenarios and adding relevant countermeasures to the application design. Modeling uncovers possible threats early, thus reducing the associated costs, and also lays the basis for future incident response plans.
• Secure design
  The design document and subsequent updates are validated in light of the security requirements. Early design reviews assist in identifying features exposed to security risks before they are implemented.
• Third-party software tracking
  Vulnerabilities in third-party components can weaken the entire system, making it important to monitor their security and apply patches when necessary. Regular checks of third-party software help to spot areas threatened by compromised components and fill in the gaps.

Adopting these practices identifies weaknesses before they make their way into the application. Checking compliance mitigates security risks and minimizes the chance of vulnerabilities originating from third-party components.

3. Implementation

This is the stage at which an application is actually created. This includes writing the application code, debugging it, and producing stable builds suitable for testing.

SDL practices recommended for this stage include:

• Secure coding
  Guides and checklists remind programmers of typical mistakes to be avoided, such as storing unencrypted passwords. Enforcing secure coding principles eliminates many trivial vulnerabilities and frees up time for other important tasks.
• Static scanning
  Static application scanning tools (SAST) review newly written code and find potential weaknesses without having to run the application. Daily use of static scanning tools uncovers mistakes before they can make their way into application builds.
• Code review
  While automated scanning saves a lot of effort, manual code reviews are still a must for building secure applications. Timely reviews help developers to flag and fix potential issues before they shift attention to other tasks.

Adopting these practices reduces the number of security issues. Combining automatic scanning and manual reviews provides the best results.

4. Testing and bug fixing

The purpose of this stage is to discover and correct application errors. This includes running automatic and manual tests, identifying issues, and fixing them.

SDL practices recommended for this stage include:

• Dynamic scanning
  Dynamic application scanner tools (DAST) expose vulnerabilities by simulating hacker attacks at runtime. To reduce false positives, you can use a combined approach (IAST). This approach complements runtime scanning with monitoring of executed code and application data flow. In addition to discovering regular vulnerabilities, dynamic scanning pinpoints configuration errors that impact security.
• Fuzzing
  Fuzz testing involves generating random inputs based on custom patterns and checking whether the application can handle such inputs properly. Automated fuzzing tools improve protection from attacks that use malformed inputs, such as SQL injection.
• Penetration testing
  It is a good idea to invite a third-party team of security professionals to simulate possible attacks. External experts rely on their knowledge and intuition to reproduce attack scenarios that might be overlooked by your team.

Adopting these practices further reduces the number of security issues. Combined with the activities from the previous stages, this provides decent protection from a wide range of known threats.

5. Release and maintenance

At this stage an application goes live, with many instances running in a variety of environments. Eventually new versions and patches become available and some customers choose to upgrade, while others decide to keep the older versions.

SDL practices recommended for this stage include:

• Environment management
  Real attackers exploit environment configuration errors and vulnerabilities. Security monitoring must cover the entire system, not just the application. Such monitoring improves the overall security of your application.
• Incident response plan
  An incident response plan clearly describes the procedures your incident team must follow to address any security breaches that might occur. Swift execution of the response plan is crucial for triage and repair of security breaches.
• Ongoing security checks
  Security checks must be repeated on a regular basis because new types of vulnerabilities are being discovered at a steady rate. Regular checks protect your application from newly discovered vulnerabilities.

Adopting these practices helps to respond to emerging threats quickly and effectively.

6. End of life

"End of life" is the point when software is no longer supported by its developer. Applications that store sensitive data may be subject to specific end-of-life regulations.

SDL activities recommended for this stage include:

• Data retention
  Governments define retention policies for some data types. Double-checking your company's retention policies for compliance with legal requirements reduces the risk of unexpected fines.
• Data disposal
  At the application's end of life, all sensitive data stored in it must be purged carefully. Examples of such data are encryption keys and personal information. Proper data disposal at the end of life keeps such information confidential and prevents data breaches.

By adopting these practices, developers ensure enough time to develop policies that comply with government regulations.

Some organizations provide and maintain SDL methodologies that have been thoroughly tested and field-proven across multiple companies. Each methodology includes a comprehensive list of general practices suitable for any type of company. They come with recommendations for adopting these practices for specific business needs. You can think of SDL methodologies as templates for building secure development processes in your team.

So when a methodology suggests specific activities, you still get to choose the ones that fit you best. For example: Does your application feature online payments? If so, and if the methodology recommends security training for your team, then you might want to arrange thorough training on PCI and SOX for them.

Popular SDL methodologies are not tied to any specific platform and cover all important practices quite extensively. Any of them will do as a starting point for SDL at your company. It's a good idea to take a deeper look at each before making a final decision, of course. You can also customize them to fit your software development cycle. This article provides an overview of three popular methodologies: Microsoft SDL, SAMM, and BSIMM.

SDL methodologies fall into two categories: prescriptive and descriptive. Prescriptive methodologies explicitly advise users what to do. The "descriptives" consist of literal descriptions of what other companies have done.

Microsoft Security Development Lifecycle (SDL)

Microsoft SDL was originally created as a set of internal practices for protecting Microsoft's own products. In 2008, the company decided to share its experience in the form of a product. Microsoft SDL is a prescriptive methodology that advises companies on how to achieve better application security.

Microsoft SDL is constantly being tested on a variety of the company's applications. Its developers regularly come up with updates to respond to emerging security risks. It covers most aspects of security, with the exception of regulatory compliance and data retention and disposal.

Microsoft provides consulting services and tools to help organizations integrate Microsoft SDL into their software development lifecycles.

OWASP Software Assurance Maturity Model (SAMM)

SAMM is an open-source project maintained by OWASP. Contributions come from a large number of companies of diverse sizes and industries. Thanks to this, virtually any development team can draw upon SAMM to identify the activities that suit their needs best.

Just like Microsoft SDL, this is a prescriptive methodology. SAMM defines roadmap templates for different kinds of organizations. These templates provide a good start for customizing SAMM practices to your company's needs.

This methodology is designed for iterative implementation. For each practice, it defines three levels of fulfillment. You can use this scale to evaluate the security profiles of your current projects and schedule further improvements.

Building Security In Maturity Model (BSIMM)

Originally branched from SAMM, BSIMM switched from the prescriptive approach to a descriptive one. It does not tell you what to do. Instead, BSIMM describes what participating organizations do.

As of this writing, the latest version (BSIMM 10) is based on data from 122 member companies. BSIMM is constantly evolving, with annual updates that keep up with the latest best practices.

In addition to a complete compilation of activities, BSIMM provides per-industry breakdowns. These more targeted lists can help to evaluate the importance of specific activities in your particular industry.

Like SAMM, BSIMM provides three levels of maturity for secure development practices. You can use it to benchmark the current state of security processes at your organization.

Ready to take your first steps toward secure software development? Here is our advice:

• Review popular SDL methodologies and choose the one that suits you best. Do so at the beginning of your project. The cost of delay is high: the earlier you find potential security issues, the cheaper it is to fix them.
• "Mind the gap"—match your current security practices against the list of SDL activities and identify the gaps.
• Read case studies on SDL implementation in projects similar to yours. Consider their successful moves and learn from their mistakes.
• Come up with a list of practices to cover the gaps. Prioritize them and add activities that improve security to your project's roadmap.
• Get buy-in from management, gauge your resources, and check whether you are going to need to outsource.
• Train your team on application security and relevant regulations to improve awareness of possible threats.
• "Shift left" by implementing each security check as early as possible in the development lifecycle. This will save you a lot of resources, as the price of fixing security issues grows drastically with time.
• Automate everything you can. Take advantage of static code scanners from the very beginning of coding. Add dynamic scanning and testing tools as soon as you have a stable build.
• Do not hesitate to hire outside experts. Arrange for security audits, since an outside point of view might identify a threat you failed to notice.

Following these guidelines should provide your project with a solid start and save both cash and labor.