# SPDX-FileCopyrightText: 2025 GitHub

# SPDX-License-Identifier: MIT

seclab-taskflow-agent:

filetype: prompt

version: 1

prompt: |

The issues suggested have not been properly verified and are only suggested because they are common issues in these types of

application. Your task is to audit the source code to check if this type of issues is present.

Note that the issues are meant to be suggestions of the risk present in the component and the file paths included are

used as examples and not exhaustive. You should take the general idea of the risk and audit the entire component, going

beyond the files and examples suggested in the issue.

You need to take into account of the intention and threat model of the component in component notes to determine if an issue

is a valid security issue or if it is an intended functionality. You can fetch entry points, web entry points and user actions

to help you determine the intended usage of the component.

For example, the application may be a dashboard frontend that allow user to query various databases, in this case, being able

to query these databases is not considered a security issue or info leak.

Or an application may be an Admin UI intended for an admin user to perform high privilege actions. In this case, the absence of

authentication or bypasses would be a security issue. However, issues that are reachable only after authentication are not

generally considered security issue, unless it has unintended consequences or are XSS, CSRF type issues.

Remember to take intended usage into account. For example, a CLI tool may be capable of high privilege actions, but it may

only be intended to be used by trusted users for local testing etc. and any actions only affects the local environment of the

user. In this case, inputs to the CLI is not in general considered as untrusted input, and being able to perform high privilege

actions with the CLI is generally not a vulnerability.

Do not consider scenarios where authentication is bypassed via stolen credential etc. We only consider situations that are

achievable from within the source code itself.

Keep a record of the audit notes, be sure to include all relevant file path and line number. Just stating an end point, e.g.

`IDOR in user update/delete endpoints (PUT /user/:id)` is not sufficient. I need to have the file and line number.

If you believe there is a vulnerability, then you must include a realistic attack scenario, with details of all the file and line included, and also what an

attacker can gain by exploiting the vulnerability. Only consider the issue a vulnerability if an attacker can gain privilege by

performing an action that is not intended by the component.

Remember, the issues suggested are only speculation and there may not be a vulnerability at all and it is ok to conclude that

there is no security issue.

Likewise, if while auditing these issues, you noticed other inconsistencies that may lead to vulnerabilities according to the

criteria that I set out, then do investigate such issues and include them in the notes.

Before reporting to the user, reflect on the notes and check the attack scenario:

1. Have you included all the file and line number?

2. Have you included a scenario of how the vulnerability can be exploited, including the end point and untrusted input that

may be used?

3. Is this a realistic scenario that does not require stolen credential, misconfiguration etc. that is outside of what can be achieved via source code?

4. In the attack scenario, what privilege can an attacker gain that is not intended by the application?

Remember, if these criteria are not satisfied, it is ok to report that there is no vulnerabilities.

In the end of the audit, collect your notes and store a new AuditResult entry. If the issue satisfies

the criteria for being a vulnerability, then set the `has_vulnerability` field to True when creating the

entry. If there are bugs that are due to incorrect implementation or inconsistencies, and it is not clear

whether it is exploitable or not, but nevertheless the bug should be addressed to harden security, then

set `has_non_security_error` to True but `has_vulnerability` to False. Set both to False if no security

related issues are identified.

IMPORTANT

You must create a new AuditResult entry regardless of whether there is

any vulnerabilities or bugs.