Joval not only features market-leading support for the SCAP family of specifications, we have also proposed several new schemas and dozens of new object types that have been accepted into the OVAL language specification. How is it possible for a relative newcomer to this space to not just develop comprehensive support, but also innovate and expand platform coverage so prolifically? The answer is that Joval was designed from the very beginning with a modular, pluggable, performance-oriented architecture. This architecture makes it possible for our team to rapidly add high-performance support for new schema objects, and to rapidly roll out support for entirely new OVAL schemas, in both our host-based agent and remote-scanning product components.
An architecture with modularity across multiple dimensions at the code level is not something that can be bolted on to a tired, decade-old code base; it is something that must be planned, even before the foundation is being laid. Only Joval customers can leverage the advantages inherent to our product’s design, either by using our SDK directly, or indirectly through our end-user products.
At its heart, Joval operates on three layers for managing the process of scanning target machines
At the bottom layer, there is a jSAF ISession that manages the connection to a target.
On top of this, there is a Joval IPlugin that references the ISession, and maintains a registry of schema object IAdapter classes. These adapters are responsible for using the session to extract information from the target machine, and potentially also, caching that information for future use.
Finally at the top layer, there are engines for processing OVAL and SCAP Datastream XML documents (IOvalEngine and IXccdfEngine, respectively), which reference their own IPlugin instances.
This three-layer pluggable architecture makes it possible to create a single object adapter to support both host-based and remote collection. It also lets us isolate the collection logic for schema objects completely outside the core document processing engine. Since our engine is schema-driven, adding support for new schemas almost trivial. We simply generate a data model from the schema, write the object adapters, register the model objects with the engine and register the adapters with the plugin — at runtime.
In some cases it is desirable to create a custom plug-in for Joval. For example, your application may store some information about target machines in a database, and you may want to retrieve that information if possible from the database instead of the target machine. In such cases, customers can create their own IPlugin implementations. Such implementations can inspect each object collection request made by the engine, and then either retrieve the information themselves, or delegate the collection to a wrapped Joval plugin instance.
Somtimes, customers want the ability to perform compliance assessments on information that is not exposed by any existing OVAL test. (Such has been the basis for the many tests we’ve proposed, which have been added to the OVAL language specification over the years!).
Since it can take (at worst) years before a new test is officially adopted by the OVAL community, we believe it’s important for our engine to be easily extended to support new types, and we’ve created a framework we support that makes it possible for customers to do this with our product.
Joval uses the abstract system interface defined by jSAF, to make it possible for an object adapter to function in multiple contexts (e.g., local, remote and offline scanning). In rare cases, a customer will want to define their own jSAF provider.
For example, in a simple case, if a customer has a database containing configuration data about routers and/or mobile devices, that customer might want to create their own ‘offline’ provider that would source information from that database. In a more complex example, a customer might already have their own native agent software distributed throughout the environment, and would want to leverage that as a mechanism for data collection. Both of these use-cases can be accommodated if the customer is willing to author their own provider implementation of the relevant jSAF interfaces.
Joval’s codebase is meticulously curated. We own the copyright for the majority of the code. All 3rd-party dependencies are redistributable using commercially-friendly terms (e.g., BSD, MIT and Apache licenses). Full documentation of 3rd-party dependencies and their associated licenses is available upon request.