Compliance and competitiveness – the role of software development in balancing the two

Konrad Litwin, Managing Director – International,Perforce Software

The perennial dilemma for financial institutions is to balance the need to be compliant with industry regulation, versus the need for competitive innovation and responding to customers’ desires.

Compliance demands impact every part of the financial market and with the growing reliance on digital technology, the compliance culture must extend to the development of the software that drives modern financial services, in order to strengthen security and reduce risk.

The challenge is that traditionally compliance and security requirements have not been a top priority for software developers, who have typically tended to work in siloes, separate from IT operations and the rest of the business.  Many risk and security checks-and-balances inevitably create hurdles or halts, and software developers do not like anything that might slow them down or limit creativity.

However, since the creation of software is where bugs and other vulnerabilities can creep in, it must be a vital part of the compliance strategy.Otherwise, problems may only be discovered later, such as during an audit process or when they create an issue for customers. Having a separate security team review code prior to ship isn’t a great option, because it won’t scale: an organization with 1,000 developers can’t afford a 100-person security team.

Fortunately, modern software development tools and techniques can help financial firms balance compliance, security and risk management, without sacrificing competitive and commercial values.  For instance,development methodologies,such as Agile and DevOps, together with the right supporting tools,assist software delivery that is fast and efficient, while also being compliant and reliable.Security and compliance teams can join with development teams to implement policy automation,by becoming involved in technology design and deployment up front.

Importantly, today’s modern development toolchain can provide many processes and capabilities that address the fact that financial products and services are often updated and even legacy applications must remain compliant and available for transparent auditing.  Compliance relates to every stage of each digital asset’s life, from ideation through to delivery, maintenance and archiving.Therefore, having visibility and transparency throughout the creation and maintenance of digital assets is fundamental to achieving a more compliant and secure environment.

Visibility and traceability

One approach many financial firms are taking is the creation of what are increasingly labelled as ‘single-sources-of-truth’, providing a centralised view that tracks each digital asset, the actions of each contributor, plus how all these inter-relate.  A version control system is typically the engine behind a single-source-of-truth, not least because they enable a unified view of disparate systems and platforms plus a full history of all application changes.

In other words, in theory they allow contributors to carry on working the way they are used to, but still provide that shared picture of who is doing what, when and how.  This all contributes towards ensuring that safe, quality-controlled digital assets are being created, but without creating hurdles that get in the way of time-to-market.

However, it is important to choose a version control system that really can support different file types, tools and processes.  This should also include the ability to provide a view into other version control systems, especially Git, which is popular with individual software developers but does not provide the enterprise-level visibility that IT management requires.

One of the tenets of the increasingly popular “shift-left”concept – which focuses on getting developers involved in testing early in the development process – is to bring compliance security as close to the left (or beginning) of the software development lifecycle (SDLC)as possible. Ensuring clean, quality code before a developer submits their project to the version control system can help to minimize error or the introduction of vulnerabilities into an application.  One way to accomplish this, without adding an undue burden on developer productivity, is through the use of automated static code analysis, which in background mode runs checks on code being created to ensure it is compliant, as well as detecting security flaws, design defects, and code weaknesses. Identifying and recommending fixes earlier in delivery process, long before they are exposed to the public.

 This is a good example of how automation around software development can contribute to quality control and provide ‘safer’ software creation, without manual intervention or slowing down a project.   Also, where Agile and DevOps methodologies are being used in the development process, including compliance and security personnel and practices at the beginning of a project or product’s creation also helps to ensure that these critical risk-management needs are met.  Both the culture and toolchain must evolve to facilitate collaborative change, removing silos and barriers of departmental fiefdoms in the interest of releasing compliant and secure products.

Granular access

Keeping the code itself secure is also of paramount importance. In the software development environment, locking down who has access to digital intellectual property (IP) can help reduce the risk of vulnerabilities.  These can range from inadvertent introduction of risk through to malicious misuse or theft of software assets.

Traditionally, developers have had carte blanche access to content, whether they require it or not and this is not fair on them nor the organisation.  Instead, it is better to implement ‘fine grained’ access control, applying the principal of least privilege (PoLP) whereby users are given access to only what they need, but no more.  Digital intellectual property (IP) can have access levels imposed in multiple ways, for instance via IP address, user and group, with enforceability at code repository, branch, directory or individual file level, locally or across authorised locations.

One major financial institution not only implements a ‘need to know’ only basis within its software development environment, it also tracks and audits every interaction with its version control (or software configuration) management system.  This addresses security and compliance, together with visibility and control, but with the benefit of flexible access permissions, allocated as appropriate, to let the development team be innovative.  create a very security-heavy ‘locked-down’ development environment.

This is just one example of how modern software development tools and processes are enabling financial institutions to be competitive, but without sacrificing security and risk management.  In fact, rather than getting in the way of these requirements, software can proactively contribute towards a bank’s business.