Merge pull request #25 from ossillate-inc/ashishbijlani-patch-3

Update README.md

README.md

@@ -233,11 +233,13 @@ Packj is backed by generous grants from [NSF](https://www.sbir.gov/node/2083473)
 <details>
     <summary><h4>Show long answer</h4></summary>
 
- CVEs are accidental programming bugs that create security vulnerabilities (e.g., Log4J, HeartBleed). Attackers need to develop an exploit to trigger such security vulnerabilities (e.g., a crafted TCP/IP packet in case of HeartBleed). Such CVEs can be fixed by patching or upgrading to a newer version of the library (e.g., newer version of Log4J fixes the CVE). In contrast, malware is purposefully bad. Moreover, malware itself is an exploit and cannot be patched or fixed by upgrading to a newer version. For example, [dependency confusion attack](https://packj.dev/go?next=https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) was intentionally malicious; it did not exploit any accidental programming bug in the code. Similarly, an author of popular package sabotaging their own code to [protest](https://packj.dev/go?next=https://en.wikipedia.org/wiki/Peacenotwar) against the war is very much intentional and does not exploit any CVEs. Typo-squatting is another attack vector that bad actors use to propagate malware in popular open-source package registries: it exploits [typos and inexperience of devs](https://packj.dev/go?next=https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090), not accidental programming bugs or CVEs in the code.
+Security vulnerabilities (a.k.a. CVEs) are result of accidental programming bugs (e.g., Log4J, HeartBleed). Typical example is a missing bounds check on user input, which makes the program vulnerable to buffer overflow attacks. Attackers need to develop an exploit to trigger such security vulnerabilities (e.g., a crafted TCP/IP packet in case of HeartBleed or a numerically high input to cause buffer overflow). Such CVEs can be fixed by patching or upgrading to a newer version of the library (e.g., newer version of Log4J fixes the CVE). 
 
-Existing scanners **DO NOT** detect malware or intentionally bad code because they assume that the third-party open-source code is benign. As such, simply scan the source code for open-source dependencies, compile a list of all dependencies being used, and look each <dependency-NAME, dependency-VERSION> up in a database (e.g., NVD) to report if the source code uses vulnerable package versions (e.g., vulnerable version of Log4J, LibSSL version affected by HeartBleed).
+In contrast, malware is purposefully bad. Moreover, malware itself is an exploit and cannot be patched or fixed by upgrading to a newer version. For example, [dependency confusion attack](https://packj.dev/go?next=https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) was intentionally malicious; it did not exploit any accidental programming bug in the code. Similarly, an author of popular package sabotaging their own code to [protest](https://packj.dev/go?next=https://en.wikipedia.org/wiki/Peacenotwar) against the war is very much intentional and does not exploit any CVEs. Typo-squatting is another attack vector that bad actors use to propagate malware in popular open-source package registries: it exploits [typos and inexperience of devs](https://packj.dev/go?next=https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090), not accidental programming bugs or CVEs in the code.
 
-Packj uses static code analysis, dynamic tracing, and metadata analysis. Please read more at [Audit README](https://packj.dev/go?next=https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md#faq)
+Existing scanners **DO NOT** detect malware or intentionally bad code because they assume that the third-party open-source code is benign. As such, these tools simply scan the source code for open-source dependencies, compile a list of all dependencies being used, and look each <dependency-NAME, dependency-VERSION> up in a database (e.g., NVD) to report if the source code uses any vulnerable package versions (e.g., vulnerable version of Log4J, LibSSL version affected by HeartBleed).
+
+Packj uses static code analysis, runtime tracing or dynamic analysis, and metadata checks to audit programmatic behavior of the package. Please read more at [Audit README](https://packj.dev/go?next=https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md#faq)
 </details>
 
 # Customization #