2.1 AppVet System
comprises the AppVet web service and its
associated tools and clients. In an AppVet system, the app vetting
workflow begins when a client submits an app to AppVet. When AppVet
receives an app, it registers the app and performs some pre-processing
of the app. Preprocessing is used to extract meta-data about an app and
possibly provide additional functionality such as ensuring that the app
conforms to specific requirements of the hosting organization. After
preprocessing an app, AppVet sends the app and related information to
one or more tools for testing and evaluation. When a tool completes its
analysis, it returns a report and risk assessment to AppVet which, in
turn, makes them available to clients. In addition, AppVet generates an
overall risk assessment based on risk assessments from all tools. The
AppVet system architecture is shown in Figure 2-1.
AppVet System Architecture.
An AppVet system comprises clients that submit apps to the system and
consume reports and risk assessments. Clients include users (such as
developers and analysts) and applications (such as app stores and
continuous integration environments). Using a web browser, users access
AppVet via the AppVet
App Management Interface
(AMI) shown in Figure 2-2.
Figure 2-2. AppVet
App Management Interface.
The AMI provides support for uploading apps, accessing reports
and assessing risk. Client applications, on the other hand, access AppVet
through the AppVet API
An AppVet system comprises tools that analyze apps for security
vulnerabilities. A tool may be provided by a third-party vendor, tool
developer, or user that leverages an existing tool. In an AppVet system,
tools must be available as online services called
. To facilitate integration of a tool service with
AppVet, AppVet requires a service to implement a simple REST API for
submitting apps to, and receiving reports and risk assessments from, the
service. AppVet defines three types of tool services:
2.3.1 Synchronous Tool Services
A synchronous tool service is a service that accepts an app from AppVet
via an HTTP Request and responds with a report and risk assessment via
the corresponding HTTP Response. Because clients will block waiting for
a response from a synchronous tool service, such services are aimed at
analyses that can be performed relatively quickly. Figure 2-3 shows the
AppVet synchronous tool service protocol.
Figure 2-3. AppVet Synchronous Tool Service.
For more information on synchronous tool services, see the
Synchronous Service API
For tool services that take an
extended amount of time to analyze an app, an asynchronous tool service
may be used.
2.3.2 Asynchronous Tool Services
An asynchronous tool service is a service that accepts an app from
AppVet via an HTTP Request and immediately responds with an
HTTP 202 Accepted
indicating that the app was accepted for processing. After processing
the app, the service will then send a report and risk assessment via an
HTTP Request to AppVet. Figure 2-4 shows the AppVet asynchronous tool
Figure 2-4. AppVet Asynchronous Tool
For more information on asynchronous services, see the
Asynchronous Service API
2.3.3 Push Tool Services
A push tool service is a service that sends a report and risk assessment
to AppVet without first receiving a corresponding request from AppVet.
Such cases occur, for example, if the service analyzes an app on behalf
of another tool service. After the tool service analyzes the app, it
sends the report and risk assessment to AppVet as shown in Figure 2-5. Note
that both asynchronous and push tool services serve as clients to AppVet
when submitting reports.
Figure 2-5. AppVet Push Tool Service.
For more information on push tool services, see the
Push Reports API