Here at Abricto Security, we believe that application penetration tests only reveal the tip of the iceberg. Specifically, if we conduct an application penetration test and we find that it’s riddled with vulnerabilities, the remediation effort shouldn’t stop once those vulnerabilities are patched and the application gets shipped. Instead, we believe the mantra that “security is a process not a destination” and that a proper secure software development lifecycle (SSDLC) can enable that.

When discussing software security, we often say security should be baked in, not bolted on. This blog post extrapolates what that means.

The SSDLC can be broken down into five or six different steps depending on who you’re asking. We define them as:

  1. Security Training
  2. Requirements
  3. Planning and Design
  4. Development
  5. Verification and Testing
  6. Release and Maintain

These six steps are cyclical; as products are developed and matured over time, they typically undergo multiple major releases.

Once a major release is published, the cycle restarts as the team prepares to begin work on the next iteration.

Unfortunately, product security teams are often seen as roadblocks to the progress of an application’s development and subsequently, its release. However, if a partnership with the development team is cultivated early-on, security can be an enabler and even a strategic differentiator to enable product sales.

Here is how product security teams can embed themselves in the SSDLC:

Security Training

Seek to understand the application stack that the development team typically uses. Generally speaking, the team probably already has an idea of what programming language(s) they’re going to use for the current or upcoming project.

Having this context, the product security team can develop a curriculum of language-specific security training to share with the development team. Adhering to the OWASP top 10 vulnerabilities is a great place to start.

It’s crucially important that the training be delivered in an interactive environment where the developers can play with vulnerable code and trigger exploits themselves to understand why vulnerabilities exist and how to fix them.

Requirements

It is the role of the product security team to understand how the development and engineering teams will address the following concerns:

  • Data privacy as governed by regulatory bodies
  • Data tagging capabilities and requirements
  • Operational risk once the product is deployed
  • Tracking of third-party components
  • Internal and contractual audit compliance
  • Role-based access controls
  • Supporting internal and external identity providers

An effective technique we use at Abricto Security is to leverage “evil user-stories” in a project’s epic. This approach generates a list of capabilities that users of the application should explicitly not be able to do. Some example “evil user-stories” would be:

  • A user should not be able to update another user’s profile
  • A user should not be able to purchase items without paying
  • A user should not be able to over-whelm the application API with more than 5 requests per second

These “evil user-stories” are assigned to developers to ensure that security is proactively being built-in to the application.

Planning and Design

During the planning and design phase of the SSDLC, the product security team meets with the product architect, engineering and operations team to compose a comprehensive threat model of the product. This is a critical phase of the SSDLC where the product security team attempts to understand all potential areas of attack surface before a single line of code is written. While such an understanding is difficult to accomplish, having all teams on the same page and aware of potential risks is invaluable. Complete threat models have a visual diagram accompanied by a report of each component and its associated attack-vectors.

Example of a threat model diagram

Development

As developers begin bringing the product to life, the product security team can expedite the time-to-completion by providing IDE plugins to actively scan for insecure code as the application is being developed. This means developers are notified about vulnerabilities as they are being written and can remediate them in real-time rather than insecure code breaking the build during compilation. Such expeditious feedback is a security super-power that makes a significant impact to a product’s overall security posture in the latter phases of the SSDLC.

In addition to IDE plugins, an organization’s CI/CD pipeline should have some automated static code analysis (SCA) and static application scanning tools (SAST) embedded to check for vulnerabilities that may’ve slipped by the IDE plugins. Some open-source SAST tools we recommend include:

  • Brakeman
  • Find security bugs
  • Sonarlint
  • SonarQube
  • Graudit
  • NodeJsScan

Organizations with mature CI/CD practices should also be leveraging nightly automated dynamic application security testing (DAST) tools. This augments penetration testing in the next phase by finding some low-hanging security issues in the application, freeing up penetration testers’ time to focus on more complex vulnerabilities.

Verification and Testing

This phase of the SSDLC is where manual DAST scanning and penetration testing takes place. Offensive security engineers (penetration testers) emulate real-world attackers’ techniques and methodologies to identify vulnerabilities in the application that automated scanners often miss; such vulnerabilities are typically business-logic, authentication and authorization related.

Seasoned penetration testers will request access to the application’s code base to validate suspect vulnerabilities and to debug exploit code. While penetration tests are intended to resemble actual attack scenarios, we find that adhering to a methodology works well to avoid missing any unturned stones. The methodology we follow is OWASP’s Testing Guide.

Release and Maintain

Once the application has been built, it’s ready to be shipped. The release and maintain phase of the SSDLC focuses on collecting application security logs and tracking vulnerabilities in the application’s stack.

Here, it’s important to collect security-related transactions which are important for incident response and security monitoring. Such events should be collected by a security information and event management (SEIM) solution. The SEIM should be tuned to accurately correlate related events to trigger alerts for the security team to investigate.

3rd party components of applications often have new vulnerabilities discovered and published. Such vulnerabilities may then affect applications using those 3rd party components. It’s important to maintain an inventory of such 3rd party components and the applications that use them to be able to respond appropriately to vulnerability disclosures.

In upcoming blog posts, we’ll take an in-depth dive to implementing automated security checks in a CI/CD pipeline, subscribe to our newsletter below to be notified when those get published.