grafeas / grafeas

Artifact Metadata API

Grafeas: A Component Metadata API

Grafeas ("scribe" in Greek) is an open-source artifact metadata API that provides a uniform way to audit and govern your software supply chain. Grafeas defines an API spec for managing metadata about software resources, such as container images, Virtual Machine (VM) images, JAR files, and scripts. You can use Grafeas to define and aggregate information about your project's components. Grafeas provides organizations with a central source of truth for tracking and enforcing policies across an ever growing set of software development teams and pipelines. Build, auditing, and compliance tools can use the Grafeas API to store, query, and retrieve comprehensive metadata on software components of all kinds.

Grafeas divides the metadata information into notes and occurrences. Notes are high-level descriptions of particular types of metadata. Occurrences are instantiations of notes, which describe how and when a given note occurs on the resource associated with the occurrence. This division allows third-party metadata providers to create and manage metadata on behalf of many customers. It also allows for fine-grained access control of different types of metadata.

Getting Started

• Watch the talk on Software Supply Chain Management with Grafeas and Kritis
• Read the Grafeas announcement
• Learn the Grafeas concepts and core design principles
• Run Grafeas locally following these instructions
• Once you have a running server, you can use the client libraries to experiment with creating notes and occurrences in Grafeas. There are client libraries available in Java, Go, Ruby, and Python.
• The authoritative API for grafeas is the protobuf files.

Grafeas Architecture

Grafeas project consists of

• the Grafeas API,
• a reference server implementation,
• 3 community contributed storage backends: PostgreSQL, BoltDB, and in-memory storage.

Longer-term, these are to be extracted into separate projects (see #341).

The diagram below shows the boundaries between Grafeas API, server, its storage backends and the clients:

Storage Backends

The following projects provide bindings for Grafeas API to different storage backends:

• grafeas-pgsql
• grafeas-oracle
• grafeas-elasticsearch
• grafeas-rds

Roadmap

Please see the Grafeas roadmap for the future of the project development.

Support

If you have questions, reach out to us on grafeas-users. For questions about contributing, please see the section below or use grafeas-dev.

Grafeas announcements will be posted to its @grafeasio Twitter account and to grafeas-users.

Contributing

See CONTRIBUTING for details on how you can contribute.

See DEVELOPMENT for details on the development and testing workflow.

License

Grafeas is under the Apache 2.0 license. See the LICENSE file for details.

grafeas's Issues

Add a QA Kind to Grafeas

Several people have asked for this, but we need a proposed Note/Occurrence schema. If this is something you're interested in - please start to add thoughts here. If a thread here becomes too unwieldy, I'll create a google document.

Swagger model definitions are complicated and hard to follow

The API definition have some room for improvement in that the model definitions should be concise and relatable. Current long list of metadata model is hard to relate to REST API request bodies and the hierarchy of models.

E.g. apiBuildDetails and apiBuildProvenance the API documentation is very hard to read, follow and make sense when it comes to defining API request bodies.

swagger documentation has errors

When i point swagger to the grafeas.json in v1alpha it throws parsing errors on line 523

Errors
Hide
Parser error on line 523
duplicated mapping key

Pointed at https://raw.githubusercontent.com/Grafeas/Grafeas/master/v1alpha1/grafeas.json

occurrence IDs should be generated by the API

In our reference impl of the v1alpha1 Grafeas API, we currently require the occurrence name to be set in CreateOccurrence:
https://github.com/grafeas/grafeas/blob/master/samples/server/go-server/api/server/v1alpha1/impl.go#L101

Occurrence names are output only and their IDs should be generated by the API:
https://github.com/grafeas/grafeas/blob/master/v1alpha1/proto/grafeas.proto#L774

Note this is unlike notes, which you need to set the ID for when creating.

This should be fixed in the v1alpha1 ref impl, or it can wait until we update the ref impl to v1beta1.

Add change history to track changes in occurrences over time.

Consistent naming of Note and Occurrence kinds

Two of the Note kinds are postfixed "Type" (VulnerabilityType and BuildType) but not the rest of them and three of the Occurence kinds are postfixed "Details" (CustomDetails, VulnerabilityDetails and BuildDetails) but not the rest of them.

I think this should be made consistent while the API is considered unstable. I don't think Type is great, but I am fine with no postfix, Details or something else (I would however rather use Type than not fixing it).

[Proposal] Use Protocol Buffers as spec definition format rather than OpenAPI(swagger)

Current Issue:

• The current swagger code generation process is unruly, generated code is checked in.
• Each implementation of the spec needs to create a router to handle request paths.

Reasons to use protocol buffers

• Protocol buffers with GRPC allow us to define http request options in the spec, so routers don't need to be self implemented.
• In addition, proto code can easily be generated at build time.
• Proto files are less verbose than openapi, and therefore a bit more human consumable.

grafeas.json isn't compatible with Swagger tools

So far I've been unable to use the Swagger JSON spec at https://raw.githubusercontent.com/Grafeas/Grafeas/master/v1alpha1/grafeas.json to generate any client or server code for the Grafeas API.

Using swagger-ui gives an error: "Parser error on line 523 duplicated mapping key"

Using NSwag, a .NET code generator for Swagger specs, throws a deserialization exception: "Requested value 'tags' was not found."

From what I can tell it seems that the current JSON spec for Grafeas doesn't follow the Swagger schema. Trying to validate grafeas.json at https://www.jsonschemavalidator.net/ throws many errors about the 'id' property not being part of the schema e.g this fragment:

"definitions": {
    "Occurrence": {
      "id": "Occurrence",

doesn't appear to be valid Swagger JSON.

Lowercase Grafeas repo and org

Go get is case insensitive while glide is not. This causes issues when using grafeas or its sibling repos as a dependency. I think the right thing to do is to change the github org and repo to lowercase (Grafeas/Grafeas -> grafeas/grafeas). While this may cause problems it won't be easier down the line.

BTW: Grafeas is not the only package that have done this this

Add database storage backend

A database will be required to run Grafeas in anything but development mode.

Querying for outdated images in a cluster?

Hi,

I'm curious for the state of thinking of grafeas' intended role in a common situation- a cluster operator wants to know at a particular point in time what images running in the cluster/namespace are out of date. The cluster or namespace equivalent to apt list --upgradable. Is it intended that this question be answerable with grafeas?

Make it possible to specify db credentials with environment variables

Postgres allows specifying the username and password through environment variables (PGUSER and PGPASSWORD) if the connection string to Postgres does not specify username and password.

Adding this would make it possible to configure db credentials with Kubernetes secrets.

Document how to add a new kind and regenerate libraries

add a protolinter to presubmit checks.

Reference Implementation: operation names are not currently validated when tied to notes/occurrences

Validate that operations exist, return an error if a referenced operation does not exist.

Implement filtering in reference implementation

Add Authorization to reference implementation

License tracking

For providers and scanners of binaries, and potentially their links to sources, it is a notable criteria to ensure LICENSE conformance. I could imagine this as a gating check.

Would data like LICENSE type live in https://github.com/Grafeas/Grafeas/blob/master/v1alpha1/grafeas.json#L1068 as a label on the source?

Add context as parameter to all methods in Storager and ProjectStorager

@skelterjohn suggested this in a comment regarding PR #81 (comment)

These interface methods should have a context as the first parameter. With context, you go all in. Annoying to plumb through, but the idea is that perhaps the underlying .CreateProject() call also makes an RPC to write the data - it would want to time out on the parent context as well.

Sounds like good idea to me but I am making it its own issue as it is outside the scope of the PR.

Provided Dockerfile does not expose Grafeas server

I pointed someone at this repo and they said the provided Dockerfile does not work. Upon review the sample server uses localhost instead of 0.0.0.0 such that I had to provide a config file.

Thoughts on making it "work" out of the box?

~/src/github.com/jonpulsifer/grafeas (expose-me) $ docker run -d --rm -p 8080:8080 grafeas
~/src/github.com/jonpulsifer/grafeas (expose-me) $ curl localhost:8080/v1alpha1/projects
{"projects":[],"nextPageToken":"0"}

proposed changes:

index 8c0deaa..f76dd49 100644
--- a/samples/server/go-server/api/server/config/config.go
+++ b/samples/server/go-server/api/server/config/config.go
@@ -41,7 +41,7 @@ type config struct {
 func defaultConfig() *config {
        return &config{
                API: &api.Config{
-                       Address:  "localhost:8080",
+                       Address:  "0.0.0.0:8080",
                        CertFile: "",
                        KeyFile:  "",
                        CAFile:   "",

If this cromulates I'll open a PR

[Feature-request] JENKINS integration for Grafeas

Proposal

• Jenkins Plugin for Grafeas

Why

• CI CD needs audits + governances for enterprise applications
• Grafeas is a Perfect candidate
• Jenkins has first class compatibility with Kubenetes from CI+ CD standpoint [https://jenkins.io/projects/jenkins-x/]
• Using the clear API contracts, we could have a closed loop CI + CG [ Continuous Governance ;-) ] + CD through when primitive of Jenkins Pipelines
  https://github.com/Grafeas/Grafeas/blob/master/case-studies/binary-authorization.md#toolchain-integration

What

• Use Grafeas java client https://grafeas.io/docs/guides/create-notes-occurrences.html#using-java
• Integrate with JenkinsPipeline Stages for https://jenkins.io/doc/pipeline/tour/post/
• PMD Checks
• Fortify Scans
• Checkmarx....
• A Plugin driven UX on Jenkins to visualize Notes + Occurrences + Kirits

RFC

Project listing API

I am planning to write a simple frontend for Grafeas. To do this I need to list projects but as far as I can see there is no API for this (right?)

If it is agreed upon that this is a good idea I would be willing to submit a PR for this.

Use golang/dep for managing the vendor tree

golang dep is the new/recommended way to handle deps.

Provide Issue Templates

Should we provide issue templates to allow easier onboarding? Ref #164 (comment)

e.g.

• feature request / proposal
• bug
• general questions

Split up the grafeas.proto file.

Split this file up like we do internally, right now it's massive and hard to sync from internal protos.

incomplete instructions for running sample server

https://github.com/grafeas/grafeas/blob/master/samples/server/go-server/api/server/README.md

As a new comer to the project, this file lacks enough detailed instructions to run sample server. For me, after adding src to $GOPATH I get this on centos7

$ go run main.go -config config.yaml 
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7fa83a]

goroutine 1 [running]:
github.com/grafeas/grafeas/samples/server/go-server/api/server/api.Run(0x0, 0xc42011ff68)
	/home/vagrant/go/src/github.com/grafeas/grafeas/samples/server/go-server/api/server/api/api.go:48 +0x3a
main.main()
	/home/vagrant/code/grafeas/samples/server/go-server/api/server/main/main.go:38 +0xa4
exit status 2

Signed artifacts

These artifacts are critical for control and audit proposes, they must be signed by the author in a model similar to Notary. It's complex to implement, we should consider leveraging a project like Notary.

Moreover, the storage must be irreversible (a la blockchain). CHAINIAC has concepts relevant for this project.

This is part of the MVP...

Enhancement Request: User definable tags/labels field in Occurrences

As part of change for #160 the occurrence (short) name will be assigned by the server. Clients will not be able to influence how the occurrence names will be assigned. As a result, clients will not be able to encode additional information in the names which can be useful for categorizing occurrences during searches.

It will be helpful if the Occurrences include additional field(s) for holding tag(s)/label(s) which can be suitably populated by the clients while creating the occurrences which will be very useful while performing searches.

As a use-case, we want to tag occurrences so that they can be categorized by generating scanners. Although we expect that there will be separate projects for holding notes pertaining to different scanners in most cases, we are also expecting that in some cases scanners may overlap and may need refer to shared notes. In such cases, the NoteName field may not be sufficient to differentiate among scanners.

This specific use-case aside, ability to add tags to occurrences will be helpful to categorize occurrences in different ways.

Support usage of STIX 2.0 within Grafeas to communicate cyberthreat (?)

STIX 2.0 (https://oasis-open.github.io/cti-documentation/) is a JSON-based OASIS open standard used to codify and exchange details of cyber threat intelligence and cyber threat incidents, and covers the gamut of what one would want to report in a cyber-threat related occurance, including

• Vulnerabilities
• Malware
• Observations (application activity, endpoint activity, network activity)
• Affiliated intrusion sets, threat actors, etc

I would propose / request that STIX 2.0 Report object be added as a KIND within Grafeas. This would allow security vendors to report, via Grafeas, when a cybersecurity incident appears to have compromised an instance or an image.

Add CRUD for projectIds to the api

Add an optional checksum field to occurrences

Add CWE to Vulnerability kind

The OWASP Top 10 is one of the most comprehensive documents for the appsec vulnerabilities. There is currently little or not support for its integration in security testing tools and secure software development pipelines, despite the benefits this could bring. I raised a discussion about this in these security stack- exchange posts (1 & 2), where I clearly defined some ways through which this could be leveraged. Since grafeas is coming with a security automation objective, the information in the top 10 could be integrated somehow. This would in no small measure assist in assessing the applications that are deployed in containers.

Is the current code buildable and functional?

Replace references to Google Cloud Storage

The grafeas schema contains several references to Google Cloud Storage (samples/server/go-server/api/storage_source.go, samples/server/go-server/api/build_provenance.go). I think these fields should be replaced by something less specific.

Proposal: note/occurrence signing

We should allow notes and occurrences to be signed. The server implementation should verify these signatures and reject if they are invalid. Notes can specify accepted keys, and occurrences attached to those notes must be signed with at least one of the accepted keys (and the server should reject the occurrence without one of the signatures).

Specifics

Notes and occurrences both get a top-level repeated string field signatures. The data to be signed will be the JSON string representation of the note or occurrence, minus the signatures field, with no indentation or newlines, and with object keys in alphabetical order. (perhaps use the proto bytes instead?)

Notes get a top-level accepted_keys field. Any occurrence attached to a note with an accepted_keys field must have a signature from at least one of the given keys - if the signature is not present in a new occurrence, the server will reject the occurrence.

Rationale

In the GoogleCloudPlatform-hosted version of Grafeas, the Container Analysis API, we rely on IAM permissions to assert sources of truth. For instance, the Container Analysis team asserts (and enforces via IAM) that the vulnerability notes in the "goog-vulnz" project can be relied upon.

We need something like that for Grafeas, and it would be very nice if that solution were general to any implementation without relying on an as-yet-unknown on-prem IAM service.

Management and distribution of private keys, while totally non-trivial, is a well-established problem with many acceptable solutions. By incorporating signing and occ-must-be-signed-by-note-key relationships into grafeas, we have a simple way to assert sources of truth, and management of keys is offloaded to some existing system.

Examples

Google publishes a public key GOOG_VULNZ_KEY through a trusted channel (eg, on a google.com website), and asserts that any vulnerability notes and occurrences will be signed with that key. Users of the hosted Grafeas service can download that key and verify that it is used to sign any vulnerability notes and occurrences.

An on-prem solution has a kubernetes deployment engine that writes deployment occurrences to their on-prem grafeas using a key that is kept within that agent. A policy enforcement agent can then verify any running deployments against the signed deployments in grafeas, and alert (or shut down) anything that doesn't have the right key signatures.

CreateNote/CreateOperation don't use 'parent' from protos

As I was fixing up the last issue, I noticed that the CreateNote/CreateOperation functions take in protos that have fields for the parent, but they don't seem to use it anywhere. Instead, they parse the parent project id out of the name passed in with the object. CreateOccurrence used to be the same way, but now the the name field is ignored, I use the parent field.

I think this inconsistency is weird, and could confuse people. Do you think it should be fixed? If so, how? Should any Notes/Operations with parents that don't match the one in the name be rejected by the server?

I can make the fix myself, but I just wanted to make sure this was something that should be addressed

Pagination support

We need pagination support to browse through the data (need arose after importing 18000 CVE:s from Clair).

For postgres: I'm thinking we could use (encrypted) values of the id as page markers by default. This would work for insertion order listings at least. For other sort orders we would probably need to build separate indexes once they are supported land.

For memstore: I'm thinking we could use list index as page markers. This will not be bullet proof as you will get the wrong index if elements are deleted, but I think this is a decent trade off. The memstore should not be used in production.

The gRPC layer seems to have what is needed already.

Removal of attestation and attestation authority from Grafeas API

Problem

Using the latest RI server the schema elements attestationAuthority for Notes and attestation for Occurrences have been removed. Is the change in schema an omission error when the API definition moved to use of Protocol Buffers?

The kind enum also does not list these types as well and if these have been removed is there any information that describes the replacement?

When you look at the Grafeas overview there is a table listing some of the kinds of metadata and ATTESTATION is listed there but I cannot seem to find this kind in the current API. When looking at the previous API defined in Swagger, the kind enum did have an ATTESTATION_AUTHORITY but I could not find ATTESTATION even then and when trying to include these values for the kind in a POST body, the server rejects the request with an error.

Also, I noticed that I needed to include the name in the Occurrence JSON as an Occurrence ID was not generated as had been done previously. The comments in the API also say Output only. The name of the Occurrence in the form "projects/{project_id}/occurrences/{OCCURRENCE_ID}" so has something changed around the Occurrence ID handling as in the server will no longer generate an Occurrence ID?

I'm trying to understand how to properly handle attestations and the PGP signing mechanisms used with attestations.

Thanks, -Craig

Background

When I start the Grafeas server and attempt to post the Note and Occurrence from the Grafeas tutorial the JSON is accepted but I do not see the attestationAuthority or attestation in the response as presumably these elements are not part of the current API definition.

Examples

Using a Note:

% curl -X POST "http://localhost:8080/v1alpha1/projects/image-signing/notes" -d @pgp_note.json
{"name":"projects/image-signing/notes/production","shortDescription":"Production image signer.","longDescription":"Production image signer.","kind":"KIND_UNSPECIFIED","relatedUrl":[],"expirationTime":null,"createTime":null,"updateTime":null}

The pgp_note.json is:

{
  "name": "projects/image-signing/notes/production",
  "shortDescription": "Production image signer.",
  "longDescription": "Production image signer.",
  "attestationAuthority": {
    "hint": {
      "humanReadableName": "production"
    }
  }
}

Using an Occurrence:

% curl -X POST "http://localhost:8080/v1alpha1/projects/image-signing/occurrences" -d @pgp_occurrence.json
{"name":"projects/image-signing/occurrences/GUID1","resourceUrl":"https://gcr.io/hightowerlabs/echod@sha256:aba48d60ba4410ec921f9d2e8169236c57660d121f9430dc9758d754eec8f887","noteName":"projects/image-signing/notes/production","kind":"KIND_UNSPECIFIED","remediation":"","createTime":null,"updateTime":null}

The pgp_occurrence.json is:

{
  "name": "projects/image-signing/occurrences/GUID1",
  "resourceUrl": "https://gcr.io/hightowerlabs/echod@sha256:aba48d60ba4410ec921f9d2e8169236c57660d121f9430dc9758d754eec8f887",
  "noteName": "projects/image-signing/notes/production",
  "attestation": {
    "pgpSignedAttestation": {
       "signature": "LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpzaGEyNTY6YWJhNDhkNjBiYTQ0MTBlYzkyMWY5ZDJlODE2OTIzNmM1NzY2MGQxMjFmOTQzMGRjOTc1OGQ3NTRlZWM4Zjg4Nw0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEJDUEcgdjEuNTYNCg0KaVFKS0JBRUJBZ0EwQlFKYWM2Z3lMUnhVYUdWR2NtOW5VR0ZrSUNoSGFYUklkV0lwSUR4amNtRnBaeTV3WlhKbA0KZWtCdmNtRmpiR1V1WTI5dFBnQUtDUkR5V1drbjZEeGRmbnJpRUFDcEFnYWhPLzF3Ryt5bkZVMWJhZmhva1hrbw0KTUtaUVdpTks1clpwRmRZNGEwdEhiMDBzTGtlSWpGSUN2emRYK3lnVGlkZ1dYclplYXhVSm1ycXN5VG1sK1gwUA0KTFVVR1JqNGh3b1dMWUZSREY3WjJLUXBoazNDV2lpN3JTNUkzT1B1RmZoMjMvUUE4eFZBa2ExbHdQdkRjSHphag0KUE9FUklINzBPaUtqTWZMM2o0Q0RoN1FEUWM2Z0I5Z2p3Ky9tTHNjN3UvNmhBQ3ZUNkZ5UXRrQStJM28rWk5ETA0KYUlEbGRvKzZVVGJBSUd1dHBlbWlTbDl0Y3Z4S1Q4K1A1djZ6cTUrdjgwYU1uaWs4ZlhXZTU3QTZ5UE9MTTFyVA0KRGdOMnVReExiWFJzSkpKNnhmRkg4d2oycklyYSs3dldwQWpEYTFPRXI1Znp1TlNIZEF1aWZ5aTlFZm4zTXRvbQ0Kb2c2a2Y4RzNrYjhUUmFneTdVTnB5QkFFdUttSWhoUlpYM2xoKzNIQXNOcC9mOUNJWVk5NURubW11N0xCV1AwTw0KVUVDTEdUVHpBQ2k5a3pyNmg5b0M5NXhvUjZvbVJrN3pYbTJVRXRzTkQvUHd3dnRDdldTejZTeERtL1JMUVdYcA0KWk4zR0tOWXZpblI1K0wyL1VwQy9YV3hMWHpENm42SldIdGhpSjErTlpYSjdNdWMzSUZrZEsrOE14NTlrc1pCOA0KWU5pOHh3NmtNMFRCVkRFaXJndFY4c2pQV3VRbjRweXgyMFNIWFM2TzIwV3lKbW9zVmE0TVMxMVE0cTlaSUpBTA0KYUl2anZLUHhwaUJLUzY2Wkk4Wk1HQnhiWEkrbWI4M0JONGN1SG1IaFpGUzhCTzlqMDZSRWs4aEozQ1NqRmNPWQ0KMjl0R3l3NzBNSnF4czI2OENRPT0NCj1VNTE1DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==",
       "contentType": "application/vnd.gcr.image.url.v1",
       "pgpKeyId": "E83C5D7E"
    }
  }
}

[Proposal] Adopt the "purl" package URL spec to identify software packages

The initial README contains this section...

---

Resource Urls

Component resource Urls need to be unique per resource as well as immutable. This will mean that the metadata associated with a resourceUrl will always be associated with exactly one component, and what is pointed at should never change. Content addressable resource urls are preferred. In the case with resources that cannot be immutable, a timestamp should be appended.

The following table provides examples one could use as resource urls for several component types:

Component Type	Identifier	Example
Debian	deb://dist(optional):arch:name:version	deb://lucid:i386:acl:2.2.49-2
Docker	https://Namespace/name@sha256:	https://gcr.io/scanning-customer/dockerimage@sha256:244fd47e07d1004f0aed9c156aa09083c82bf8944eceb67c946ff7430510a77b
Generic file	file://sha256::name	file://sha256:244fd47e07d1004f0aed9c156aa09083c82bf8944eceb67c946ff7430510a77b:foo.jar
Maven	gav://group:artifact:version	gav://ant:ant:1.6.5
NPM	npm://package:version	npm://mocha:2.4.5
NuGet	nuget://module:version	nuget://log4net:9.0.1
Python	pip://package:version	pip://raven:5.13.0
RPM	rpm://dist(optional):arch:name:version	rpm://el6:i386:ImageMagick:6.7.2.7-4

---

These examples are great but lack a proper definition and are not always consistent.
Several other tools and APIs use similar but different conventions to identify and locate packages.

To better specify what these URLs are here and elsewhere (including in the https://github.com/nexB/scancode-toolkit and https://aboutcode.org projects and several other projects) I started to put down a draft spec at https://github.com/package-url/purl-spec/blob/042f1088bb17e0762e68b27daad30637ca44de4f/README.rst

It would be great for Grafeas to adopt such a spec too!

This is open for review at package-url/purl-spec#1

PS: The original conversation was started here nexB/scancode-toolkit#805

Database init fails for custom db usernames

Using a configuration with a user called something other than postgres makes grafeas unable to create the database during startup. The reason for this is that the code that created the postgres database did not explicitly specify the database name (connections that does not explicitly specify the database name gets the username as the database name)

CircleCi integration is broken

The status for PRs isn't getting updated, which makes validation difficult. The last PR to trigger was #94

Integration with Helm?

Hi all, are there thoughts for how grafeas and helm would interact? Is a specific helm release of a specific version of a chart a Deployment Kind occurrence? Does helm get its own Kind?

Thanks,

Jonah

Migrate sample server to v1beta1

The current server implementation uses the v1alpha1 which makes it incompatible with kritis reference implementation.
The only conflict in the migration is how to treat the operations API which does not exist in v1beta1.

Avoid using unicode punctuations in schema docs

This is minor but a possible source of inconveniences in the future: see https://github.com/Grafeas/Grafeas/blob/dda9654a580daec8c8ec7e16eed67589e2a80324/v1alpha1/grafeas.json#L1301

Bad URL on api/server/README.md

The link "This is a reference implementation of the Grafeas API Spec" (https://github.com/Grafeas/Grafeas/blob/master/README) is not found. This link can be found on the following document: https://github.com/grafeas/grafeas/blob/master/samples/server/go-server/api/server/README.md

Apologies for not submitting a pull request to fix the issue, I am too unfamiliar with the project, but hope to soon be more familiar :)

Plugins

At the KubeCon BoF there were three hooks discussed to the core metadata DB (Grafeas core),

1. Producers (for each artifact, metadata in different formats, from different toolss/sources)
2. Consumers (Analysis, prioritization, machine learning across metadata/artifact types)
   Tooling to perform analysis across artifacts. Combine queried information to create risk scores. For example image reputation/signing, package importance/network accessible/utilization (e.g. openssl vs tar), history of packages risk (e.g. OpenSSL), CVSS score, runtime information etc.
3. Admission Control (based on authorization, policy etc)

Proposal for 2. Tooling across artifacts/risk assessment to be submitted soon

Kritis

Where is Kritis source code? I'm looking for the policy verification engine.

Remove UNKNOWN type from spec

We don't have any solid use cases for unknown.

Coordination/cross pollination with CVE JSON format

Hi, I'm looking for the person(s) to talk to about coordinating and bouncing ideas around with respect to the JSON data format you are using, and the JSON CVE data format (which I'm largely to blame for =). I can be reached via email at [email protected], I apologize for using the issues to contact you but it wasn't clear from the commits who is best to talk to), thanks.

test issue

to see if some email aliases were set up correctly