Deploy the generated website via GitHub Actions

README.md

@@ -1 +1 @@
-Website last update: 2025-01-01 at 00:48:21.
+Website last update: 2025-01-02 at 09:58:34.

cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html

@@ -2617,7 +2617,7 @@ <h2 id="defining-the-attack-surface-of-an-application">Defining the Attack Surfa
 <p>Group each type of attack point into buckets based on risk (external-facing or internal-facing), purpose, implementation, design and technology. Then, count the number of attack points of each type. Next, choose some cases for each type. Finally, focus your review/assessment on those cases.</p>
 <p>With this approach, you don't need to understand every endpoint in order to understand the Attack Surface and the potential risk profile of a system. Instead, you can count the different general type of endpoints and the number of points of each type. This enables you to budget what it will take to assess risk at scale, and you can tell when the risk profile of an application has significantly changed.</p>
 <h3 id="microservice-and-cloud-native-applications">Microservice and Cloud Native Applications<a class="headerlink" href="#microservice-and-cloud-native-applications" title="Permanent link">&para;</a></h3>
-<p>Microservice and Cloud Native applications are comprised of multiple smaller components, loosely coupled using APIs and independently scalable.  When assessing the attack surface for applications of this architectural style, you should prioritize the components that are reachable from an attack source (e.g. external traffic from the Internet).  Such components may be located behind tiers of proxies, load balancers and ingress controllers, and may auto-scale without warning.</p>
+<p>Microservice and Cloud Native applications are comprised of multiple smaller components, loosely coupled using APIs and independently scalable. When assessing the attack surface for applications of this architectural style, you should prioritize the components that are reachable from an attack source (e.g. external traffic from the Internet). Such components may be located behind tiers of proxies, load balancers and ingress controllers, and may auto-scale without warning.</p>
 <p>Open source tooling such as <a href="https://github.com/weaveworks/scope">Scope</a> or <a href="https://github.com/deepfence/ThreatMapper">ThreatMapper</a> assist in visualizing the attack surface.</p>
 <h2 id="identifying-and-mapping-the-attack-surface">Identifying and Mapping the Attack Surface<a class="headerlink" href="#identifying-and-mapping-the-attack-surface" title="Permanent link">&para;</a></h2>
 <p>You can start building a baseline description of the Attack Surface in a picture and notes. Spend a few hours reviewing design and architecture documents from an attacker's perspective. Read through the source code and identify different points of entry/exit:</p>
@@ -2645,7 +2645,7 @@ <h2 id="identifying-and-mapping-the-attack-surface">Identifying and Mapping the
 <li>...Your types</li>
 </ul>
 <p>You also need to identify the valuable data (e.g. confidential, sensitive, regulated) in the application, by interviewing developers and users of the system, and again by reviewing the source code.</p>
-<p>You can also build up a picture of the Attack Surface by scanning the application. For web apps you can use a tool like the <a href="https://www.zaproxy.org/">OWASP ZAP</a> or <a href="http://arachni-scanner.com/">Arachni</a> or <a href="http://code.google.com/p/skipfish/">Skipfish</a> or <a href="http://w3af.sourceforge.net/">w3af</a> or one of the many commercial dynamic testing and vulnerability scanning tools or services to crawl your app and map the parts of the application that are accessible over the web. Some web application firewalls (WAFs) may also be able to export a model of the application's entry points.</p>
+<p>You can also build up a picture of the Attack Surface by scanning the application. For web apps you can use a tool like the <a href="https://www.zaproxy.org/">OWASP ZAP</a> or <a href="http://arachni-scanner.com/">Arachni</a> or <a href="http://code.google.com/p/skipfish/">Skipfish</a> or <a href="https://docs.w3af.org">w3af</a> or one of the many commercial dynamic testing and vulnerability scanning tools or services to crawl your app and map the parts of the application that are accessible over the web. Some web application firewalls (WAFs) may also be able to export a model of the application's entry points.</p>
 <p>Validate and fill in your understanding of the Attack Surface by walking through some of the main use cases in the system: signing up and creating a user profile, logging in, searching for an item, placing an order, changing an order, and so on. Follow the flow of control and data through the system, see how information is validated and where it is stored, what resources are touched and what other systems are involved. There is a recursive relationship between Attack Surface Analysis and <a href="https://owasp.org/www-community/Application_Threat_Modeling">Application Threat Modeling</a>: changes to the Attack Surface should trigger threat modeling, and threat modeling helps you to understand the Attack Surface of the application.</p>
 <p>The Attack Surface model may be rough and incomplete to start, especially if you haven't done any security work on the application before. Fill in the holes as you dig deeper in a security analysis, or as you work more with the application and realize that your understanding of the Attack Surface has improved.</p>
 <h2 id="measuring-and-assessing-the-attack-surface">Measuring and Assessing the Attack Surface<a class="headerlink" href="#measuring-and-assessing-the-attack-surface" title="Permanent link">&para;</a></h2>