Turkish Banking Agency Mandates Better Software Supply Chain Hygiene

November 03, 2020
By Alejandro Gamboa

Today, application attacks and breaches often result from easily exploited – and easily rectified – open source vulnerabilities. While we hope companies would self-regulate their cybersecurity hygiene in our software-driven world, daily breach headlines indicate that government, associations and third-party regulations might be a necessary motivator for action.

One such entity that has recently decided to take action, through new standards to protect the Turkish citizenry, is the Banking Regulation and Supervision Agency (BRSA). The agency introduced Regulations requiring banks to more aggressively protect customer data, payment information and create safer transactions.

As stated by Mondaq "the Regulation will have a significant impact on business operations carried out by (i) banks, (ii) auditing firms, (iii) technology firms offering outsource services to banks, (iv) firms offering open banking products." And, they aren't to be taken lightly. Unlike other organizations who may just have "guidelines" in place, BRSA puts your money where their mouth is. Recently, it distributed $48m worth of fines for institutions who didn't follow their orders during the coronavirus pandemic. We expect similar fines for organizations who don't follow these new hygiene rules. Banks cannot afford to be noncompliant on any Regulations, and need a solution.

So, If You're a Financial Institution Operating in Turkey, What Do You need to Know?

Among other things, there are two overarching secure development measures that companies need to adhere to. The must:

• " ensure that related software or mobile applications do not contain any code that could compromise customer security"
• And, "provide necessary patches and updates to the customer usage to address security flaws."

The Regulations go into great detail on exactly how they expect companies to reach these broader goals. Specifically:

• Most notably, Article 22, which details system development migration and installation, requires security policies in writing that govern how software is developed. Furthermore, section 4 of the Article demands that security be built in throughout the software development life cycle (SDLC) in order to improve software quality and minimize risk from the start. This means applications are regularly scanned for security gaps. In a groundbreaking move, Article 22 also lays out requirements for secure coding training for all personnel.

• Article 15 discusses security configuration management and details how the bank must implement a whitelist for applications and libraries to ensure that only approved components and systems are in place. You must also scan regularly to ensure they haven't been modified. Companies must also keep detailed software inventory, to know exactly what's in use.

• Article 16 outlines vulnerability and patch management processes, and notes that you MUST have a process in place that takes into account where a security patch is coming from, whether applying the patch might have issues itself, and how to identify where gaps may be. You must also identify whether software in your system is out of date and can no longer be updated appropriately. There must also be continuous, automatic vulnerability scanning that provides information to the right people at the right time, to ensure the most critical vulnerability can be addressed immediately.

• Article 24, covering change management, mandates that any changes, components, code, and documentation about change processes to the software systems be recorded.

All of this can seem daunting. But, it doesn't have to be. Fortunately, many of the mandates presented in the BRSA Regulation are easily solved by better understanding your use of known vulnerable open source components. Large and small enterprises already put DevSecOps principles and practices to work, and use the Sonatype Platform to mitigate their software vulnerability risk.

The Sonatype Platform automatically enforces open source governance and controls risk across every phase of the SDLC. Fueled by Sonatype Intelligence, which includes in-depth security, license, and quality information on more than 100M open source components across dozens of ecosystems, the platform:

• Precisely identifies risk and provides expert remediation guidance.
• Generates a software bill of materials (SBOM) so you can easily track and trace the location of every component embedded within their production software applications.
• Allows you to set policies to govern the use of components, as well as access to those approved components.

Only Sonatype secures your perimeter and every phase of your SDLC, including production, by continuously monitoring for new risk based on your open source policies.

With 90% of most modern applications comprised of open source components, organizations must start by understanding their open source use. We had the opportunity to explore this topic in depth at Innovera's VShield cybersecurity conference over the summer. It was great to talk to financial institutions of all sizes about how they can proactively make changes to get in front of these new rules.

Don't know where to start? We've got you covered. Try our free Sonatype Vulnerability Scanner to see how easy it is to comply with BRSA's new Regulations.

Written by Alejandro Gamboa
Alejandro is a Director at Sonatype, helping enterprises in Iberia, Italy and North Africa, develop secure apps faster, using open source components.