In its latest State of Software Supply Chain survey, Maryland-based software company Sonatype asserted that development teams should aim for a minimum of four releases every year – but the optimum number of releases ultimately depends on what product owners want to achieve, says QA VectorⓇ Research.
However, based on our original insights, QA VectorⓇ Research suggests that there is no one-size-fits all strategy for financial firms. We believe that financial infrastructure firms need to apply a spectrum-based approach. Whilst an ideal strategy tends towards monthly, for classes of heavily legacy applications, quarterly releases carry the least risk.
Updates to systems of engagement lend themselves to more frequent releases than changes to the mainframe or middleware. Maintenance updates should be released fortnightly and new features monthly.
To be able to support such regular releases, institutions must continuously modernise their CI/CD pipeline, to become more agile. This means creating the right environment, equipped with effective release machinery and management. The recent partnership between software services provider CloudBees and Google Cloud, for example, aims to deliver a DevOps cloud platform which will enable organisations to modernise their applications in a hybrid environment.
From its research, Sonatype concluded that a higher frequency of dependency updates statistically results in more secure code, empowering components against attacks to the supply chain. This is especially important, according to Sonatype, because adversaries are now taking advantage of an attack vector whereby vulnerabilities can be injected directly into open source project releases.
These attacks are particularly high-risk for financial services; when malicious code infiltrated the build chain of cryptocurrency wallet Agama in June 2019, it endangered over $13m in cryptocurrency assets.
Based on the feedback of quality leaders across the financial services sector, on which our insight is based, more frequent releases do enable firms to improve their software risk management. But effectively defining the right release frequency relies on a sober assessment of the current mix of legacy applications, maturity of release management infrastructure, skills and processes.
