Docs: Added faq.md and modified roadmap.md

Signed-off-by: Nisha K <[email protected]>

Author: Nisha K

README.md

@@ -4,13 +4,11 @@
 
 Tern is an inspection tool to find the metadata of the packages installed in a container image. It runs scripts from the "command library" against the container and collates the information into a Bill of Materials (BOM) report. Tern gives you a deeper understanding of your container's bill of materials so you can make better decisions about your container based infrastructure, integration and deployment strategies.
 
-## Why Tern?
-Tern was created to help developers meet open source compliance requirements for containers. Tools like Docker make it easy to build and distribute containers but keeping track of what is installed in the container is left to dev or devops teams. Knowing your container's Bill of Materials not only helps you meet your open source compliance obligations, but helps you debug integration and build errors and identify vulnerable packages in your running containers easily.
-
 ## Table of Contents
+- [FAQ](/docs/faq.md)
 - [Getting Started](#getting-started)
 - [Project Status](#project-status)
-- [Documentation](#documetation)
+- [Documentation](#documentation)
 - [Contributing](#contributing)
 - [Glossary of Terms](/docs/glossary.md)
 - [Architecture](/docs/architecture.md)
@@ -59,16 +57,7 @@ $ python tests/<test file>.py
 ```
 ## Project Status<a name="project-status"/>
 
-Tern currently has these features:
-* A Cache to store layers with the packages that are installed in those layers
-* A report containing a line-by-line 'walkthrough' of the Dockerfile to say what packages were installed in each line
-* A summary report
-* The complete list of dependencies are retrieved
-
-Current work:
-* Code refactoring
-* Layering of container filesystems one by one
-* Source retrieval
+We try to keep the [project roadmap](./docs/project-roadmap.md) as up to date as possible. We are currently working on Release 0.1.0.
 
 ## Documentation<a name="documentation"/>
 Architecture, function blocks, code descriptions and the project roadmap are located in the docs folder. We also welcome contributions to the documentation. See the [contributing guide](/CONTRIBUTING.md) to find out how to submit changes.

docs/faq.md

@@ -0,0 +1,12 @@
+# FAQ (Work in Progress)
+
+## Why Tern?
+Tern was created to help developers meet open source compliance requirements for containers. Open source software compliance is a hard problem in general but it gets harder with containers due to the ability to reuse diff filesystems. How those filesystems were created is still an ad hoc process. If you happen to have an lwn subscription you can read an article about it [here](https://lwn.net/Articles/752982/).
+
+The first step in meeting open source compliance obligations is knowing your container's Bill of Materials or BoM. This knowledge gives you some added benefits like debugging integration and build errors and identifying vulnerable packages in your running containers.
+
+## Why not filesystem scanning?
+Static analysis is a reasonable approach to find software components and there are tools like [clair](https://github.com/coreos/clair) that create a BoM as part of vulnerability scanning. Some things to consider when using static analysis is the number of false positives that are detected, the time it takes to scan numerous files (some of which may not even be needed for an application to work) and the reliance on data that may not be open sourced. Tern is not meant to be a replacement for static analysis but simply a tool that automates some of the methods that developers and sysadmins use anyway.
+
+## Why Python?
+Python is well suited for easy string formatting which is most of the work that Tern does.

docs/project-roadmap.md

@@ -1,31 +1,19 @@
 # Project Road Map
 
-## Guiding Principles
-
-* Tern is mean to provide guidance for building more compliant containers by
-  * Analyzing an existing container for packages that are installed
-  * Extracting the sources for packages governed by licenses that require sources to be provided
-  * Rebuilding the container using equivalent packages for which the provenance (exact source code) is known
-
-* The output that Tern creates should not be the source of truth for what is installed in the container nor be used without review. This is because the universe of software installation, package creation and management solutions including dependency management solutions is quite large. There are many different methods of discerning the contents of the container and their provenances but none of them are 100% accurate. In the end, only the person building the container knows for sure what it is meant to contain.
-
-* Tern is not meant to be the 'silver bullet' for container compliance. Tern cannot tell you whether the packages installed on your container are 'compliant'.It is not a lawyer and is not meant to replace your compliance and/or legal team. It is only meant to automate some of the tasks that you may have to do yourself in order to meet the legal obligations for the software installed.
-
-## Package information extraction
-
-* Integration with a static analysis tool - Research
-* SPDX document output
-* YAML document output - Phase 3
-* Check container against a ruleset - Backlog
-
-## Source Retrieval
-
-* Implementation of sources tarball retrieval - Phase 4
-* Configuration to point to an external repository for scripts - Backlog
-* Configuration to point to an external database - Research
-
-## Reconstruct a compliant image
-
-* Use configured database of known good binaries - Phase 5
-* Use container labeling for metadata like build number and content digest
-* Use container signing
+## 2018
+The end goal for 2018 is to make the project relevant to real world containers and to make it easy to contribute to it. Milestones for the project can be discussed on the community slack channel or the public forum. See the [contributing guide](../CONTRIBUTING.md) for information on how to join the conversation.
+
+## Release 0.1.0
+- Create isolated environments to operate on without using other dependencies
+- Analyze a container image layer by layer
+- Optimize shell script workload for package managers
+
+## Release 0.2.0
+- Work on raw container images along with Dockerfiles
+- Ability to track true base images (FROM scratch in Dockerfiles)
+- Support for images created from multiple imports
+- Support for ADD, COPY and WORKDIR
+
+## Release 0.3.0
+- Hardening with a variety of Dockerfiles
+- Support for multistage build Dockerfiles