For the first decade of its life, Tyro Payments of Australia was in the business of providing EFTPOS services to small and medium enterprises. In 2013, Tyro decided to take the “next step” and transform itself into a full scale bank, processing loans and taking deposits, in addition to their core business of processing card transactions.
Today, the company has more than 140 developers across eighteen engineering teams. To better support rapid growth Tyro had to implement processes to manage component usage, monitor application aging and eliminate licensing issues. They chose Nexus Repository and Nexus Lifecycle to automate the monitoring of those processes and improve the speed of their software development teams.
One of the challenges with taking this next step was for Tyro Payments to increase their security posture. They began investigating solutions for creating a comprehensive component inventory for their applications, identifying vulnerable components and assessing the level of risk within the components discovered.
It was important for the solution not to impede Tyro’s Agile processes or put up gates requiring “stamps of approval” as developers were building and updating applications. The desire was to empower developers to be able to quickly create and manage microservices, with minimal manual obstructions. The solution needed to inform them if they were selecting a component with a known vulnerability, provide them the information as to why it was not secure, and to empower them to remediate vulnerabilities instantly.
When Tyro began their search for risk assessment and monitoring tools, they found many which returned large quantities of false positives. “If you're trying to improve the security information given to your team, and you're given a lot of false positives, it actually makes people frustrated with security,” says Edwin Kwan, Application and Software Security Team Lead at Tyro.
“We focus a lot on engineering because we believe in innovation and growth. Our team uses Nexus Lifecycle to make sure we have no vulnerabilities, no license issues, and to minimize our use of outdated or dead open source projects. We have about 5 gigabytes of traffic we send to the Nexus Lifecycle server every day. Before Nexus Lifecycle, we really had no way to monitor policy violations or licensing risks. There was no mechanism for running these checks."
“Once we implemented Nexus Lifecycle, we had an immediate overview, a high-level picture of where the vulnerabilities were. It gave us a way to actually prioritize what to fix,” explained Kwan.
“There are two ways issues are discovered by Nexus Lifecycle. The first is when an engineer tries to introduce a vulnerable component. When something is vulnerable, our Nexus Lifecycle policy fails the build. You cannot submit anything if something is broken. It actually stops the pipeline. You can't go further until the issue is addressed.”
“The second way a vulnerability comes in is when new vulnerabilities are discovered in existing components. We have large TV displays everywhere showing the status of all our builds and we have set up Nexus Lifecycle email notifications for policy violations.”
“Once that happens, we get everyone together and we talk about the problems identified by Nexus Lifecycle. We do some investigation to see how it impacts us and talk through possible fixes. After that we write a Confluence page on the way to mitigate or remove the problem. We then give it to every team who has been affected by it to then fix it.”
In addition to Nexus Repository and Nexus Lifecycle, Tyro uses Atlassian JIRA and Confluence to manage tasks and team communications. Jenkins and GoCD are used for continuous builds, and Puppet is used to ensure that whenever a change is made to a developer image, everyone gets it.
One thing worth noting is that Tyro uses a microservices architecture, with many small applications handling a single function, rather than one monolithic application managing multiple functions. The microservices talk to each other through shared libraries stored in Nexus Repository. Whenever a change is made to a dependency file, or a new library is required, a change is made to the POM file and a clean Maven install is built. A scan is run for each of the nightly builds for all applications.
Finally, when a Jenkins CI job kicks off, a Nexus Lifecycle scan is done to make sure all components are approved for use against it's automated policies.
“We are in the process of moving to continuous delivery, where every time a change is made it goes right out to production. That way we produce smaller incremental changes rather than a big release, which is riskier."
“Before Nexus Lifecycle, we really had no way to monitor policy violations or licensing issues. We have so many applications, it's really hard to keep track. Once we implemented Nexus Lifecycle, we were then able to monitor and keep track of those issues. We were able to determine the severity of the issues, which gave us a way to prioritize what to fix. We then started fixing them -- knocking out the highest priority issues first."
“We’ve empowered our many development teams to choose whatever works best for them, as long as it is safe in terms of security and licensing. We just define and automate our policies in Nexus Lifecycle, defining what we don't want them to use: the things with known vulnerabilities or license risks. We like to go with the approach of ‘you can use anything you want as long as it fits within our policies’. If it fits, you're more than welcome to use it."
“I would recommend Nexus Lifecycle. That's the only way you have visibility into what you have.”