How Implementing an Internal Developer Portal will Optimize Your Business

In a highly regulated environment such as financial services, how can we fully realize the promise of cloud to increase developer productivity, secure the software supply chain whilst also ensuring all security and compliance requirements are met?

Financial services firms have been adopting public cloud and DevSecOps over the last few years believing that they would see, among other things, an increase in agility and reduced time to market. But, firms are not consistently seeing the results they want. So, can the industry address these challenges?

The challenge

Application teams within financial services can find it difficult to get their solutions into production. This is primarily due to governance, approval processes and a reliance on other teams, like infrastructure and security.
Public cloud and DevSecOps adoption has meant that application teams have had to become cloud engineers. And learning a cloud platform isn’t easy, especially for software engineers. Yes, you can create a separate ‘platform’ team, but this results in increased costs and introduces a potential new bottleneck . In addition, InfraSec teams must ensure that only approved cloud services are used and that they’re configured correctly. Passing the responsibility on to application teams means that they’ve lost an element of control that they had in the on-premises world.

Applying the on-premises operating model to the public cloud

In some cases, the on-premises operating model has been applied to the public cloud. This means that – because a core infrastructure team still have some responsibility for provisioning services – application teams lose autonomy and can then incur lead times resembling those of the old world.

“You build it, you run it”

Application teams have been told to adopt DevSecOps. This means they’re then responsible for provisioning and maintaining their own infrastructure and ensuring that security is embedded at every stage of the Software Development Life Cycle (SDLC).
This then results in several issues:
 

• Skills – Application teams must think like infrastructure and security engineers. However, in most cases, they don’t have the necessary skills to do this.
• Adoption – Application teams are finding it challenging to adopt new tools, such as those for secrets management and monitoring. This is usually down to a lack of best practice patterns on adoption, and also application teams lacking the knowledge of the service or tool and being told that they must adopt it.
• Supply Chain Security – Application teams need to embed security at every stage of the SDLC. However, adopting new tools can prove to be a challenge due to a lack of skills and knowledge. Practices like ‘consolidated package management’ are the exception rather than the rule. This makes it difficult to for organizations to have visibility of what exists and whether it has security gaps.
• Open Source Policy – Financial services firms tend to only let users install approved and licensed software on their computers and have polices in place to ensure unapproved software can’t be installed. With modern application teams relying more and more on open source and low-code solutions, organizations must ensure these are scrutinized in a similar way.
• Increased Cost – Application teams are having to retrain or hire additional platform engineers to help with maintaining and provisioning cloud services.
• Governance – With application teams provisioning and maintaining their own cloud services, the question is now how security teams can verify and prove that service usage meets security and compliance requirements.

So, going back to our original question…

“In a highly regulated environment such as financial services, how can we fully realise the promise of cloud to increase developer productivity, secure the software supply chain whilst also ensuring all security and compliance requirements are met?”

Enter the Internal  Developer Portal…

“An ecosystem for the Software Development Life Cycle”

Software development is complicated at the best of times. Developers must contend with multiple tools, such as Visual Studio, JIRA, SQL Developer, CI/CD tools, and ServiceNow, to name but a few.

In highly regulated environments like financial services, this is further complicated by more stringent governance and compliance requirements.

A developer portal can be considered as a single view of a unified ecosystem; a one-stop-shop for delivering a high-quality and secure SLDC experience, without application teams having to worry about how to integrate with new services – from secrets management to cloud infrastructure – and reducing their reliance on multiple tools and portals.
 

There are four core parts to the portal…

1) The Software Catalogue

The software catalogue is the foundation of any developer portal. It represents all the software, services, APIs, templates and resources that form a company’s software ecosystem – with clear ownership, inter-relationships and other accompanying metadata.
With a central catalogue, it becomes much easier to promote reuse and inner-source models – including federated operating models, such as the data mesh.

The software catalogue becomes the ‘hub’ upon which other features of the portal rely. It allows the exposition of documentation; architectural decision records; security; quality; cost and tech debt scorecards; windows into CI/CD; pull request and repo health; and any number of other features. This gives development teams a ‘single pane of glass’ that covers all the individual systems with which they work. The idea here is to have a component or service that is not just easily consumable, but which also satisfies any security and compliance requirements.

2) The Scaffolding Tool

The scaffolding tool is built on top of the catalogue. Its primary goal is to increase developer productivity by removing friction and ensuring that developers minimize time on chores such as building and configuring infrastructure, creating deployment pipelines, downloading packages for their solution, or onboarding onto solutions, like monitoring and secrets management.
One way to do this is to use the portal to ask developers questions about the solution they’re building, such as:

• What programming language and framework are they using?
• Is the application containerized?
• What is the backend? 
• Do they need new infrastructure?

Using a scaffolding tool, developers can get environments, CI/CD pipelines and integration with third-party tools, in minutes, allowing them to focus more on building new features for their solutions.

3) The Risk Engine

Determining the risk profile of an application is something that, in most financial services firms, is traditionally manual – and requires talking to various teams, such as compliance, governance and security.
The idea behind the risk engine is to try and automate as much as possible and make it part of the developer portal ecosystem.
In asking developers questions about their application, a risk engine can determine if the risk profile of an application with a higher risk profile will require additional steps such as DAST and IAST, or even penetration testing, whilst applications with a lower risk profile may not require the same level of scrutiny.
A risk engine can help automate the traditional manual step of trying to get all the right people together, across multiple teams. Although it may not be able to automate everything, anything that can be automated will reduce the friction between application teams and governance, and improve developer productivity.

4) Observability and Analytics

Financial services firms have traditionally been very thorough in tracking what’s occurring within the organization from an infrastructure standpoint, like what needs to be patched, and what third-party software, such as antivirus, needs to be upgraded.  

Where there has been less focus on custom-built applications within an organization, these have been left to application teams to manage. However, as mentioned previously, developers are not security or infrastructure engineers.

So, how do we ensure that developers follow security best practices when coding? How can InfoSec teams have confidence that there are no vulnerabilities lurking in application code and ensure that only components from the service catalogue are being utilized?

Having a well-defined service catalogue, and using a scaffolding tool, underpinned by a risk engine, goes a long way to ensuring that application teams are running their solution on secure infrastructure and following best practices by automatically creating deployment pipelines with the necessary steps, based on the risk profile of the application. 

But, to improve the experience – not just from a developer standpoint but also from an InfoSec one – it’s important to capture as much data as possible from the SDLC to make truly data-informed decisions.

Bringing together all this data, in a central store, exposed by the developer portal, can give application teams a complete view of their application, from commit to build, to deployment, and even when monitoring data from their infrastructure, to see whether they are meeting their SLO and SLIs.
InfoSec teams can utilize this data as well: to ensure that any application teams are meeting their compliance and security requirements; whether the correct services are being used; and whether they’re from the service catalogue or if anyone has gone rogue.  

This data can also be used to have a centralized view of tasks and to visualize gaps, such as improving technical debt, remediation against vulnerabilities and framework upgrades. Any team, including InfoSec, can then create a ‘movement’ with clear instructions. This data provides clear evidence, with a deadline, not only that a task needs doing but also that it will improve things in the future.

Having all this data available can really allow organizations to have a single source of truth and make better decisions, based on data.

Conclusion

There’s no one solution for implementing a developer portal. Every organization is different and there’s a burgeoning ecosystem of both open source and commercial products. But, the basic building blocks are as we’ve outlined above.

Self-service is essential here. By providing an ecosystem and enabling developers to make their own decisions, underpinned by components which meet the organization’s security and compliance requirements, agility is increased and time to market is reduced. 

But, with great power comes great responsibility. The financial services industry is heavily regulated, but it’s vital that teams don’t put up roadblocks; they must be able to monitor what’s going on within their organization and give application teams the freedom to build great products.
Implementing a developer portal will go a long way towards helping them do just that.