Shifting Security Left in the HERE Platform

With each month, the HERE platform continues to expand not only on the features that our services offer, but the set of services offered to our customers. Alongside this growth, we are absolutely unwilling to waiver on our commitment to securing our services and the data hosted on our platform.  This creates an interesting challenge: how do you enable a company to grow quickly without taking on additional security risk? HERE is heavily investing in quite a few efforts in this area, and  we want to highlight one that we believe is having a huge impact: Shifting Security Left. 

To ensure security is not a bottleneck for rapid feature releases and product growth, we’ve increased investment in automated security tooling that can plug into our product development pipelines. At HERE, we are in the process of migrating products to Gitlab Pipelines for our Continuous Integration and Continuous Delivery (CICD) development process. This presents us with two great opportunities:

1. Iterate on our templated security guidance so that we continue to provide easily adopted security guidance to developers
2. Present this templated guidance to developers as they are codifying their CICD, in our case the .gitlab-ci.yml file

Security in CICD is not at all new at HERE; we’ve been providing security guidance and automated tooling for HERE products long before our move to Gitlab. But this move allows us to revisit these practices and share our strategy with the community at large.

A typical Gitlab Pipeline, or more precisely a .gitlab-ci.yml file, at HERE looks like this from a high level:

You’ll notice that there’s nothing specific to security in here. Developers test code, compile it, save off the result. Then our developers put the result into the environment where it’ll run, test that environment, and save it off. Then they deploy if the change is approved and destined for production.

There is nothing new in the developer process in what is shown above. And we in Security believe that is key to building secure software over time. Our security requirements do not interject entire new stages into a developer’s CICD pipeline which require separate attention. This allows them to continue focusing on development without large, time-consuming interrupts.

One templated piece of code added into a .gitlab-ci.yml file provides a development team in depth security insight early in the development cycle. GitLab pipelines can run a Static Code Analysis tool, for example, inline during a pipeline’s test-code stage. HERE developers already embrace static code analysis that detects performance and bad coding practices.  Our templated code leverages the same paradigm to test for security concerns.

So where, then, do we actually “Shift Left”?

Release Package

In the release-package stage, our development teams upload their application package to our JFrog Artifactory server. JFrog Artifactory is a feature-rich tool for managing build artifacts of any kind, from logs to binaries. It tracks each resource’s version history and maintains metadata unique to a given artifact type, building a rich library of our software dependencies.

Security shifts another increment leftward when we turn on JFrog’s Xray plug-in within Artifactory.  Once a package lands in Artifactory, Xray automatically scans that package looking for any known vulnerabilities associated with the components contained within the package. It will also do license compliance, but we use our own OSS Review Toolkit for that.  Nothing needs to be done by the developer to trigger the scan. The simple act of uploading the package to Artifactory, which happens as part of the CICD pipeline flow, triggers Xray’s scan.

With these results, developers can take action to address known vulnerabilities, and feed the components they use back into our company’s threat intelligence team. This catalog allows our security team to easily query the packages in use by HERE within minutes of a new vulnerability being released.  That’s a game changer. With that kind of advanced notice, it’s possible to stay a step ahead of attackers’ ability to deploy exploits which abuse newly identified vulnerabilities.

Build Image

HERE platform heavily utilizes containers for application environments. As teams build these containers, we use a self-hosted container repository called Quay to store the containers.  This allows us to take control of our supply chain by not pulling directly from a 3^rd party. It also allows us to utilize Quay’s tool for container security analysis, called Clair.

As soon as a container is uploaded to Quay, a scan is queued up for Clair. Much like Xray, this scan breaks the container down into its different elements and scans them for known vulnerabilities. As a scan finishes, there are a number of notification actions we can use to alert developers about vulnerabilities in their container images. Again, no manual trigger is required by developers other than uploading their container image to the container repository.  And that is another default step in their CICD pipeline flow.

Completing the Picture

Once a Gitlab Pipeline has finished, a development team and security both have the information about the security state of the software they’ve produced. They know that:

• Their code has been reviewed for vulnerabilities
• The software components they rely on have been reviewed for vulnerabilities
• The environment they put their application into has been reviewed for vulnerabilities

This is not the entirety of HERE’s Shift Left plan. We also have additional security analysis tools that we are exploring to specifically:

• Reduce the time that it takes a developer to get feedback from a security scan
• Improve the coverage of our tooling across a broad developer ecosystem

Tooling empowers developers by alerting them to a weakness as soon as it is possible to identify it. But a large part of security is about building a culture where security is a considered in every development iteration. To assist in that cultural maturity, we are building a Security Champions program. Security Champions help to level up their development area’s security acumen. The more security pushes left in the development cycle, the more comfortable it becomes for developers to make security choices without requiring full reviews from the formal Security teams.

This post only highlights some of the security efforts we are excited about at HERE. As the year progresses, keep an eye out as we are looking forward to sharing even more.