We just finished a webinar with SANS that was presented by our CSO, Ryan Berg, focused on the hidden risk of components. Ryan engaged us with practical advice based on his years in the security business. Here are the key points that I gathered from his discussion.
- Components are pervasive – organizations have moved from manual coding to assembling applications with components. Components make up 80-90% of most applications. 8 billion components were downloaded from Central last year.
- Components introduce risk – although components can provide a huge productivity increase, if you fail to manage them they will introduce security risk (not to mention licensing and quality risk). Attackers are focused on components since they have become pervasive.
- Most organizations aren’t aware of component usage, let alone risk – many organizations have trouble tracking all of their applications, let alone the components used to build those applications. Since they don’t know what they have, they have limited visibility into their risk profile.
- You can’t NOT use open source – some organizations naively overreact by attempting to eliminate the use of open source. That is simply not possible given how applications are built today.
- Security must be designed for agile development – cumbersome security policies that were challenged in a waterfall development process will simply fail in an agile environment. Developers will simply work around the policy if it hinders their progress.
- Security must be woven into the development process – security must be built into the entire development process – including smart policies that drive appropriate action at different development stages. Integration directly in the development tools is key – including Repository Managers, IDEs, Build and CI environments.
- The security team must speak the language of the developer – the security team should approach the development team as an equal partner – they can’t mandate behavior or simply provide a list of potential vulnerabilities that need to be fixed.
Ryan concluded the presentation by talking about placing a hungry and thirsty donkey equidistant from a source of water and food – the donkey, not being able to make a decision, both starves and dies of thirst. Ryan used it to illustrate the dilemma between patching and replacing flawed software components. I think it also illustrates the fact that you don’t have to pick between secure applications & developer productivity. It doesn’t have to either or – if you take a best practices approach that aligns all of the constituents you can manage components and application security effectively.
Join the conversation on Twitter using the #CSORisk.
View the webcast recording here.
