Over the past decade, application security has changed dramatically. Yet the biggest shift is not that software has suddenly become less secure . The real change is that discovering vulnerabilities has become much easier , while fixing and distributing those fixes has become significantly harder . For software vendors, the bottleneck is no longer finding security issues. It is maintaining secure software throughout the entire lifecycle of a product. Not that long ago, finding vulnerabilities was largely a manual exercise. Internal penetration tests, customer security assessments and occasional code reviews uncovered issues that developers would then address before the next release. Today, vulnerability discovery is continuous and increasingly automated . Static Application Security Testing (SAST) tools such as SonarQube analyze every build for insecure coding patterns. Dynamic Application Security Testing (DAST) has become a standard part of many security programs, both int...
Open Banking has been around for several years. With PSD2 in the European Union and Open Banking in the UK, banks were forced to open access to payment accounts and payment services to regulated third parties. Since then, we have seen a growing number of use cases emerge: account aggregation in personal financial management applications, transaction data used for credit scoring and risk decisioning, account verification during onboarding, cashback and loyalty services, and account-to-account payments. Yet despite all the attention Open Banking has received, its impact remains relatively limited compared with its original promise. Part of the explanation is technical. API quality and availability still vary significantly between banks. Implementations differ, making connectivity complex and costly for third-party providers. Authentication and consent processes can introduce additional friction, while seemingly basic challenges around historical information, joint accounts, transac...