fix grammar and spelling in user_prompt sections

src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/validate_user_input.yaml

@@ -18,7 +18,7 @@ taskflow:
         ```
         {{ result.result }}
         ```
-        Check that the notes contains a section call "User-Controlled input" or similar.
+        Check that the notes contain a section called "User-Controlled input" or similar.
         If the section is missing, then mark the alert as invalid and update the alert results
         with the reason saying that no user input is found.
       toolboxes:

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/audit_workflow_users.yaml

@@ -17,7 +17,7 @@ taskflow:
       user_prompt: |
         Fetch the file {{ result.user }} from the repo {{ result.repo }}.
 
-        Get the high privileged triggers for the of the workflow in the file {{ result.user }} and check if it is reusable. 
+        Get the high privileged triggers for the workflow in the file {{ result.user }} and check if it is reusable. 
         If it does not contain any high privileged trigger AND it is not a reusable action, then the task is done.
 
         Otherwise, check that the action specified by {{ result.user }} in repo {{ result.repo }} is active.
@@ -34,7 +34,7 @@ taskflow:
         You must mention the fact that {{ result.user }} uses {{ result.action }} in lines {{ result.lines }}
         in the notes.
         You must also include all the permissions granted to the {{ result.user }} action in the notes, and all the triggers of the action.
-        Finally, update the all the alert result that has {{ result.action }} with the results in your notes using `update_all_alert_results_for_flow_graph` with 
+        Finally, update all the alert results that have {{ result.action }} with the results in your notes using `update_all_alert_results_for_flow_graph` with
         your notes as the `results`, {{ result.action }} as the `next` and {{ result.repo }} as the `repo`.
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml

@@ -42,7 +42,7 @@ taskflow:
 
         1. Inspect the workflow file to see if any permission is granted to the action. List all the permissions in your notes
         2. Then check and see if the action is using any secrets.
-           IMPORTANT: Do not consider GITHUB_TOKEN as a secret. Include the name of the all the secrets and their line numbers in the notes.
+           IMPORTANT: Do not consider GITHUB_TOKEN as a secret. Include the name of all the secrets and their line numbers in the notes.
 
 
         Take notes while assessing the alert, including the trigger, permissions, and secrets used by the action.

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/create_issues_actions.yaml

@@ -64,7 +64,7 @@ taskflow:
         - seclab_taskflow_agent.personalities.assistant
       exclude_from_context: true
       user_prompt: |
-        Fetch the all the completed alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the completed alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -180,6 +180,6 @@ taskflow:
         - seclab_taskflow_agent.personalities.assistant
       exclude_from_context: true
       user_prompt: |
-        Fetch the all the invalid alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the invalid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml

@@ -55,7 +55,7 @@ taskflow:
         {% include 'seclab_taskflows.prompts.triage_taskflows.actions_common.check_dismiss_reason' %}
 
         IMPORTANT:
-        1. If the dismissal reason does not apply the issue, then you must not dismiss the alert. In particular,
+        1. If the dismissal reason does not apply to the issue, then you must not dismiss the alert. In particular,
         DO NOT try to reason about code injection sanitizer beyond the dismissal reason. 
 
         2. A security check has to restrict the permission or privilege of the user, simple checks that 

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml

@@ -137,7 +137,7 @@ taskflow:
           echo "The issue title is: ${{ env.ISSUE_TITLE }}"
         ```
         IMPORTANT:
-        However, if envoirnment variables are not set in the `env` section, but are set in the `run` section, then it is vulnerable to code injection:
+        However, if environment variables are not set in the `env` section, but are set in the `run` section, then it is vulnerable to code injection:
         ```
         run: |
           echo "TITLE=${{ github.event.issue.title }}" >> $GITHUB_ENV
@@ -200,13 +200,13 @@ taskflow:
         only consider whether the code at the alert location {{ result.location }} is affected by a sanitizer or a check that takes 
         place before the code injection vulnerability at {{ result.location }}.
 
-        If the sanitizer is still valid include update the alert results with these information using the alert_id {{ result.alert_id }} and repo {{ result.repo }} in the 
-        `update_alert_result` tool with your notes as the `result`. Remember to include the line numbers of the checks or sanitizers in the notes.
+        If the sanitizer is still valid, update the alert results with this information using the alert_id {{ result.alert_id }} and repo {{ result.repo }} in the
+        `update_alert_result` tool with your notes as the `result`. Remember to include the line numbers of the checks or sanitizers in the notes,
         and then set the `valid` field of the alert result to `false` using alert_id {{ result.alert_id }} and repo {{ result.repo }}.
 
         IMPORTANT:
-        You must only based your decision on the present of sanitizer and check and not any other factors. And do not include 
-        comment on any other factors that may affect the code injection vulnerability.
+        You must only base your decision on the presence of sanitizers and checks and not any other factors. And do not include
+        comments on any other factors that may affect the code injection vulnerability.
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer
         - seclab_taskflows.toolboxes.report_alert_state
@@ -218,7 +218,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -249,7 +249,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the all the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -259,7 +259,7 @@ taskflow:
         Review the information gathered from the audit notes to determine whether this alert is a FP.
       inputs:
         vuln_specifics: |
-          DO NOT look for sanitizers of user input beyond those mentioned in the notes. If the notes does not 
+          DO NOT look for sanitizers of user input beyond those mentioned in the notes. If the notes do not
           mention any sanitizers used on the user input, then assume that the user input is not sanitized, even if
           you think the code is safe from code injection.
   - task:
@@ -269,7 +269,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -309,5 +309,5 @@ taskflow:
       uses: seclab_taskflows.taskflows.alert_triage_examples.triage_taskflows.actions_common.check_report
       inputs:
         vuln_specifics: |
-          You decision must be based only on the criteria above, and not any other factors. 
+          Your decision must be based only on the criteria above, and not any other factors.
           DO NOT mark the alert as invalid if you think the code is safe from code injection.

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_client_side_xss.yaml

@@ -53,8 +53,8 @@ taskflow:
         Exploitable means that a remote attacker would be able to inject a malicious script into the web application that would be executed in the context of a user visiting the page.
         This could include a `javascript:` URL, a `<script>` tag, or any other way to inject JavaScript code into the page.
         It also means that the XSS vulnerability is not mitigated by any other code in the repository, such as sanitization or validation of the input.
-        Check if the code tries to sanitize or validate the input. F.ex. if the output is encoded before being sent back. Or if a Regex is used to validate the input.
-        Also check if the Regex only let's true a subset of the provided input.
+        Check if the code tries to sanitize or validate the input. For example, if the output is encoded before being sent back. Or if a Regex is used to validate the input.
+        Also check if the Regex only lets through a subset of the provided input.
         Take note of relevant regex patterns.
         Analyze all Regex patterns used in the code to see if they are effective against cross-site scripting (XSS) attacks. Let's think step by step and explain how the Regex works.
         If you encounter methods used for validation or sanitization, look them up and check if they are effective against cross-site scripting (XSS) attacks.
@@ -75,7 +75,7 @@ taskflow:
 
         If the vulnerable code sink is part of code that retrieves messages from WebSockets e.g. inside `onMessage`,
         the XSS-vulnerability is likely not exploitable as the attacker would need to be able to send a message to the WebSocket
-        (this might be possible if the WebSocket would be used as some sort of chat notifcation system between users).
+        (this might be possible if the WebSocket would be used as some sort of chat notification system between users).
         Take notes while assessing the alert.
         If prompt token count exceeds the given limit note this in the result and mark the task as complete.
         Update the results field of the alert result with your notes using `update_alert_result` with 
@@ -92,7 +92,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -122,7 +122,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -140,7 +140,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_path_injection.yaml

@@ -26,7 +26,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the alert results that has the rule `js/path-injection`.
+        Fetch the alert results that have the rule `js/path-injection`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -69,7 +69,7 @@ taskflow:
       async: true
       user_prompt: |
         Check all results whether they contain next steps that need to be taken. If they do, then take those steps.
-        In case code parts (such as methods) were not found previosuly, look them up and change the notes accordingly.
+        In case code parts (such as methods) were not found previously, look them up and change the notes accordingly.
         Update the results field of the alert result with your notes using `update_alert_result` using the updated notes. 
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_untrusted_checkout_critical.yaml

@@ -30,7 +30,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the alert results that has the rule `{{ globals.rule }}`.
+        Fetch the alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -45,7 +45,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -99,7 +99,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -130,7 +130,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the all the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -157,7 +157,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:

src/seclab_taskflows/taskflows/audit/acl_check.yaml

@@ -20,23 +20,23 @@ taskflow:
         Fetch the list of issues for component {{ globals.id }} in repo {{ globals.repo }}. Check if there is any issue 
         that involves access control or authentication. If there isn't any, then your task is finished.
 
-        If there are any authentication or access control that are crucial in determining whether issue is vulnerable or not,
-        then go through these measures and look carefully to see if there is any way to bypass these checks. Also look for 
-        inconsistencies in access controls. The goal of this task is to scrutinize the access control, authentication
-        relevent to the issue. You should limit your audit to those that are involved in the in issue. 
+        If there are any authentication or access controls that are crucial in determining whether the issue is vulnerable or not,
+        then go through these measures and look carefully to see if there is any way to bypass these checks. Also look for
+        inconsistencies in access controls. The goal of this task is to scrutinize the access control and authentication
+        relevant to the issue. You should limit your audit to those that are involved in the issue. 
 
-        Look at the authentication and access control mechanism used in this component. Note that the implementation of 
-        the authentication and access control may well be defined outside of this component. In which case, you need to 
-        look at files in the repo outside of the component. For each end point, take note of 
-        its intended functionality and any access control/authetnication that is applied. When looking at access control,
+        Look at the authentication and access control mechanisms used in this component. Note that the implementation of
+        the authentication and access control may well be defined outside of this component. In which case, you need to
+        look at files in the repo outside of the component. For each endpoint, take note of
+        its intended functionality and any access control/authentication that is applied. When looking at access control,
         do not just check if access control is applied, but note down the exact role/authority that is required.
 
-        Go through the list of access control and authentication that you made earlier, and consider the followings:
-        - Look through end points functionalities and identify those that should require similar level of privilege. For example, 
-        endpoint that modifies data should require similar privilege to endpoints that write to data, but endpoints that only 
-        read data allows lower privilege. Within the group of endpoint, do access control ensure that they have the same privilege?
-        Or do some endpoint required higher privilege than others? Take a note of such inconsistencies stating clearly 
-        which endpoints should require similar privilege but doesn't. Then decide whether it is 
+        Go through the list of access control and authentication that you made earlier, and consider the following:
+        - Look through endpoint functionalities and identify those that should require similar levels of privilege. For example,
+        endpoints that modify data should require similar privilege to endpoints that write to data, but endpoints that only
+        read data allow lower privilege. Within the group of endpoints, does access control ensure that they have the same privilege?
+        Or do some endpoints require higher privilege than others? Take note of such inconsistencies stating clearly
+        which endpoints should require similar privilege but don't. Then decide whether it is
         a security issue or not.
 
         - Are there other ways to bypass ownership/access control checks via IDOR etc.?