We’ve talked before about platform engineering — building a platform on which developers can innovate more easily, quickly, and cheaply. At BRYXX, we go one step further by making sure that every application you build is automatically secure, right out of the box.
This is the ideal scenario: an internal developer platform with security so deeply embedded that every application you build is protected by default, with no extra steps or manual input. To achieve this, you need what’s known as a security plane: a security layer woven throughout the development platform.
How do you embed security in the platform?
You solve this puzzle using a combination of solutions, such as a secrets manager. If applications on the same platform work together via APIs, this interaction must of course be completely secure. You could hardcode the associated passwords in an application, store them in a script or — even worse — in a hidden file within a container. But this merely results in “security through obscurity”.
At BRYXX, we do it differently. For example, in a recent rollout for a major client, developers received ready-made templates as a starting point. The basic application was already prepared, with a variable that automatically contains the correct password, supplied by the secrets manager and integrated into the platform. The developers didn’t even have to think about it — because platform had taken care of it.
In another case, a client felt SSH wasn’t safe enough to use with Ansible, where you open SSH from a single central point to all servers. To address this, you can choose to eliminate manual log-ins to the servers via SSH altogether. Puppet then sets up the servers automatically, and tools such as Splunk, Elastic, and Dynatrace can collect and monitor all log data. You can then even protect the Puppet configuration itself from manual access.
The safest way is also the easiest
By removing the need for manual security configuration, you create a situation in which you as a developer no longer have to think about security. You no longer need to set up key management or user management if you choose SSH, for example. There isn’t even an access point that needs to be secured .
Of course, you might encounter early resistance from developers when you introduce a development platform with built-in security. The reason? The least secure methods (such as manually logging in to servers) often feel faster and more familiar. However, once they begin working on the platform, they’ll quickly realize that the most secure way is also the easiest for them. They can develop faster, and everything they build is automatically secure. In this way, security is no longer a burden; it becomes an enabler that actually contributes to smoother workflows.
What about the price?
Yes, implementing a secure by default platform requires an upfront investment. But consider the return you’ll benefit from by working more securely. Because in truth the question isn’t whether you’ll be hacked, but when, how badly, and at what price? By investing wisely in security, you can prevent disaster — and its many associated costs — from knocking at your door. And if disaster does strike, you can be confident that you’ll keep your losses to a minimum, precisely because every development is secure by default. In this way, you’ll quickly realize your ROI, not just through faster, safer development but also though real peace of mind.