Added keyword 3 times in body (#7089)

articles/linux-vulnerability-detection-with-oval-and-fleet.md

@@ -2,7 +2,7 @@
 
 ![Linux vulnerability detection with OVAL and Fleet](../website/assets/images/articles/linux-vulnerability-detection-with-oval-and-fleet-1600x900@2x.jpg)
 
-Basically, vulnerability detection is just checking for particular vulnerable states on a system. For example, if a host has FooBar 2.0.1 or earlier installed and the contents of `/ect/foobar.config matches isSecure=false`, then we can say the host is susceptible to CVE-1 and CVE-2. If we had a dataset matching known vulnerabilities to declarative statements about the system state, we could use the data collected from osquery to perform vulnerability assessment and enter OVAL®.
+Basically, vulnerability detection is just checking for particular vulnerable states on a system. For example, if a host has FooBar 2.0.1 or earlier installed and the contents of `/ect/foobar.config matches isSecure=false`, then we can say the host is susceptible to CVE-1 and CVE-2. If we had a dataset matching known vulnerabilities to declarative statements about the system state, we could use the data collected from osquery to perform linux vulnerability assessment and enter OVAL®.
 
 Open Vulnerability and Assessment Language (OVAL) is an international information security community standard to promote open security content and to standardize the transfer of this information across the entire spectrum of security tools and services. You can read more about it on OVAL's site. The main thing to know is that the OVAL standard provides a way to define the system state in a structured manner. We refer to this structured artifact as an OVAL definition.
 
@@ -10,7 +10,7 @@ OVAL expresses definitions using the XML format. Definitions sit at the top of t
 
 OVAL tests can target a wide range of system states, from network interface configuration to contents of files. But since we’re focusing on vulnerabilities related to the software inventory of a host, we only need to parse and evaluate a subset of those tests. Each software inventory test is defined as an assertion about a software object, like a package name, and one or more assertions about that object state, which are mostly related to the software version. To keep things simple, we’ll say that software tests are written in terms of names and versions.
 
-The availability of OVAL definitions varies depending on the target OS. Still, looking at the official OVAL repository, we can see that the security teams of Canonical and RedHat provide and maintain OVAL definitions for many of their releases. They parse and process these definitions to let us perform vulnerability detection on any Ubuntu or RedHat-based distros. 
+The availability of OVAL definitions varies depending on the target OS. Still, looking at the official OVAL repository, we can see that the security teams of Canonical and RedHat provide and maintain OVAL definitions for many of their releases. They parse and process these definitions to let us perform linux vulnerability detection on any Ubuntu or RedHat-based distros. 
 
 We’ll go into more detail about how we use OVAL for detecting software vulnerabilities on the most popular distros (Ubuntu, CentOS, Fedora, and RedHat). But first, let’s look at the vulnerability detection pipeline from a bird’s-eye view.
 
@@ -47,7 +47,7 @@ When the Fleet server downloads the OVAL definitions in a previous run, we need
 
 Depending on the target OS platform, the OVAL standard defines different elements. In the context of software inventory tests for RHEL-based systems, we have the `therpminfo_test` element. For Debian-based systems, we have the `dpkginfo_test` element.
 
-As we said earlier, all software inventory tests are defined in terms of names and versions. So, it makes sense to standardize the different variations into some common data structure. Since we expect the vulnerability detection process to run multiple times per day, one of the goals when designing all this was to make the whole process as lightweight as possible. That’s why we decided to parse the XML OVAL definitions into a lighter format. 
+As we said earlier, all software inventory tests are defined in terms of names and versions. So, it makes sense to standardize the different variations into some common data structure. Since we expect the linux vulnerability detection process to run multiple times per day, one of the goals when designing all this was to make the whole process as lightweight as possible. That’s why we decided to parse the XML OVAL definitions into a lighter format. 
 
 We also need to make sure that any produced artifacts can be easily introspected by anyone, so we decided to output the parsed XML files as JSON. Here’s a table comparing the original file size of the OVAL definitions to the produced JSON artifacts at the time of this writing.