docs: improve targets documentation

    - define target types and refer to them in relevant places
    - use consistent structure for all targets docs (also simplify it)
    - (also update scanner embedding doc)

docs/docs/advanced/container/embed-in-dockerfile.md

@@ -1,28 +1,41 @@
 # Embed in Dockerfile
 
-Scan your image as part of the build process by embedding Trivy in the
-Dockerfile. This approach can be used to update Dockerfiles currently using
-Aqua’s [Microscanner][microscanner].
+You can scan your image as part of the image build process by embedding Trivy in the Dockerfile. 
+When scanning the container contents, use the [rootfs](../../target/rootfs.md) target.
 
-```bash
-$ cat Dockerfile
-FROM alpine:3.7
+Examples:
+
+Using the [Trivy install script](../../../getting-started/installation.md#install-script-official):
+
+```Dockerfile
+FROM ...
+// your build steps
 
 RUN apk add curl \
     && curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin \
     && trivy rootfs --exit-code 1 --no-progress /
+```
 
-$ docker build -t vulnerable-image .
+Using the [Trivy official image](../../../getting-started/installation.md#container-image-official) to avoid insecure `curl | sh`:
+
+```Dockerfile
+FROM ...
+// your build steps
+
+COPY --from=aquasec/trivy:latest /usr/local/bin/trivy /usr/local/bin/trivy
+RUN trivy rootfs --exit-code 1 --no-progress /
 ```
-Alternatively you can use Trivy in a multistage build. Thus avoiding the
-insecure `curl | sh`. Also the image is not changed.
-```bash
-[...]
-# Run vulnerability scan on build image
-FROM build AS vulnscan
+
+Using multi-stage build to separate scanning from the build artifact:
+
+```Dockerfile
+FROM ... as build
+// your build steps
+
+FROM build as vulnscan
 COPY --from=aquasec/trivy:latest /usr/local/bin/trivy /usr/local/bin/trivy
 RUN trivy rootfs --exit-code 1 --no-progress /
-[...]
+
+FROM build
 ```
 
-[microscanner]: https://github.com/aquasecurity/microscanner

docs/docs/coverage/iac/index.md

@@ -1,7 +1,6 @@
 # Infrastructure as Code
 
-## Scanner
-Trivy scans Infrastructure as Code (IaC) files for 
+Trivy scans Infrastructure as Code (IaC) files with the following scanners: 
 
 - [Misconfigurations][misconf]
 - [Secrets][secret]

docs/docs/coverage/language/index.md

@@ -1,20 +1,18 @@
 # Programming Language
 
-Trivy supports programming languages for 
+Trivy scans programming languages packages in the following scanners: 
 
 - [SBOM][sbom]
 - [Vulnerabilities][vuln]
 - [Licenses][license]
 
-## Supported languages
-The files analyzed vary depending on the target.
-This is because Trivy primarily categorizes targets into two groups:
+## Pre/Post Build
+Trivy categorizes targets into either Pre-build and Post-build. The files analyzed vary depending on the target type.   
+Pre-build is meant for scanning code projects, where packages are likely in package manager lock files (e.g `package-lock.json`). Post-build is meant for scanning deployable artifacts (e.g vm, container) where packages are likely "installed" (e.g in `node_modules`) and source code (including lock files) is not available.
 
-- Pre-build
-- Post-build
+## Supported languages
 
-If the target is a pre-build project, like a code repository, Trivy will analyze files used for building, such as lock files.
-On the other hand, when the target is a post-build artifact, like a container image, Trivy will analyze installed package metadata like `.gemspec`, binary files, and so on.
+The following table lists the supported languages and the way Trivy scans each language in each target:
 
 | Language             | File                                                                                       | Image[^4] | Rootfs[^5] | Filesystem[^6] | Repository[^7] |
 |----------------------|--------------------------------------------------------------------------------------------|:---------:|:----------:|:--------------:|:--------------:|

docs/docs/coverage/os/index.md

@@ -1,7 +1,6 @@
 # OS
 
-## Scanner
-Trivy supports operating systems for 
+Trivy scans operating systems packages in the following scanners: 
 
 - [SBOM][sbom]
 - [Vulnerabilities][vuln]

docs/docs/index.md

@@ -4,3 +4,15 @@ Welcome to the Trivy documentation!
 Here you can find complete and thorough information about every aspect of Trivy, how to use it, features available, and configuration options.
 
 👈 Please use the left side navigation browse the different topics.
+
+## Sections
+
+- **Targets**: Targets are the artifacts that you want Trivy to scan. Trivy supports scanning various targets.
+- **Scanners**: Scanners are the engines that Trivy uses to find security issues in targets. Trivy supports multiple scanners.
+- **Coverage**: Listing of the different languages, package managers, and ecosystems that Trivy can scan.
+- **Configuration**: How to configure Trivy to suit your needs.
+- **Supply Chain**: Topics related to supply chain security.
+- **Compliance**: Asses your scan targets got compliance with well-known or custom security guidelines and benchmarks.
+- **Plugins**: Extending Trivy with plugins.
+- **Advances**: Advanced topics related to operating Trivy.
+- **References**: Technical references about Trivy usage.

docs/docs/references/terminology.md

@@ -29,6 +29,10 @@ This page explains the terminology system used in Trivy, helping users understan
 ### Target
 Types of artifacts that Trivy can scan, like container images and filesystem.
 
+### Target type
+Trivy categorizes targets into Pre-build and Post-build targets. The files analyzed during scan vary depending on the target type.  
+Pre-build is meant for scanning code projects, where packages are likely in package manager lock files (e.g `package-lock.json`). Post-build is meant for scanning deployable artifacts (e.g vm, container) where packages are likely "installed" (e.g in `node_modules`) and source code (including lock files) is not available.
+
 ### Scanner
 Trivy's built-in security scanning engines. Trivy has four main scanners: