update README to reflect recent changes

README.md

@@ -11,6 +11,14 @@ LOG_DIR=/app/logs
 
 The `MEMCACHE_STATE_DIR` is needed to persist some intermediate data in the memcache, `DATA_DIR` is needed for various mcp servers to store intermediate results, and `LOG_DIR` is used to store log files generated by the servers. These can be set in a `.env` file in the `src` directory.
 
+In addition, AI API endpoints and secrets also needs to be configured via [environment variables or Codespace secrets](https://github.com/GitHubSecurityLab/seclab-taskflow-agent?tab=readme-ov-file#configuration). In particular, the environment variables `AI_API_TOKEN` and `AI_API_ENDPOINT` needs to be set to the approach AI API endpoints and credentials. If not set, the default `AI_API_ENDPOINT` is GitHub models:
+
+```
+AI_API_ENDPOINT="https://models.github.ai/inference"
+```
+
+In addition, the `GH_TOKEN` environment variable also needs to be set to allow interaction with the GitHub API, such as fetching content, creating issues etc.
+
 The repo provides a script [`run_seclab_agent.sh`](https://github.com/GitHubSecurityLab/seclab-taskflows/blob/main/src/run_seclab_agent.sh) to run a docker container of the `seclab-taskflow-agent` as outlined [here](https://github.com/GitHubSecurityLab/seclab-taskflow-agent/tree/main?tab=readme-ov-file#deploying-from-docker). Note that this script needs to be run from the `src` directory.
 
 Individual taskflows may need additional setup, please refer to the `README.md` in the relevant subdirectories for further requirements.

src/seclab_taskflows/taskflows/alert_triage_examples/README.md

@@ -15,12 +15,30 @@ This directory contains taskflows for fetching code scanning alerts from a repo
 
 ```
 
-After running the triage workflows, the analysis results are stored in a sqlite3 database called `alert_results.db` in the `ALERT_RESULTS_DIR`.
+The taskflows for triaging Actions alerts are configured to triage rules with the critical severity:
 
-To generate a report and create an issue in the repository, run the corresponding `create_issue_*` taskflows. For example, `js` related issues are created with `create_issue_js_ts.yaml` and `actions` related issues are created with `create_issues_actions.yaml`. When using these taskflows, the `github_official` mcp server is used and an authorization token needs to be set:
+```yaml
+globals: 
+  rule: actions/code-injection/critical
+```
+
+However, there are different versions of these rules with different severity and the taskflows can be used for triaging lower severity versions of these queries. This can be done by overwriting the rule with command line option:
+
+```
+./run_seclab_agent.sh -t seclab_taskflows.taskflows.alert_triage_examples.triage_taskflows.triage_actions_code_injection -g rule=actions/code-injection/high
+```
+
+After running the triage workflows, the analysis results are stored in a sqlite3 database called `alert_results.db` in the `DATA_DIR`.
+
+To generate a report and create an issue in the repository, run the corresponding `create_issue_*` taskflows. For example, `js` related issues are created with `create_issue_js_ts.yaml` and `actions` related issues are created with `create_issues_actions.yaml`. When using these taskflows, the `github_official` mcp server is used and an authorization token needs to be set as the `GITHUB_AUTH_HEADER` token:
 
 ```
 GITHUB_AUTH_HEADER="Bearer <my_token>"
 ```
 
 After creating an issue, additional triaging checks are applied to remove false positives by running the corresponding `review_*` taskflows.
+
+Disclaimers: 
+1. Although these taskflows have already been used to report vulnerabilities to projects, we strongly recommend carefully reviewing all output. 
+2. Note that running the taskflows can result in many tool calls, which can easily consume a large amount of quota. 
+3. The taskflows may create GitHub issues, please be considerate and seek the repo owner’s consent before running them on somebody else’s repo.