{"id":41090,"date":"2020-09-29T12:21:48","date_gmt":"2020-09-29T11:21:48","guid":{"rendered":"https:\/\/www.intelligentcio.com\/eu\/?p=41090"},"modified":"2020-10-01T08:51:48","modified_gmt":"2020-10-01T07:51:48","slug":"managing-competing-demands-of-development-velocity-and-application-security","status":"publish","type":"post","link":"https:\/\/www.intelligentcio.com\/eu\/2020\/09\/29\/managing-competing-demands-of-development-velocity-and-application-security\/","title":{"rendered":"Managing competing demands of development velocity and application security"},"content":{"rendered":"\n

Software tools are constantly offering new ways of working which enable organisations to compete. Patrick Carey, Director of Product Marketing at Synopsys<\/em>, says that as the shape of software development continues to evolve, so too must the mechanisms to secure it<\/em>. <\/p>\n\n\n\n

The first software development team I worked on operated on the follow mantra:<\/p>\n\n\n\n

  1. Make it work.<\/li>
  2. Make it fast.<\/li>
  3. Make it elegant (maybe).<\/li><\/ol>\n\n\n\n

    Meaning, don\u2019t worry about performance optimisations until your code actually does what it\u2019s supposed to do, and don\u2019t worry about code maintainability until after you know it both works and performs well. Users generally have no idea how maintainable the code is, but they do<\/em> know if the application is broken or slow. So more often than not, we\u2019d never get around to refactoring the code \u2014 at least not until the code debt started to impact application reliability and performance.<\/p>\n\n\n\n

    Today, that developer mantra has two additional lines:<\/p>\n\n\n\n

    • Ship it sooner<\/li>
    • And while you\u2019re at it, make it secure<\/li><\/ul>\n\n\n\n

      As with application performance and reliability, delivering an application on time is easily quantified and observed. Everybody knows when you miss a deadline \u2014 something that\u2019s easy to do when your release cycles are measured in weeks, days, or even hours \u2014 the security of an application isn\u2019t so easily observed or quantified, at least not until there\u2019s a security breach.<\/p>\n\n\n\n

      It should come as no surprise, then, that nearly half of the respondents to the modern application development security survey, conducted by Enterprise Strategy Group (ESG), state that their organisations regularly push vulnerable code to production. It\u2019s also not surprising that for over half of those teams, tight delivery schedules and critical deadlines are the main contributing factor. In the presence of a deadline, what can be measured is what\u2019s going to get done, and what can\u2019t be (or at least isn\u2019t) measured often doesn\u2019t get done. <\/p>\n\n\n\n

      However, ‘we don\u2019t have time to do it’ doesn\u2019t really cut it when it comes to application security. This is demonstrated by the 60% of respondents who reported that their applications have suffered OWASP Top 10 exploits during the past 12 months. The competing demands of short release cycles and improved application security are a real challenge for development and security teams.<\/p>\n\n\n\n

      It doesn\u2019t have to be this way, and other findings in the survey point to opportunities that teams have to both maintain development velocity and<\/em> improve application security. Here are just a few:<\/p>\n\n\n\n

      Reject silver bullets<\/strong><\/p>\n\n\n\n

      Gone are the days of security teams simply running DAST and penetration tests at the end of development. A consistent trend shown in the report is that teams are leveraging multiple types of security testing tools across the SDLC to address different forms of risk in both proprietary and open source code.<\/p>\n\n\n\n

      Integrate and automate<\/strong><\/p>\n\n\n\n

      Software development is increasingly automated and application security testing needs to be too. Over half the respondents indicated that their security controls are highly integrated into their DevOps processes, with another 38% saying they are heading down that same path.<\/p>\n\n\n\n

      Train the team<\/strong><\/p>\n\n\n\n

      Most developers lack sufficient application security knowledge to ensure their code isn\u2019t vulnerable. Survey respondents indicated that developer knowledge is a challenge, as is consistent training. Without sufficient software security training, developers struggle to address the findings of application security tests. An effective way to remedy this is to provide ‘just-in-time’ security training delivered through the integrated development environment (IDE).<\/p>\n\n\n\n

      Keep score<\/strong><\/p>\n\n\n\n

      If what gets measured gets done, then it\u2019s important to measure the progress of both your AppSec testing and security training programmes. This includes tracking the introduction and mitigation of security bugs as well as improvements to both of these metrics over time, i.e. who is writing secure code and who isn\u2019t and are they improving?<\/p>\n\n\n\n

      We must also recognise that there can be too much of a good thing in terms of security tooling. ESG reported over a year ago that organisations, on average run 25 to 49 security tools from up to 10 different vendors. Some of these are monitoring tools for IT infrastructure, such as network, endpoint, wireless, identities and so on. But it applies to software development as well.<\/p>\n\n\n\n

      Analysts like Forrester and 451 Research have reported on security tool sprawl in the past year, noting that as many as 40% of organisations admit that their development teams are so overwhelmed by security alerts that they can\u2019t respond to at least 25% of them. Indeed, when security alerts are so constant, they become background noise and are ignored \u2014 the exact opposite of the intent.

      It shouldn\u2019t be this way. The right combination of tools that run the right tests at the right time can help security keep pace with development, which has moved into hyperdrive over the past few years. And still, there is a persistent perception that if some tools improve your security, more will improve it even more. Unfortunately, it could be just the opposite. If you pile too many tools on your development team, especially if you can\u2019t coordinate them on a single platform, your developers are more likely to ignore critical alerts.

      Too many tools can even expand your attack surface if they don\u2019t communicate securely or aren\u2019t updated regularly. So what can you do?

      Take an inventory of your security tools<\/strong><\/p>\n\n\n\n

      Eliminate tool sprawl by taking a rigorous inventory and evaluating it. Know what you have and what it\u2019s intended to do. It\u2019s of great importance also to make sure your tools are properly configured, deployed and are up to date. And then evaluate: are they doing what they’re supposed to? Is any tool doing the same thing that another tool might be doing better? If a security tool is inferior or redundant, get rid of it. Security clutter is the last thing you want.

      Make sure tools complement one another<\/strong><\/p>\n\n\n\n

      Be sure your tools can work together. It doesn\u2019t matter that a single tool is considered best in class if it can\u2019t play nice with all the others. Your tools need to integrate with one other and into your workflow, which makes it easier to embed security into the SDLC from start to finish. As the experts say, the best way to encourage developers to add ‘Sec’ to DevOps is to make the secure way the easier way.

      Integrate tools into your workflow<\/strong><\/p>\n\n\n\n

      The way to make security easier, and combat security tool overload in the process, is to integrate your security tools into a single platform with a dashboard that flags bugs and other potential defects as you go. It\u2019s far better than forcing developers to return to code they wrote weeks ago to deal with problems you discovered today.

      High velocity development is the future, there\u2019s no denying it. And while security must keep up with methodologies such as DevOps, it must be carried out in a way that enables development teams to build security into their existing processes. As the shape of software development continues to evolve, so too must the mechanisms to secure it \u2014 and that doesn\u2019t simply mean an overabundance of security tooling.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Software tools are constantly offering new ways of working which enable organisations to compete. Patrick Carey, Director of Product Marketing at Synopsys, says that as the shape of software development continues to evolve, so too must the mechanisms to secure it. The first software development team I worked on operated on the follow mantra: Make […]<\/p>\n","protected":false},"author":21,"featured_media":41091,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[57,1489,13,93,24],"tags":[],"class_list":["post-41090","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-security","category-insights","category-main-story-newsletter","category-top-stories","category-used"],"acf":[],"publishpress_future_workflow_manual_trigger":{"enabledWorkflows":[]},"_links":{"self":[{"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/posts\/41090","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/comments?post=41090"}],"version-history":[{"count":4,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/posts\/41090\/revisions"}],"predecessor-version":[{"id":41138,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/posts\/41090\/revisions\/41138"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/media\/41091"}],"wp:attachment":[{"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/media?parent=41090"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/categories?post=41090"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.intelligentcio.com\/eu\/wp-json\/wp\/v2\/tags?post=41090"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}