shieldworks aegis issues

shieldworks / aegis

Aegis: Keep Your Secrets… Secret

https://vsecm.com

MIT License

31 stars 3 forks source link

issues

Newest

Newest Most commented Recently updated Oldest Least commented Least recently updated

Feature/bump

#489 v0lkan closed 1 year ago
0
Live Long and Prosper, Aegis 🖖

#488 v0lkan opened 1 year ago
0
479: Adding README.md file on aegis helm-chart release process

#487 abhishek44sharma closed 1 year ago
0
479: Adding README.md file on aegis helm-chart release process

#486 abhishek44sharma closed 1 year ago
0
#302: Introducing initial helm chart for aegis

#485 abhishek44sharma closed 1 year ago
1
Abhishek44sharma/aegis helm chart

#484 abhishek44sharma closed 1 year ago
0
Update documentation about fips compliance

#483 v0lkan opened 1 year ago
0
a command line utility to do replacements on any file talking to Aegis Safe

#482 v0lkan opened 1 year ago
0
v0.18.1 — version bump

#481 v0lkan closed 1 year ago
0
Test aegis on a kind cluster

#480 v0lkan opened 1 year ago
0
Add helm charts to artifacthub

#479 v0lkan closed 1 year ago
1
#476: Fixing aegis-safe restart issue

#478 abhishek44sharma closed 1 year ago
0
Fixing spire-server restarting, due to missing CRD(ClusterStaticEntry)

#477 abhishek44sharma closed 1 year ago
0
Aegis Safe v0.18.0 appears to be broken

#476 v0lkan closed 1 year ago
7
add some badges to the readme

#475 v0lkan opened 1 year ago
1
Sentinel is getting too crowded with flags; maybe it’s time to introduce subcommands:

#474 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
1
All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.

#472 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
It is SUGGESTED that static source code analysis occur on every commit or at least daily. \

#469 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.

#466 v0lkan opened 1 year ago
0
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.

#465 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.)

#460 v0lkan opened 1 year ago
0
It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals.

#459 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
A test suite SHOULD be invocable in a standard way for that language.

#455 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
The project SHOULD be buildable using only FLOSS tools.

#453 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private.

#451 v0lkan opened 1 year ago
0
The project MUST publish the process for reporting vulnerabilities on the project site.

#450 v0lkan opened 1 year ago
0
The project MUST have a publicly available archive for reports and responses for later searching. (URL required)

#449 v0lkan opened 1 year ago
0
The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive).

#448 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0
The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project.

#443 v0lkan opened 1 year ago
0
The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard).

#442 v0lkan opened 1 year ago
0
The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software.

#441 v0lkan opened 1 year ago
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 v0lkan opened 1 year ago
0