This is post three in a series on the Application Program Maturity Curve. A dedicated and rigorous Application Security Program is best pursued as a sustained, policy-driven program that employs proactive, preventative methods to manage software risk. It will deliver an effective software security strategy that addresses both immediate and systemic risks with a rigorous plan and continued investment. The mantra of any successful appsec program is utilization, adoption and expansion. Without a clearly defined and governed policy, none of these is possible. The information security team is specifically charged with setting appsec policy, obtaining its governance mandate, and setting goals and objectives for the program. A good appsec policy identifies the processes, controls, tools and resources necessary for success. It establishes standards and practices for assessing software risk, including detection of high-risk vulnerabilities and prioritization of mitigation and remediation efforts. Application Security deserves executive sponsorship. Often the toughest hurdle is helping executive management understand that application security is a significant business risk – no less important than network security! Policy definition is typically completed during the Blueprint Program stage (level 2). With proper stewardship, this process can be completed in 30 days or less; it needn’t take months. With this in place, your organization is ready to move to the next level.
Level 3: Baseline Program Objective: We’re rolling it out. Program: Test all critical apps, scorecards results and onboard development teams. Time Period: As little as 60 days. The next maturity stage focuses on rapid deployment of the program and baseline testing of critical applications. Success at this level is all about adoption – making it easy for others to play an essential role in securing the software portfolio. The goal is to get your new appsec program up and running with the right team in place. It’s also important to understand what the Baseline stage is not. It’s not about implementing complex security gates that impede the development process. The application teams identified during the discovery process must now be onboarded and back the effort – a delicate undertaking to be sure. App developers will resist approaches to application security that they find cumbersome or an impediment to their delivery schedule. The objective is to bring them aboard as quickly as possible, in as little as 1-2 weeks. That’s how quick it should take to scan each application once using your chosen testing technology and to return results for group review. They’ll still require some convincing. The last section of this guide provides some insight into developer diplomacy. Be sure to select a testing technology that supports self-service, so developers themselves can control the process. Minimize impact on developers with a system that dovetails with their chosen SDLC. Your organization must create its own recipe for the testing mix based upon your unique business requirements. Some decisions include static vs. dynamic testing? On-premise install vs. a cloud service? Licensed enterprise-wide or subscription per-developer seat? Implemented by employees or by expert consultants? Only your organization can answer these questions for itself.
|Your Situation||Developer Need|
|Ad-hoc development projects or where gated security testing is suitable||Quick “submit binary – get results” type of testing service|
|Development teams & SDLCs that leverage IDEs with heavier development, shorter release cycles||Testing service available on the desktop|
|Agile SDLCs with constantly changing builds and constant releases||Integrated, scheduled, “behind-the-scenes” testing service|
Finally, set reasonable remediation targets at the start – for example fixing only cross-site scripting or buffer overflow errors first. Your software security policy should allow an application to exit the program and deploy only when it fulfills certain benchmarks, so make these initial goals attainable. Perhaps a single SDLC integration point to start that uses existing workflows. Allow each development team to dictate the exact test and fix regimen according to their unique product schedules. The Baseline Program stage should focus on raising risk awareness and securing a commitment to improve software security. Employ parallel engagement with multiple development teams at once. This way all critical teams can be able to be introduced to the program – and all apps baseline scanned – in about 60 days.
Level 4: Integrated Program Objective: We’re going big! Program: Sustainable program scaled across enterprise with full SDLC integration. Time Period: About 3 months. It’s time to go big or go home. Sometimes a bit of adrenaline is all it takes to achieve success at this next appsec maturity stage. Sustaining an Integrated Program in your organization involves a continuing drive to make it systemic, repeatable and ongoing. The next level is all about scale. The objectives at this maturity stage are to integrate the program deeper into your software development lifecycle (SDLC), track its success metrics with scorecarding, and begin formal developer education programs. Tracking along the curve, at this point you should be following well-defined policies, controls and processes for securing your internal software based on baseline measures and inherent risk profiles. Applications are being remediated and re-assessed at regular intervals as code changes or other triggers necessitate. Beginning to deepen SDLC integration, this effort captures the objectives of each development team and identifies appropriate integration points in their existing development workflow. Sustained risk mitigation begins with changing poor appsec practices from the inside. If the short-term focus of the Baseline Program was to on-board development teams quickly and easily, the longer term focus of the Integrated Program is to actively train and certify teams on safe coding practices. Choose from a variety of eLearning curricula available that deepen each team’s knowledge and skillset and introduce some informal courses at this stage. CA Veracode’s services for developers help integrate security with the SDLC. Read more. The final post in this series will examine the last two stages of the Application Program Maturity Curve. Post 1: About the Appsec Program Maturity Curve Post 2: Program Levels 1 to 2 – from Ad-Hoc to Blueprint Post 4: Program Levels 5 to 6 – from Improved to Optimized