Tayloring Projects - an example

TrustSource has been designed to support compliance of solutions, to address security of complete solution stacks. This is why we do not stop at the SBOM. We allow to include all software your solution comprises of.  This includes infrastructure such as middleware internal as well as external services or Common of the Shelf (COTS or 3rd party) components.

To give you an idea of how to benefit from all this, we will use an example application and show how we would tailor the application so that you may better understand the concepts behind TrustSource. Therefor we assume you want to provide a small time tracking app to your colleagues, so that they will be able to better keep track of their worktime. In a first draft you may come up with an architecture like the one depicted in the following diagram.

Our example App

The app will consist of two services. One to capture and manage the HR data (who, how much, passwords, etc.) used by an admin and a second service addressed to the users who want to enter work time, the time entry service. Both services will use one persistence layer.

In addition a notification service will periodically remind those that did not complete the entries by the end of the week by email Sunday evening. In our target architecture, this Notification Service will be triggered using a cron job and an external email service.

Assessing the Implementation

In a first step, it should be of interest to see what implements the different components because each language and implementation environment may create specific scanning requirements.

In our case, the application service interfaces both are implemented in JavaScript. One of the services logic is implemented using Java (operated on a tomcat) , the other uses python (on a flask server) Both will be provided in a separate docker container on alpine. The persistence is provided by a MySQL server, running on a separate instance. The notification service is provided as a C++ implementation, also running in a separate container, invoked by a cron-job on the DB server instance. As the Mail-provider sendgrind has been selected (no commercials, just the first logo I found). The following diagram displays this implementation view.

Based on this information different scanning requirements become visible:

1. The service implementations of the two main services with user interaction consist of environments using package managers. These are standard cases where scanning can be done as part of the CI/CD chain. All four languages are covered by ts-scan, our preferred scanning solution. But they also could be scanned using any of the given environment specific solutions available as long as they will produce a CycloneDX or SPDX SBOM. This SBOM later will be uploaded to TrustSource for analysis.
2. The C++-Service might be build using Cmake or Conan, which would set it in the same direction as the package manager systems under 1. But it also may be build in a more traditional approach. However, to do a precise composition analysis, the files of the solution must be scanned directly. This can be done either using our ts-scan or the underlying tool ts-deepscan. 
3. MySQL, Tomcat, Flask and SendGrid are third party solutions, where MySQL, Tomcat and flask are open source, SendGrid a closed source solution. This will require a specific treatment, since we might decide not to build them all from scratch or may not even have the sources available to scan them. 
4. The alpine base image used for the services will also require a specific treatment. Here you may decide on your risk appetite, whether you trust the "official" alpine image or you prefer to build the base image yourself from the alpine distribution. The proper way for best security would be to build the image as well as all of its components by yourself. Formerly, the way to scan your base image would have been to use ts-docker in combination with syft by anchore. Today you may select ts-scan, which comes with these competencies included. 

Tailoring the project

However, now since the scanning requirements are clear, it is about to tailor the scan targets and derive a project structure. This includes thoughts on how the development cycles of the different targets will evolve over time. Finally, there is no wrong or right. It is completely up to you, how to tailor your project. But for this "implementation" we would recommend to select a tailoring as depicted in the diagram below.

In a first step it is important to understand that TrustSource differentiates products, projects and modules as classification elements. While products are a term addressing "things that leave the company towards customers", projects represent all sorts of deliverables that have a business value by themselves. e.g. providing a business function. In general a project has its own release cycle. 

Modules resemble delivery artefacts. You may see either a binary, a library or an archive as an equivalent. Also modules may have their own release cycle. But modules can be combined with other modules and projects into projects. 

The Structure

This said, the tailoring of the project might result in the following tree structure:

• Time Tracking Solution (Project)
  • HR Service (Project)
    • HRS-UI (Module)
    • HRS-Backend (Module)
    • Tomcat (infrastructure component)
  • Time Entry Service (Project)
    • TES-UI (Module)
    • TES-Backend (Module)
    • Flask (Infrastructure Component)
  • Notification Service (Project)
    • Notification Service (Module)
  • Sendgrid (COTS)
  • MySQL (Infrastructure component)
  • alpine docker (Infrastructure component)

Depending on your preferences you may consider to provide cron as a separate module in the notification project or you may choose to add it through alpine since it may be installed during the container setup. Given you would be building it by yourself, we would recommend to add it as a separate project11. When you prefer pulling it from alpine during the container setup, you may prefer to leave it a spart of the alpine distribution.

However, this example clearly shows the flexibility TrustSource is providing. The self referential architecture, which allows you to link projects into projects gives you maximum flexibility to create all sorts of hierarchies. See here for more information about the different levels TrustSource is supporting. Find further thoughts behind the given structure below.

Why there are four projects?

The outer bracket is the solution "Time tracking Solution". This is the business purpose. It is what a user may see. There is a some infrastructure and three main services providing logic: HR-Data Service, TimeEntry Service and the Notification Service.  Both consist of several elements, diverse technical components and may follow an independent development plan. Thus, it may be useful to release them separately. It is also possible, to release modules separately. But since each of the services consists of several elements, which most likely are not independent from each other, it seems to be better to combine them. Combining elements is only possible on project level. Thus, it is useful to create three projects, one for each service.

In a next step you would create the framing project Time Tracking Solution and add the other three projects into the new project. Whenever a new project release from any of the subprojects will become available, the project manager of the framing project may decide to "upgrade". In general this would be the case, when a new deployment happens. This will transport the then valid structures of the particular release of the subproject into the project. From now on vulnerabilities and legal obligations of the new SBOM will apply to the main project. Up to the upgrade, the pure existence of a new version of the subproject will keep the project unchanged.

This  allows for precise, version specific security management. You may even change these upgrades automatically during the deployment within the CI/CD chain using the API. This will keep your reporting accurate.

Why are Tomcat and Flask Infrastructure modules?

TrustSource Projects allow to add infrastructure modules. We use this term to refer to well known stuff that often is used in projects as infrastructure. Whether it is a database, a webserver or a cache. All these components are used as runtime environments. Most often they are not modified and  will not be referenced or called directly in the sources of any solution. They tend to be developed outside your project scope. But they are part of your project!

Whether it is open source like a Tomcat or closed source like the SendGrid-Service in our example, it is part of the solution and requires you attention when it comes to risk or security management. To give you a chance to include these elements, we introduced the concepts of COTS and infrastructure components. 

While infrastructure comprises all sort of open source middleware that supports your solution, COTS represents the proprietary components. We collect data about these components in the background. We allocate CVEs or pull security advisories from vendors, when components are added. This data will automatically added to your risk and vulnerability reports, allowing you compliance managers a complete overview without the need to look into all the details of these "infrastructure components". 

Why is there a notification module in the notification project?

Every deliverable requires a module. Thus every project has at minimum one module. Since we decided to operate the notification service as the other two services as a project, the notification project was born. The notification project then requires the notification module to carry the information from the scanning of the notification service artefact. 

Since the notification service in this solution comes as a single executable, it could also be modelled as a module inside the TrackingTime project. This would not make any difference. But given sendgrid later would provide a library to connect securely to it, the module would not be able to cover the library. A project would be able to add the library as COTS.

This is why we decided to select a project at this level. However, it could also be solved in a simpler way by assigning the module directly to the TimeTracking project. You also may decide at any time in the future to create a new project for the module and move the module into this new project, create a release and add the new release into the TimeTracking project. So do not fear in making a mistake.

If you still feel like you might need decision support, feel free to reach out to our helpful support team. They are lucky to help!