In my recent blog, 'Financial Services Organizations have Open Eyes on Open Source', I shared how Sonatype's company mission aligns with the recent FS-ISAC guidelines put out by the third party software security working group. In short, open source security can't be an after thought. Security isn't only the responsibility of 'security professionals' but instead a shared responsibility for all parties involved in developing or managing an organization's software supply chain. Better put in the FS-ISAC guidelines, "the most appropriate type of control for addressing the security vulnerabilities in open source, including older versions of the open source, is one that addresses vulnerabilities before the code is deployed—i.e. by applying policy controls in the acquisition and use of open source libraries by developers."
The Drive to Secure Applications
Which brought us to the question, do developers consider themselves an application security driver or consumer? Preliminary results on 275 responses to a new survey by the Trusted Software Alliance (TSWA) showed that 67% of developers consider themselves a primary driver for application security (positive news for sure). While the developers considered themselves a primary driver for security, we have also seen survey results revealing 55% of participants “do not have clear policies” or “have policies that are not effectively enforced”. Being a primary driver of application security does not always mean that you have the policies in place to support that drive or responsibility.
Advice from the Front Lines
While developing policies could help developers and others driving application security efforts, another approach would be to ensure these policies are built into the tools developers and others use today. This is an approach echoed in a recent interview with Jim Routh, Chief Information Security Officer and lead for the Global Information Security function at Aetna (he is also Chairman of the FS-ISAC Products & Services Committee and a former board member).
Listen to Jim Routh's 2 part interview on the Trusted Software Alliance.
Routh shared, “We have to apply techniques that address both the quality and security attributes of open source components as they are acquired. By doing so, we can improve confidence in the LEGO-like assembly process [of downloading and assembling components] used by developers.”
“The developers can then use those components with some level of confidence and certainly understand the tradeoffs between quality and security”, Routh continued. “That technology is just emerging today and is likely to mature over the next several years.”
In addition to defining policies and making them more accessible to employees companies should start looking to where their investments in application security are focused. It's not far to say, financial services firms aren't properly investing in application security. Billions are being spent everyday searching and testing for vulnerabilities of applications that are already in production.
The change we're hoping to see is for companies to look deeper into their application development supply chain for potential vulnerabilities that might be introduced when 3rd party components are consumed allowing developers to make better decisions about the components they integrate into their software projects and ensure those projects remain secure overtime.
Want a simple place to start?
Sit down with your developers and ask them how they are taking advantage of open source components in the software development lifecycle. You’ll likely find the approach varies and data shows it’s because of the lack of standardized policies and tools that ensure security is built into the development process from the start.
To learn more about the FS-ISAC guidelines and the need for 'Policy Management and Enforcement for Consumption of Open Source Libraries and Components', read the full FS-ISAC whitepaper.
To learn why Sonatype is a preferred application security vendor for financial organizations visit http://www.sonatype.com/spotlight/fs-isac
