Issues
- 1
Add helm charts to artifacthub
#479 opened by v0lkan - 7
Aegis Safe v0.18.0 appears to be broken
#476 opened by v0lkan - 0
Update documentation about fips compliance
#483 opened by v0lkan - 0
- 0
Test aegis on a kind cluster
#480 opened by v0lkan - 1
add some badges to the readme
#475 opened by v0lkan - 1
Sentinel is getting too crowded with flags; maybe it’s time to introduce subcommands:
#474 opened by v0lkan - 1
Add sentinel the ability to randomly generate key for the "manual insertion" mode. — Sentinel shall require a public key, and encrypt the response with that public key before delivering it (for added security) — the owner of the private key then can decrypt the result — we can also write a helper binary for that
#473 opened by v0lkan - 0
All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.
#472 opened by v0lkan - 0
It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds.
#471 opened by v0lkan - 0
It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.
#470 opened by v0lkan - 0
It is SUGGESTED that static source code analysis occur on every commit or at least daily. \
#469 opened by v0lkan - 0
All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.
#468 opened by v0lkan - 0
The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access.
#467 opened by v0lkan - 0
Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.
#466 opened by v0lkan - 0
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.
#465 opened by v0lkan - 0
The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure.
#464 opened by v0lkan - 0
The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.
#463 opened by v0lkan - 0
At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.
#462 opened by v0lkan - 0
The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled
#461 opened by v0lkan - 0
The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.)
#460 opened by v0lkan - 0
It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals.
#459 opened by v0lkan - 0
The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project.
#458 opened by v0lkan - 0
The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite.
#457 opened by v0lkan - 0
It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result).
#456 opened by v0lkan - 0
- 0
The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md).
#454 opened by v0lkan - 0
- 0
The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days
#452 opened by v0lkan - 0
If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private.
#451 opened by v0lkan - 0
The project MUST publish the process for reporting vulnerabilities on the project site.
#450 opened by v0lkan - 0
The project MUST have a publicly available archive for reports and responses for later searching. (URL required)
#449 opened by v0lkan - 0
The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive).
#448 opened by v0lkan - 0
The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
#447 opened by v0lkan - 0
The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL required) [
#446 opened by v0lkan - 0
The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A.
#445 opened by v0lkan - 0
To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases.
#444 opened by v0lkan - 0
The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project.
#443 opened by v0lkan - 0
The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard).
#442 opened by v0lkan - 0
The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software.
#441 opened by v0lkan - 0
If the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) MUST be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable"\
#440 opened by v0lkan - 0
The project MUST use at least one static analysis tool with rules or approaches to look for common vulnerabilities in the analyzed language or environment, if there is at least one FLOSS tool that can implement this criterion in the selected language. [
#439 opened by v0lkan - 0
The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered.
#438 opened by v0lkan - 0
Hardening mechanisms SHOULD be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities.
#437 opened by v0lkan - 0
The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all.
#436 opened by v0lkan - 0
It is SUGGESTED that in the version control system, each important version tag (a tag that is part of a major release, minor release, or fixes publicly noted vulnerabilities) be cryptographically signed and verifiable as described in signed_releases.
#435 opened by v0lkan - 0
The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public
#434 opened by v0lkan - 0
The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it.
#433 opened by v0lkan - 0
The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replace them without code recompilation.
#432 opened by v0lkan - 0
The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3.
#431 opened by v0lkan