Tune In: Banking on built-in security checks

You’ve seen the headlines: Financial services are a top target for hackers. From breaches at Anthem to cyberattacks at JPMorgan Chase, cybercrime has repeatedly been bad news for financial services companies, affecting not just customer accounts but share prices as well. The good news is financial services companies are beginning to shield themselves from breaches by activating automatic security checks in their applications as they build them.

Applications are one of the largest attack surface areas for hackers. By building in security checks early in the development cycle, risks can be reduced dramatically, and everyone can benefit: developers, the application security team, and even a company’s shareholders.

An illustration comes from a recent collaboration between Red Hat, Sonatype and one of the world’s largest global financial services firm on creating a more secure software development lifecycle (SDLC). Red Hat and Sonatype are hosting today a webinar to explore how the firm is establishing a clean open source supply chain, addressing both software development and application security goals. Modern development practices are augmented by built-in software supply chain visibility and management. Software builds are analyzed to identify any components with known vulnerabilities while in the continuous integration pipeline—a habit Forrester Research recommends for Rugged DevOps to accelerate releases while maintaining stronger security.  The firm can track and trace what components are used and where. That’s critical considering 80% of the average application is made of third-party and open-source components.

The security (and quality) checks can actually start even earlier in the SDLC than that. Direct integration into the integrated development environment (IDE) and Repository Manager can give developers immediate feedback on whether a component is suitable based on known security vulnerabilities, component age, version, and license obligations. If a component doesn’t meet a security or compliance requirement, the developer can get actionable intelligence on alternative components to use.

Developers can choose better and more secure components upfront, which may mean less re-work and less risk later. And when vulnerabilities are published, the application security team has information it can act on to more quickly understand which applications are affected and immediately begin planning and prioritizing remediation.

Early risk detection in the SDLC is consistent with the trend in Agile, continuous integration/continuous deployment (CI/CD) and now DevOps to “shift left” by moving testing from post-release to pre-release. It’s a win-win situation: Security policies are incorporated into the pre-release processes with automation, insight and integration. This can create a culture of quality able to scale with the pace and volume of modern software development. This in turn can build trust between development and application security.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.