[DO NOT MERGE] verify Semgrep gate blocks merge queue (private-issues#630)#36143
[DO NOT MERGE] verify Semgrep gate blocks merge queue (private-issues#630)#36143mbiuki wants to merge 9 commits into
Conversation
…sues#630) DO NOT MERGE — temporary fixture proving a red Semgrep fails Finalize / Final Status and blocks merge-queue entry. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @mbiuki's task in 51s —— View job Rollback Safety Analysis
Result: ✅ Safe To RollbackThe diff introduces a single new Java file (
This is a temporary test fixture added purely to trigger Semgrep findings. Rolling back to the previous release leaves no persistent side effects — no schema changes, no data transformations, no index modifications. The label "AI: Safe To Rollback" has been applied. |
🤖 Codex Review —
|
mbiuki
added
OKR : Security & Privacy
![semgrep-code-dotcms-test[bot]](https://avatars.githubusercontent.com/u/1005263?s=60&v=4){kind=small}
|
Semgrep found 1 The method identified is susceptible to injection. The input should be validated and properly If this is a critical or high severity finding, please also link this issue in the #security channel in Slack. |
this is for test and discussion we are having right now to check the change made in the CUSTOM_INJECTION-1 from semgrep from comment mode to block mode to see if this is effective i.e. it is going to blocke this PR from merging
|
|
||
| public ResultSet lookup_1B(final Connection conn, final String userInput) throws SQLException { | ||
| final Statement st = conn.createStatement(); | ||
| return st.executeQuery("SELECT * FROM users WHERE name = '" + userInput + "'"); |
There was a problem hiding this comment.
Semgrep identified an issue, but thinks it may be safe to ignore.
The method identified is susceptible to injection. The input should be validated and properly
escaped.
Why this might be safe to ignore:
This is a deliberate security test fixture meant to trigger Semgrep and block CI, not production code. The SQL is intentionally vulnerable, but fixing it would not improve real application security because the file is temporary and marked do not merge.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by CUSTOM_INJECTION-2.
If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
|
|
||
| public ResultSet lookup_1B(final Connection conn, final String userInput) throws SQLException { | ||
| final Statement st = conn.createStatement(); | ||
| return st.executeQuery("SELECT * FROM users WHERE name = '" + userInput + "'"); |
There was a problem hiding this comment.
Semgrep identified an issue, but thinks it may be safe to ignore.
SQL Injection is a critical vulnerability that can lead to data or system compromise. By
dynamically generating SQL query strings, user input may be able to influence the logic of
the SQL statement. This could lead to an adversary accessing information they should
not have access to, or in some circumstances, being able to execute OS functionality or code.
Replace all dynamically generated SQL queries with parameterized queries. In situations where
dynamic queries must be created, never use direct user input, but instead use a map or
dictionary of valid values and resolve them using a user-supplied key.
For example, some database drivers do not allow parameterized queries for > or < comparison
operators. In these cases, do not use a user supplied > or < value, but rather have the
user
supply a gt or lt value. The alphabetical values are then used to look up the > and <
values to be used in the construction of the dynamic query. The same goes for other queries
where
column or table names are required but cannot be parameterized.
Example using PreparedStatement queries:
// Some userInput
String userInput = "someUserInput";
// Your connection string
String url = "...";
// Get a connection from the DB via the DriverManager
Connection conn = DriverManager.getConnection(url);
// Create a prepared statement
PreparedStatement st = conn.prepareStatement("SELECT name FROM table where name=?");
// Set each parameters value by the index (starting from 1)
st.setString(1, userInput);
// Execute query and get the result set
ResultSet rs = st.executeQuery();
// Iterate over results
while (rs.next()) {
// Get result for this row at the provided column number (starting from 1)
String result = rs.getString(1);
// ...
}
// Close the ResultSet
rs.close();
// Close the PreparedStatement
st.close();
For more information on SQL Injection see OWASP:
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Why this might be safe to ignore:
This is a temporary verification fixture that explicitly says it deliberately contains blocking Semgrep findings and should not be merged. The match is intentional test code for CI gate validation rather than production logic, so fixing it does not improve real application security.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by CUSTOM_INJECTION-1.
If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
|
Semgrep found 1 The method identified is susceptible to injection. The input should be validated and properly If this is a critical or high severity finding, please also link this issue in the #security channel in Slack. |
github-project-automation
Bot
moved this from In Progress
to Done
in dotCMS - Product Planning
2 participants
Temporary draft — do not merge, will be closed and branch deleted.
checking...
End-to-end verification for dotCMS/private-issues#630. Adds a Java file with deliberate blocking Semgrep findings (SQL injection + command injection) to prove that a red Semgrep fails
Finalize / Final Statusand blocks merge-queue entry.Expected:
PR Semgrepjob FAILS →Finalize / Final StatusFAILS. Once observed, this PR is closed and the branch deleted.🤖 Generated with Claude Code
This PR fixes: #36148