Forem: Sven Ruppert

The quick wins of DevSecOps

Sven Ruppert — Fri, 22 Jan 2021 12:32:15 +0000

Hello and welcome to my DevSecOps post. Here in Germany, it's winter right now, and the forests are quiet. The snow slows down everything, and it's a beautiful time to move undisturbed through the woods.

Here you can pursue your thoughts, and I had to think about a subject that customers or participants at conferences ask me repeatedly.

The question is almost always:

What are the quick wins or low hanging fruits if you want to deal more with the topic of security in software development?

And I want to answer this question right now!

For the lazy ones, you can see it as youtube video as well

Let's start with the definition of a phrase that often used in the business world.

Make Or Buy

Even as a software developer, you will often hear this phrase during meetings with the company's management and sales part.

The phrase is called; "Make or Buy". Typically, we have to decide if we want to do something ourselves or spend money to buy the requested functionality. It could be less or more functionality or different so that we have to adjust ourself to use it in our context.

But as a software developer, we have to deal with the same question every day. I am talking about dependencies. Should we write the source code by ourselves or just adding the next dependencies? Who will be responsible for removing bugs, and what is the total cost of this decision? But first, let's take a look at the make-or-buy association inside the full tech-stack.

Diff between Make / Buy on all layers.

If we are looking at all layers of a cloud-native stack to compare the value of "make" to "buy" we will see that the component "buy" is in all layers the bigger one. But first things first.

The first step is the development of the application itself.

Assuming that we are working with Java and using maven as a dependency manager, we are most likely adding more lines of code indirectly as dependency compared to the number of lines we are writing by ourselves. The dependencies are the more prominent part, and third parties develop them. We have to be carefully, and it is good advice to check these external binaries for known vulnerabilities.

We should have the same behaviour regarding compliance and license usage. The next layer will be the operating system, in our case Linux.

And again, we are adding some configuration files and the rest are existing binaries.

The result is an application running inside the operating system that is a composition of external binaries based on our configuration.

The two following layers, Docker and Kubernetes, are leading us to the same result. Until now, we are not looking at the tool-stack for the production line itself.

All programs and utilities that are directly or indirectly used under the hood called DevSecOps are some dependencies.

All layers' dependencies are the most significant part by far.

Checking these binaries against known Vulnerabilities is the first logical step.

one time and recurring efforts for Compliance/Vulnerabilities

Comparing the effort of scanning against known Vulnerabilities and for Compliance Issues, we see a few differences.

Let's start with the Compliance issues.

Compliance issues:

The first step will be defining what licenses are allowed at what part of the production line. This definition of allowed license includes the dependencies during the coding time and the usage of tools and runtime environments. Defining the non-critical license types should be checked by a specialised lawyer. With this list of white labelled license types, we can start using the machine to scan on a regular base the full tool stack. After the machine found a violation, we have to remove this element, and it must be replaced by another that is licensed under a white-labelled one.

Vulnerabilities:

The recurrent effort on this site is low compared to the amount of work that vulnerabilities are producing. A slightly different workflow is needed for the handling of found vulnerabilities. Without more significant preparations, the machine can do the work on a regular base as well. The identification of a vulnerability will trigger the workflow that includes human interaction. The vulnerability must be classified internally that leads to the decisions what the following action will be.

Compliance Issues: just singular points in your full-stack

There is one other difference between Compliance Issues and Vulnerabilities. If there is a compliance issue, it is a singular point inside the overall environment. Just this single part is a defect and is not influencing other elements of the environment.

Vulnerabilities: can be combined into different attack vectors.

Vulnerabilities are a bit different. They do not only exist at the point where they are located. Additionally, they can be combined with other existing vulnerabilities in any additional layer of the environment. Vulnerabilities can be combined into different attack vectors. Every possible attack vector itself must be seen and evaluated. A set of minor vulnerabilities in different layers of the application can be combined into a highly critical risk.

Vulnerabilities: timeline from found until active in the production

I want to have an eye on as next is the timeline from vulnerability is found until the fix is in production. After a vulnerability is existing in a binary, we have nearly no control over the time until this is found. It depends on the person itself if the vulnerability is reported to the creator of the binary, a commercial security service, a government or it will be sold on a darknet marketplace. But, assuming that the information is reported to the binary creator itself, it will take some time until the data is publicly available. We have no control over the duration from finding the vulnerability to the time that the information is publicly available. The next period is based on the commercial aspect of this issue.

As a consumer, we can only get the information as soon as possible is spending money.
This state of affairs is not nice, but mostly the truth.

Nevertheless, at some point, the information is consumable for us. If you are using JFrog Xray, from the free tier, for example, you will get the information very fast. JFrog is consuming different security information resources and merging all information into a single vulnerability database. After this database is fed with new information, all JFrog Xray instances are updated. After this stage is reached, you can act.

Test-Coverage is your safety-belt; try Mutation Testing.

Until now, the only thing you can do to speed up the information flow is spending money for professional security information aggregator. But as soon as the information is consumable for you, the timer runs. It depends on your environment how fast this security fix will be up and running in production. To minimise the amount of time a full automated CI Pipeline ist one of the critical factors.

But even more critical is excellent and robust test coverage.

Good test coverage will allow you, to switch dependency versions immediately and push this change after a green test run into production. I recommend using a more substantial test coverage as pure line-coverages. The technique called "mutation test coverage" is a powerful one.

Mutation Test Coverage
If you want to know more about this on, check out my YouTube >channel.
I have a video that explains the theoretical part and the >practical one for Java and Kotlin.

The need for a single point that understands all repo-types
To get a picture of the full impact graph based on all known vulnerabilities, it is crucial to understand all package managers included by the dependencies. Focussing on just one layer in the tech-stack is by far not enough.

JFrog Artifactory provides information, including the vendor-specific metadata that is part of the package managers.

JFrog Xray can consume all this knowledge and can scan all binaries that are hosted inside the repositories that are managed by Artifactory.

Vulnerabilities - IDE plugin

Shift Left means that Vulnerabilities must be eliminated as early as possible inside the production pipeline. One early-stage after the concept phase is the coding itself. At the moment you start adding dependencies to your project you are possibly adding Vulnerabilities as well.

The fastest way to get feedback regarding your dependencies is the JFrog IDE Plugin. This plugin will connect your IDE to your JFrog Xray Instance. The free tier will give you access to Vulnerability scanning. The Plugin is OpenSource and available for IntelliJ, VS-Code, Eclipse,... If you need some additional features, make a feature request on GitHub or fork the Repository add your changes and make a merge request.

Try it out by yourself - JFrog Free Tier

How to use the IDE plugin?

If you add a dependency to your project, the IDE Plugin can understand this information based on the used package manager. The IDE Plugin is connected to your JFrog Xray instance and will be queried if there is a change inside your project's dependency definition. The information provided by Xray includes the known vulnerabilities of the added dependency. If there is a fixed version of the dependency available, the new version number will be shown.

If you want to see the IDE Plugin in Action without >registering for a Free Tier, have a look at my youtube video.

Conclusion

With the JFrog Free Tier, you have the tools in your hands to practice Shift Left and pushing it into your IDE.

Create repositories for all included technologies, use Artifactory as a proxy for your binaries and let Xray scan the full stack.

With this, you have a complete impact graph based on your full-stack and the pieces of information about known Vulnerabilities as early as possible inside your production line.

You don't have to wait until your CI Pipeline starts complaining. This will save a lot of your time.

Youtube

If you liked this blog post, I would appreciate to have you as my new subscriber on Youtube.

I have two channels, one in English and one in german.

On my channel, you will find videos about the topics Core Java, Kotlin and DevSecOps.

Please give me a thumbs up and see you on my channel.

Chartcenter or - Do not reinvent the wheel

Sven Ruppert — Wed, 21 Oct 2020 15:13:23 +0000

Who doesn't know the times when there was only one server in operation? A single computer that combines all the services that are required within the company. In the beginning, it was a simple printing service so that you only had one central printer within the company. Services were added later, such as a shared file storage system, email server and so on and so on. The requirements were continually being revised upwards, and gradually more and more servers were offering the necessary services alone and later in a network.
The first server failure in a company could be perceived as a warning event. A person who looked after the server and subsequently the server became an independent IT department. It quickly became apparent that different optimization goals, unfortunately, stood in each other's way. As an example, I would like to mention the cost development, which sadly took an unpleasant course in connection with the design of the reliability of individual services.

The first virtual server

A new age in IT began with the development of virtualization. Services could now be separated from each other even more intensely on the physical hardware. Several services on one hardware server were now easy to implement again. With this new technology, however, new weak points in the area of security were introduced into the existing IT landscape. The requirements for the IT department were changed again at this point. The approach of using this virtualization, not like a component kit has established itself over time. More and more often, it was possible to obtain prefabricated virtual machines from the respective software products. The configuration within these modules could therefore, be provided directly by the manufacturers, which represented a big leap for the success of this technology.

One server becomes many servers

Over time, the demand for the computing power provided has grown steadily. The hardware could only keep up to a limited extent at this point if you didn't want to let the hardware costs grow into infinity. It turned out that many commercially available servers could be used in such a way that a higher level of reliability is achieved compared to a particular expensive server. So it made sense to look at the way to manage this zoo of small servers efficiently. After several approaches by different companies and the most diverse communities, a combination prevails on the market worldwide. The combination of Docker as a para-virtualizer and Kubernetes as a management tool is the current industry standard.

complexity

Unfortunately, it has always been the case with distributed systems that the underlying mechanisms are not trivial. On the one hand, location transparency is desirable to realize availabilities that are not minimized even by changing the version of the individual components. However, on the other hand, it is by no means trivial to provide the services required to manage this location transparency. So it was time within IT to deal with how declarative approaches can be used to make controllability accessible to the general public in IT. One method that is becoming more and more popular is described under the term "infrastructure as source text". The aim here is to define a description language that enables the required IT system to be described in its entirety. These definitions are then used within code versioning systems, e.g. git, so that you can easily switch between different versions of a description.

Don't reinvent the wheel

One of the essential principles within IT is that you should reuse existing knowledge efficiently. In this case, it means that one should take over the existing description of partial systems to compose the required overall system from them then. What sounds simple has it all in the details. There are immediately some questions that arise in practical use.

Where do I put my experiences?

The question of the right place to store your experiences so that others can access them is essential. In the past, it has been shown that the approach of creating a superset is prevalent. Be it with tools like maven or npm, or with operating systems like Linux. It enormously simplifies access when there is a central authority that can be used as an initial entry point. For the definition of infrastructure compositions, the "description language" HELM is the industrial location when using Kubernetes. HELM is the package manager for Kubernetes similar to maven it is for the Java world. To offer a central entry point for the community, https://chartcenter.io/ was created. It's a superset of different sources to make an efficient and user-friendly collection point.

Trust

The next question that arises is the question of trust. In other words, one can ask oneself about the vulnerability or security of the components offered. The parts shown are, in turn, very complex units consisting of program elements and their configuration. These sub-systems, in turn, have their characteristics and also have their dependencies. The complete dependency graph is complicated for a human to grasp. Manual control is almost impossible. Here the IT itself has to be used again.
At chartcenter Xray from JFrog is used to check the definitions stored there. All binaries that are used directly and indirectly in these compositions are examined for known security gaps. This results in a complete dependency graph that shows where security gaps are present and how they affect the overall context.

The first steps

In order to start composing your own environment, you also need to know what is actually there. Tools that support navigation in this component repository using full-text searches and taxonomies help here. Here https://chartcenter.io offers a very intuitive and user-friendly graphical interface to identify the essential components required in the shortest possible time. The additional necessary information based on the README (for example https://chartcenter.io/bitnami/postgresql ) of the element helps to make the first decisions quickly.
The initial commands for using the selected component are also available.

Conclusion

In summary, one can say that https://chartcenter.io is the next logical step to meet the requirements of IT. In order to make the existing components efficiently usable, a central location is required where this knowledge about the existence and availability of the ingredients is collected. Access is free and supports every developer who wants to use these components as well as those who want to make their knowledge and skills available to the general public. This approach supports every open source project directly and indirectly and helps to harden the IT world a little further with the security information offered.
The next step is to visit the website to get your picture of how easy it is to use these components.

Cheers Sven

AWS-CodeArtifact versus JFrog-Artifactory

Sven Ruppert — Fri, 19 Jun 2020 17:57:18 +0000

Welcome, AWS-CodeArtifact to the world of repository managers.
Amazon has marked the Managed Service AWS CodeArtifact as a GA, thereby giving the general public access. But what is this service all about, and how does it compare to JFrog-Artifactory? We'll take a quick look at that here in detail.

btw: read other parts of the series here:

JFrog Artifactory vs AWS CodeArtifact: Comparison in 10-ish parts

JBaruch 🎩 ・ Jun 19 '20 ・ 2 min read

#jfrog #artifactory #aws #codeartifact

BirdEye View

In summary, one can say that Amazon is immersed in an existing market in which some competitors have a much longer history. You can see that from the variety of functions on the JFrog site. There is still significant potential here on the Amazon side. As with all Amazon products, the use of this service is fully tied to the AWS cloud itself. If you look at the price model, Amazon has the billing model that is typical for this platform and is difficult to predict, based on read- and write- cycles. Anyone who can foresee this must know and be able to estimate their development processes down to very delicate actions. If this is not the case, cost accounting can quickly reach areas that were not foreseen. Here, the simple license model from JFrog has a clear advantage, and there are no surprises in the planning. With JFrog-Artifactory, you also have no vendor lock-in in terms of the runtime environment and IT architecture. Here you can be sure that you will have the free decision in the future towards the cloud, or even out of it again. Migration scenarios are possible in any mix between OnPrem and SAAS.
In terms of supported technologies, there is a distinct advantage of JFrog products. And the design options for the repository structures are much more flexible compared to the CodeArtifact options. Amazon has just three package managers in its portfolio. And also in the way the compositions can be set up, the virtual repositories are a feature from Artifactory that leads the field unbeaten. It remains to be seen what Amazon wants to bring up next.

Repositories and how to use binaries efficiently

After we have seen what the basic options for repository composition look like, the question arises which advantages and disadvantages result from this for production. At this point, I assume that we are in a DevOps or already in a DevSecOps environment. For each change made available in a source code repository, a build process starts, which then leads to a binary package stored in an artifact repository. This behavior inevitably leads to a sharp increase in the resources required to keep these binary packages available for further progression. On the other hand, you also want to prevent partial results or results that have caused a termination within processing to bleed into other production processes. It is therefore essential to make a very accurate separation here. How can this be implemented in the two systems mentioned here?

In addition to the previously mentioned approach, the amount of new created binary fragments usually decreases with every further step in the build pipeline. For example; From several feature branches, a develop branch from which a release branch can then become. With every further development stage, i.e. with every additional step within the production chain, the frequency with which artifacts generated decreases. As soon as a new binary has been created in a develop branch that contains the source code changes of an analogous feature branch, all created artifacts of the corresponding feature branch can be removed. Removing can now mean that they are deleted, or just hidden from the active repository structures of the subsequent production stages.

Now we come to our candidate from Amazon. Here you can build a tree from repositories. This structure enables you to establish a caching process. But how do we isolate the individual stages in the production chain? Based on the tree structure and the current restriction that you can only ever have one higher-level repository, only stringent top-down structures can be mapped. Cross-sectional structures cannot be represented in this way. A subsequent stage cannot have a sub-selection of the higher-level element here. To isolate the binaries from the feature branches, you have to set up your structure at this point and then rebuild all associated binary packages during a merge in the developer branch to save the result again in the repository belonging to the develop branch. This approach has some conceptual weaknesses that I would like to point out here explicitly.

One point is that you have to reproduce this procedure in every project, which is only a matter of time before bumps and errors creep into this structure. Additionally, running this procedure means that the results of a previously executed build process must be delivered again.
It is better not only to minimize this effort at this point, which will bring temporal, financial and ecological advantages but also follow the DRY principle very clearly.

What is the solution with Artifactory? Here you can assign a dedicated private local repository to each production stage in which the artifacts created. Because all operations in the JFrog products offered via REST as well, it is also possible to automatically assign a repository to a newly created feature branch. If you want to map the isolation even more explicitly, create a separate artifact repository for each processing level in a build-plan. This solution then has the additional advantage that the last failed step of the partially completed build processes can be started again at the previous finished point without having to go through all previous stages. DRY!

The needed cross-sectional repositories can be defined using virtual repositories. Only those elements that are necessary for this production stage are then active within these repositories. This concept helps that no artifacts from previous steps can bleed in that do not belong to precisely this production stage for exactly this entity of the outcome to be generated. Maintenance of the artifact inventory can also very efficiently implemented since the partial repositories that are no longer required are deleted or deactivated directly.

last words

In terms of supported technologies, there is a distinct advantage of JFrog With this brief overview; this topic is far from exhausted. To do this, I will gradually look at the various sub-areas over the next few weeks and make a direct comparison.
If particular aspects of these comparisons are of interest, please contact me directly. The order of the areas has not yet been determined. But if you want to get a realistic picture, I cordially invite you to start a trial and try it out by yourself.

Cheers Sven

btw: read other parts of the series here:

JFrog Artifactory vs AWS CodeArtifact: Comparison in 10-ish parts

JBaruch 🎩 ・ Jun 19 '20 ・ 2 min read

#jfrog #artifactory #aws #codeartifact