- Development
- Security
Putting security & compliance at the heart of software development
December 8 - 23
For many years, the barrier to entry to build digital products has been getting lower and lower. Anyone can whip up a few lines of code on a server spun out by a cloud provider and call themselves an app builder regardless of their level of expertise and the quality of their processes (or lack thereof).
But things have been changing since then. And they have changed quickly in these last few years, especially in terms of security and data compliance (GDPR, bill 25 in Quebec, ISO 27001, SOC 2).
Software is now expected to be 1) free of security vulnerabilities and 2) compliant with various regulations governments and institutions have been putting in place. The push for security is not just a trend, but a fundamental shift in how we approach software engineering.
With so much of our daily lives dependent on digital platforms, the stakes are higher than ever — user trust can be quickly lost following a security breach or a data compliance violation while companies can be fined for non-compliance.
Today, developers are building software using higher-level languages, low-code, no-code or AI-generated code. This can lead to a shallower depth of knowledge among development teams to prevent these issues, thus increasing the risk of inserting vulnerabilities or non-compliant patterns into codebases. And while modern technology paradigms like decentralization and immutability bring new ways to store and distribute data, they also bring a different set of concerns in terms of security, privacy, and long-term data compliance.
In an ever-growing interconnected world, the number of endpoints vulnerable to attacks has grown exponentially. And as technology becomes more embedded in daily life, from smart homes to connected vehicles, the potential consequences of security failures extend far beyond data breaches to tangible, real-world implications like safety and well-being. What’s more, as the user base of digital products becomes more diverse, there’s a growing need to ensure that software is not only secure and compliant, but also equitable and inclusive, protecting all users irrespective of their technological proficiency or demographic background.
What does this new reality mean for engineering teams?
The engineering teams that will thrive in the future will be the ones that have cultivated a “build things right” mindset. They will build digital products with security, data, and privacy in mind because it’s the right thing to do, not just because it’s required.
This doesn’t mean they won’t use bleeding-edge technologies (eg., AI, immutability, decentralization, etc.) to gain competitive advantage in terms of efficiency — they will carefully strike the right balance between rapid adoption of new technologies and adapting their use to the right mindset.
But having the right mindset isn’t enough. They will need to make sure they have the necessary processes and tooling in place. Spoiler alert: it’s going to be a wake up call for organizations that were treating security and data concerns on a “nice to have” basis.
It’s also not a one-time deal — new security vulnerabilities are discovered each week, new compliance specifications come into effect. They are going to have to make sure the code they write and ship remains secure and compliant.
As consumers become more educated about their digital rights and the intricacies of data privacy, their expectations of software providers have increased. An organization’s reputation, once marred by security or compliance lapses, can take years to rebuild, if ever. Additionally, the global nature of many digital products means that breaches or non-compliance can have ripple effects, impacting international relations, trade agreements, and even geopolitical stability. Furthermore, in an era when ethical considerations in tech are under the spotlight, engineering teams are grappling not only with technical challenges but also with the moral implications of their coding decisions.
“An organization’s reputation, once marred by security or compliance lapses, can take years to rebuild, if ever.”
What can engineering teams do to address these concerns?
Automation
Automation is the cornerstone of an efficient and effective engineering team. By using automated workflows to address these new concerns as part of their SDLC (software development lifecycle), teams can leverage tooling in a way that doesn’t add friction to existing processes.
Security analysis (both static and dynamic) tools are used to quickly identify potential vulnerabilities. Policy agents will be deployed in high- risk environments to ensure codebases and infrastructure are tested against hardened policies. Infrastructure-as-code tools will be used to make explicit and reviewable changes to an ever-increasing number of components.
Engineering teams that embrace automation as a first-class citizen will be able to rapidly adapt to changes without sacrificing velocity.
Beyond the immediate development environment, automated monitoring and alerting systems are becoming indispensable to ensure real-time detection and response to any unusual or malicious activity. Additionally, the use of machine learning in automation can further predict and preemptively address potential vulnerabilities, transforming reactive measures into proactive solutions. By incorporating AI-driven DevSecOps, software engineering can move towards a future where security measures evolve in tandem with emerging threats, making the protection layer smarter with each iteration.
Engineering involvement during product definition phases
But not everything can be solved by machines, algorithms, and automated processes. As more and more security and data concerns need to be addressed in digital products, the need for engineering involvement in discovery and definition phases is greatly increased.
Because these concerns should be viewed as core requirements (and not simple features), they often lead to major architectural decisions, which should be taken as early as possible in the process. These decisions will impact how and where data will be fetched, processed, and persisted. Engineering concerns can also affect the product itself as implementation complexity is a major factor involved in these decisions.
Operation and maintenance
Even if engineering teams do their best in the product development phase, it can fall apart in the operation phase. Security and data concerns are not one-time things. Teams need to be proactive to stay on top of things because new security vulnerabilities are discovered every day.
By conducting regular (hopefully as automated as possible) audits, they can identify and address issues as soon as they arise. By keeping their dependencies and runtimes up-to-date, they avoid playing catch up when security issues occur.
However, the level of impact on operations can be mitigated during the development phase. By starting projects with reusable foundations and using consistent sets of dependencies, teams can reduce maintenance time and costs as changes can be propagated across projects.
How to implement this mindset
Taking care of your SDLC and always trying to improve it will make it do more for your team without impacting speed and deployment. Leveraging automated security scanning tools (both static and dynamic) in your manual security analysis and auditing services can also be beneficial. For example, through our boilerplate projects at Mirego, we maintain secure-by-default templates we use to spawn off new projects, making sure that every new project has healthy and secure defaults, hardened settings, and pre-configured automated tooling.
Doubling down on security can also mean having a dedicated team for maintenance and support to ensure that necessary changes are proactively pushed back into the various codebases as soon as new best practices are being integrated into boilerplate projects. The same mindset should be applied when exploring new technologies or working with existing ones: never compromise on security for the sake of innovation.
The bare minimum is no longer enough
Not only do users expect more from digital products in terms of security and privacy, but governments will make sure that they do. The consequences of ignoring these concerns are very real.
Being proactive rather than reactive to security threats can make all the difference.
Engineering teams that are already in the right mindset will benefit greatly. They already see security as a top-level priority and use automation to make it part of their SDLC. They already treat user information as sensitive data and design strict but flexible architectures according to privacy requirements. They treat digital products as ever-evolving pieces of software that will live for a long time. They have rigorous processes to keep codebases and infrastructure up-to-date.
As new technologies emerge, they strike the perfect balance between them, the possibilities they bring, and the external context around them. They treat this context not as a set of limitations but as a framework within which the products they build must fit.
We can’t predict the future — it’s impossible to predict what vulnerabilities will be discovered. It’s hard to predict what new regulations will be enforced in the next decade.
What we can do is make sure that our mindset, processes, and tooling are aligned with the idea that security and privacy concerns will only become more important in the next few years. In the words of Bruce Schneier, “Security is a process, not a product.” The future of software engineering from a security and compliance standpoint will be defined by the processes we adopt, the mindset we cultivate, and the value we place on user trust and data integrity. It’s an ongoing journey, but wone that can be successfully navigated with the right approach.