Skip to content

Commit aae4648

Browse files
authored
Minor Spelling Changes
Minor Spelling Changes
2 parents 41baf98 + bc00da7 commit aae4648

File tree

3 files changed

+4
-4
lines changed

3 files changed

+4
-4
lines changed

old-versions/V0.1/00a-Overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -96,7 +96,7 @@ it checks the software behavior under unexpected conditions and inputs.
9696

9797
3. **Interactive analysis**
9898

99-
Also known as Interactive Application Security Testig (IAST) monitors the application while other systems interact with it and observe vulnerabilities. This is achieved via sensors or agents deploy with the application. The sensors can see the entire flow from HTTP request down to the executed code, tracing the data through the application. Similar to static analysis, it can test one component at a time, but not multiple components. However, if agents/sensors are deployed on all components, when they interact with eachother this could reveal vulnerabilities in each component used in the application. (Eg. for a microservice architecture, only the microservices that have agents/sensors attached will report vulnerabilities)
99+
Also known as Interactive Application Security Testing (IAST) monitors the application while other systems interact with it and observe vulnerabilities. This is achieved via sensors or agents deploy with the application. The sensors can see the entire flow from HTTP request down to the executed code, tracing the data through the application. Similar to static analysis, it can test one component at a time, but not multiple components. However, if agents/sensors are deployed on all components, when they interact with eachother this could reveal vulnerabilities in each component used in the application. (Eg. for a microservice architecture, only the microservices that have agents/sensors attached will report vulnerabilities)
100100
![Interactive analysis](/document/assets/images/iast_analysis.png)
101101

102102
---

old-versions/V0.1/01b-Linting-Code.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ Advanced static analysis tools typically deliver:
2828
- Out-of-the-box certification for use in the development of safety-critical applications.
2929

3030
### Issues with Linters
31-
+ Not every language has "quality" standard linter tools available, each framwork usually has one or several linters.
31+
+ Not every language has "quality" standard linter tools available, each framework usually has one or several linters.
3232
+ Different versions or configurations can lead to different results.
3333
+ Since some linters are very verbose and information overload can lead to focusing on "unimportant" issues.
3434

@@ -40,4 +40,4 @@ You can perform it in the **pre-commit** phase, so locally before actually commi
4040

4141
### References
4242

43-
+ [Preforce](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important)
43+
+ [Preforce](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important)

old-versions/V0.1/02f-Container-Vulnerability-Scanning.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ As containers become an almost ubiquitous method of packaging and deploying appl
1717
### Where and When to use Container Scanner?
1818
<img align="center" src="/document/assets/images/Dev-process.png">
1919

20-
You can use it at the build phase when you're actually building for instance a Dockerfile and looking at the resulting image that you're creating. Another location to perform container scanning would be when you push a container to the registry or when you pull a container from a registry. However, a good approach is scanning before pushing into a trusted container registry then you can say we have a container registry with a scanned version of all images and for deploying in production you can pull from this trusted container registry. (Plase take look into the following image)
20+
You can use it at the build phase when you're actually building for instance a Dockerfile and looking at the resulting image that you're creating. Another location to perform container scanning would be when you push a container to the registry or when you pull a container from a registry. However, a good approach is scanning before pushing into a trusted container registry then you can say we have a container registry with a scanned version of all images and for deploying in production you can pull from this trusted container registry. (Please take look into the following image)
2121

2222
<img align="center" src="/document/assets/images/container-security-pipeline.png">
2323

0 commit comments

Comments
 (0)