Proposing few more attributes - #138
Conversation
| config: {}, | ||
| }); | ||
| /* eslint-disable */ | ||
| // @ts-ignore |
There was a problem hiding this comment.
Got a type issue that blocks commits without this
|
I start looking at this now. If I drop the ball on reviewing this please @me to get my attention. My initial reaction is that some of the attributes added should already be there. I'm going to have to take a deeper look at the PR and your intentions to understand what I'm missing. I really appreciate you taking the time to contribute and share your use case and needs. We'll figure it out! |
|
So it looks like the primary thing missing is the job.created_at. it seems like the rest is either parent attribute propagation or derived attributes? Am I understanding this PR correctly? There is another PR that is proposing propagating parent attributes that I'd like to separate these concerns. Can we just focus on the missing attributes for this PR? I'd also like to avoid derived attributes like the MS between created and started. I think this should be calculated on the vendor. I know honeycomb enables this. |
Works for me 👍
Sounds like a good approach 👍
Yep, given we agreed on all the rest, the only thing that would be worth doing with this PR would be this. |
|
I guess I can close this PR and open a new one with that change only then. FYI when I try to setup things locally I had to wrestle a bit with ESLint and Typescript. |
|
If you end up figuring out what tripped you up I'd love help getting a contributing doc started! |
The Queued span ended at the first job's started_at without clamping, so clock skew or a null started_at (new Date(null) -> epoch 1970) made end < start and underflowed OpenTelemetry's unsigned-nanosecond duration to ~2^64 ms, corrupting SUM(duration_ms) dashboards. Clamp the end to max(start, started_at), mirroring the existing job-span clamp. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Clamp Queued span end so it never precedes its start
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
![wiz-8537228d09[bot]](https://avatars.githubusercontent.com/u/60490529?s=60&v=4){kind=small}
There was a problem hiding this comment.
Improper Limitation of Pathname to Restricted Directory (Path Traversal) (CWE-22)
More Details
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access.
The risk stems from the application's failure to properly restrict file operations to a limited directory. By manipulating the file path with special characters like "../", an attacker can traverse the file system hierarchy and access arbitrary files or directories.
Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise. It is crucial to validate and sanitize all user input used in file operations to prevent such attacks.
| Attribute | Value |
|---|---|
| Impact |  |
| Likelihood |  |
Remediation
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access. Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise.
To fix this issue, you should validate and sanitize all user input used in file operations to prevent path traversal attacks. This can be achieved by using a secure path resolution library or by implementing strict input validation and sanitization routines. Avoid concatenating user input directly into file paths, and instead, use platform-specific path normalization functions to resolve paths safely.
Code examples
// VULNERABLE CODE - User input is concatenated directly into the file path
const fs = require('fs');
const userInput = "../../../sensitive.txt";
fs.readFile(`/app/files/${userInput}`, (err, data) => {
// ...
});// SECURE CODE - User input is sanitized, and path is resolved securely
const fs = require('fs');
const path = require('path');
const userInput = "../../../sensitive.txt";
const sanitizedPath = path.resolve('/app/files', path.normalize(userInput));
fs.readFile(sanitizedPath, (err, data) => {
// ...
});Additional recommendations
- Use the built-in
pathmodule in Node.js to safely construct file paths. - Implement strict input validation and sanitization routines for all user input used in file operations.
- Follow the principle of least privilege and restrict file operations to a limited directory scope.
- Adhere to security best practices outlined in the OWASP Top 10 and CWE guidelines for handling user input and file operations.
- Consider using a secure path resolution library like
path-sanitizerorsecure-path-resolvefor additional protection against path traversal attacks.
Rule ID: WS-I011-TYPESCRIPT-00001
To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason
If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).
To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate
There was a problem hiding this comment.
Improper Limitation of Pathname to Restricted Directory (Path Traversal) (CWE-22)
More Details
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access.
The risk stems from the application's failure to properly restrict file operations to a limited directory. By manipulating the file path with special characters like "../", an attacker can traverse the file system hierarchy and access arbitrary files or directories.
Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise. It is crucial to validate and sanitize all user input used in file operations to prevent such attacks.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access. Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise.
To fix this issue, you should validate and sanitize all user input used in file operations to prevent path traversal attacks. This can be achieved by using a secure path resolution library or by implementing strict input validation and sanitization routines. Avoid concatenating user input directly into file paths, and instead, use platform-specific path normalization functions to resolve paths safely.
Code examples
// VULNERABLE CODE - User input is concatenated directly into the file path
const fs = require('fs');
const userInput = "../../../sensitive.txt";
fs.readFile(`/app/files/${userInput}`, (err, data) => {
// ...
});// SECURE CODE - User input is sanitized, and path is resolved securely
const fs = require('fs');
const path = require('path');
const userInput = "../../../sensitive.txt";
const sanitizedPath = path.resolve('/app/files', path.normalize(userInput));
fs.readFile(sanitizedPath, (err, data) => {
// ...
});Additional recommendations
- Use the built-in
pathmodule in Node.js to safely construct file paths. - Implement strict input validation and sanitization routines for all user input used in file operations.
- Follow the principle of least privilege and restrict file operations to a limited directory scope.
- Adhere to security best practices outlined in the OWASP Top 10 and CWE guidelines for handling user input and file operations.
- Consider using a secure path resolution library like
path-sanitizerorsecure-path-resolvefor additional protection against path traversal attacks.
Rule ID: WS-I011-TYPESCRIPT-00001
To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason
If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).
To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate
There was a problem hiding this comment.
Improper Limitation of Pathname to Restricted Directory (Path Traversal) (CWE-22)
More Details
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access.
The risk stems from the application's failure to properly restrict file operations to a limited directory. By manipulating the file path with special characters like "../", an attacker can traverse the file system hierarchy and access arbitrary files or directories.
Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise. It is crucial to validate and sanitize all user input used in file operations to prevent such attacks.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access. Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise.
To fix this issue, you should validate and sanitize all user input used in file operations to prevent path traversal attacks. This can be achieved by using a secure path resolution library or by implementing strict input validation and sanitization routines. Avoid concatenating user input directly into file paths, and instead, use platform-specific path normalization functions to resolve paths safely.
Code examples
// VULNERABLE CODE - User input is concatenated directly into the file path
const fs = require('fs');
const userInput = "../../../sensitive.txt";
fs.readFile(`/app/files/${userInput}`, (err, data) => {
// ...
});// SECURE CODE - User input is sanitized, and path is resolved securely
const fs = require('fs');
const path = require('path');
const userInput = "../../../sensitive.txt";
const sanitizedPath = path.resolve('/app/files', path.normalize(userInput));
fs.readFile(sanitizedPath, (err, data) => {
// ...
});Additional recommendations
- Use the built-in
pathmodule in Node.js to safely construct file paths. - Implement strict input validation and sanitization routines for all user input used in file operations.
- Follow the principle of least privilege and restrict file operations to a limited directory scope.
- Adhere to security best practices outlined in the OWASP Top 10 and CWE guidelines for handling user input and file operations.
- Consider using a secure path resolution library like
path-sanitizerorsecure-path-resolvefor additional protection against path traversal attacks.
Rule ID: WS-I011-TYPESCRIPT-00001
To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason
If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).
To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate
There was a problem hiding this comment.
Improper Limitation of Pathname to Restricted Directory (Path Traversal) (CWE-22)
More Details
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access.
The risk stems from the application's failure to properly restrict file operations to a limited directory. By manipulating the file path with special characters like "../", an attacker can traverse the file system hierarchy and access arbitrary files or directories.
Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise. It is crucial to validate and sanitize all user input used in file operations to prevent such attacks.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Path traversal vulnerabilities occur when user-supplied input is used to construct file paths without proper validation or sanitization. This allows an attacker to access files and directories outside the intended scope, potentially exposing sensitive data or enabling unauthorized system access. Successful exploitation of a path traversal vulnerability can lead to data breaches, unauthorized access to system resources, and potentially complete system compromise.
To fix this issue, you should validate and sanitize all user input used in file operations to prevent path traversal attacks. This can be achieved by using a secure path resolution library or by implementing strict input validation and sanitization routines. Avoid concatenating user input directly into file paths, and instead, use platform-specific path normalization functions to resolve paths safely.
Code examples
// VULNERABLE CODE - User input is concatenated directly into the file path
const fs = require('fs');
const userInput = "../../../sensitive.txt";
fs.readFile(`/app/files/${userInput}`, (err, data) => {
// ...
});// SECURE CODE - User input is sanitized, and path is resolved securely
const fs = require('fs');
const path = require('path');
const userInput = "../../../sensitive.txt";
const sanitizedPath = path.resolve('/app/files', path.normalize(userInput));
fs.readFile(sanitizedPath, (err, data) => {
// ...
});Additional recommendations
- Use the built-in
pathmodule in Node.js to safely construct file paths. - Implement strict input validation and sanitization routines for all user input used in file operations.
- Follow the principle of least privilege and restrict file operations to a limited directory scope.
- Adhere to security best practices outlined in the OWASP Top 10 and CWE guidelines for handling user input and file operations.
- Consider using a secure path resolution library like
path-sanitizerorsecure-path-resolvefor additional protection against path traversal attacks.
Rule ID: WS-I011-TYPESCRIPT-00001
To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason
If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).
To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate
3 participants
First of all, thanks for this amazing action.
I'm loving this so much!
We have just added a self-hosted runner on AWS spot instances: https://github.com/philips-labs/terraform-aws-github-runner
We are bounded by the number of vCPUs we can get from AWS so we need data to understand the best configuration, e.g. whether to have few larger instances and get unit test jobs done faster optimising for compute, or have a bigger fleet of smaller instances.
This PR is an initial iteration at it.
We can use the queued_ms attribute to understand how many jobs were waiting for a runner to pick up the work.
We can also use the propagated workflow attributes to get more insights in the whys a particular job or step is executing.
If you are interested in it or a part, let me know and I'll write something that is agreeable on the standards of this repo.