Add registered prompt and gemini md updates for enabling notation usa… #107
Conversation
QuinnDACollins
requested review from
QuanZhang-William,
capachino,
evanotero,
heltonduarte,
pedrour and
shrishabh
as code owners
| * **Example:** A piece of code might use a slightly older, but not yet broken, cryptographic algorithm for a non-sensitive, internal cache key. While technically not "best practice," it may have zero actual security impact. In contrast, using the same algorithm to encrypt user passwords would be a critical finding. You must use your judgment to differentiate between theoretical and actual risk. | ||
| ### 5. Whitelisting Vulnerabilities |
There was a problem hiding this comment.
nit: the accepted term now seems to be "Allowlist"
There was a problem hiding this comment.
+1 - here and the filename below.
GEMINI.md
Outdated
| ### 5. Whitelisting Vulnerabilities | ||
| When a user disagrees with one of your findings, you **MUST** whitelist the disagreed upon vulnerability. | ||
| * **YOU MUST** Use the MCP Prompt `note-adder` to create a new notation in the `security_notes/vuln_whitelist.txt` file with the following format: |
There was a problem hiding this comment.
should we just name this /security:note-adder?
There was a problem hiding this comment.
Also should the tool/prompt just assume the directory is security_notes? would tighten things down a bit, and make the prompt call less error prone, we can enforce/validate the arg in the MCP server to an allowed set of values (e.g. just vuln_allowlist for now)
| * Use the 'WriteFile' tool to write the **entire updated content** back to the file. | ||
| * **If the file does NOT exist (ReadFile returns an error):** | ||
| * First, if the 'security_notes' directory doesn't exist, create it. | ||
| * This is a new note. You MUST ask the user to define a template for this note. |
There was a problem hiding this comment.
Should we be opinionated here and provide a template? Would prefer to not put the burden of the template on the user.
There was a problem hiding this comment.
In context this tool is being used from analysis.toml , where the template is provided already by the command, to the user
| * **Example:** A piece of code might use a slightly older, but not yet broken, cryptographic algorithm for a non-sensitive, internal cache key. While technically not "best practice," it may have zero actual security impact. In contrast, using the same algorithm to encrypt user passwords would be a critical finding. You must use your judgment to differentiate between theoretical and actual risk. | ||
| ### 5. Whitelisting Vulnerabilities |
There was a problem hiding this comment.
+1 - here and the filename below.
commands/security/analyze.toml
Outdated
| * **Action:** If it does not already exist, create a new folder named `.gemini_security` in the user's workspace. | ||
| * **Action:** Create a new file named `SECURITY_ANALYSIS_TODO.md` in `.gemini_security`, and write the initial, high-level objectives from the prompt into it. | ||
| * **Action:** Create a new, empty file named `DRAFT_SECURITY_REPORT.md` in `.gemini_security`. | ||
| * **Action"** Prep yourself using notes files under `security_notes/` |
There was a problem hiding this comment.
Can we re-use .gemini_security folder, or is the idea that user would like to check-in these security notes to github?
There was a problem hiding this comment.
The idea was moreso that the files is easily accessible by the user, harder to access if it's in a hidden directory. On the other hand, a file of vulnerabilities on a repo being pushed to git may not be the wisest... I'll move it to the .gemini_security directory
GEMINI.md
Outdated
| ``` | ||
| * Explicitly ask the user which they would prefer before proceeding. The manual analysis is your default behavior if the user doesn't choose the command. If the user chooses the command, remind them that they must run it on their own. | ||
| * During the security analysis, you **MUST NOT** write, modify, or delete any files unless explicitly instructed by a command (eg. `/security:analyze`). Artifacts created during security analysis should be stored in a `.gemini_security/` directory in the user's workspace. | ||
| * During the security analysis, you **MUST NOT** write, modify, or delete any files unless explicitly instructed by a command (eg. `/security:analyze`). Artifacts created during security analysis should be stored in a `.gemini_security/` directory in the user's workspace, unless explicitly instructed otherwise (ex. `security_notes` folder). |
There was a problem hiding this comment.
No longer using security_notes?
| role: 'user', | ||
| content: { | ||
| type: 'text', | ||
| text: `You are a helpful assistant that helps users maintain notes. Your task is to add a new entry to the notes file at '.gemini_security/${notePath}'. |
There was a problem hiding this comment.
we might want to think about validating the notePath somehow to make sure it's simply just a file (i.e. doesn't contain a directory path). I believe this can be done in MCP prompts.
There was a problem hiding this comment.
Existing prompt language prevents a directory from being used from what I've seen thus far.
4 participants
Add tooling for persistent notations in extension. Current implementation supports vulnerability whitelisting.