Designate Secure namespaces for Rails monolith code
Context
We have begun enforcing namespacing in the monolith code: !51236 (merged)
The guidelines for namespacing specify that we should prefer to use feature categories, and nest namespaces when a feature's complexity requires it
Proposal
- Define in this issue the namespaces that we will use across Secure - both specific feature category namespaces and the namespaces we want to use for shared functionality
- Find a place to document the namespaces, and do so
- Managers: share the documented namespaces with your teams during a weekly meeting
Feature category namespaces
-
dynamic_application_security_testing
:DAST
-
your feature category
:the matching namespace
Shared namespaces
TBD
Architectural Support
- Reminder: 72-hour SLA
- Due Date: FILL_ME_IN
- DRI: FILL_ME_IN
Scope Checklist
-
Does not involve architectural decisions -
Is after-the-fact -
Is not already covered by architecture guidelines/handbook -
Has a broad impact within #secure -
Is a new unit of work -
Is strictly #secure -
Could not come to an agreement (escalation) -
Involves architectural decisions
See the scope scoring table below to interpret the checkboxes above
Scope Scoring Table
Reason | in | opt-in | out |
---|---|---|---|
Does not involve architectural decisions | |||
Is after-the-fact | |||
Is not already covered by architecture guidelines/handbook | |||
Has a broad impact within Secure | |||
Is a new unit of work | |||
Is strictly Secure | |||
Could not come to an agreement (escalation) | ? |
||
Involves architectural decisions |
Reviewed by
🤖
Auto-Summary Discoto Usage
Points
Discussion points are declared by headings, list items, and single lines that start with the text (case-insensitive)
point:
. For example, the following are all valid points:
#### POINT: This is a point
* point: This is a point
+ Point: This is a point
- pOINT: This is a point
point: This is a **point**
Note that any markdown used in the point text will also be propagated into the topic summaries.
Outcomes
Outcomes define the decisions or resolutions of a discussion. Once outcomes are defined, sub-topics and points are collapsed underneath the outcomes.
Outcomes are declared in a similar manner as points:
#### OUTCOME: This is an outcome
* outcome: This is an outcome
+ Outcome: This is an outcome
- oUTCOME: This is an outcome
outcome: This is an outcome
Note that multiple outcomes may be declared for each topic.
Topics
Topics can be stand-alone and contained within an issuable (epic, issue, MR), or can be inline.
Inline topics are defined by creating a new thread (discussion) where the first line of the first comment is a heading that starts with (case-insensitive)
topic:
. For example, the following are all valid topics:
# Topic: Inline discussion topic 1
## TOPIC: **{+A Green, bolded topic+}**
### tOpIc: Another topic
Quick Actions
Action Description /discuss sub-topic TITLE
Create an issue for a sub-topic. Does not work in epics /discuss link ISSUABLE-LINK
Link an issuable as a child of this discussion Discussion-Size Indicators
The relative size of the discussion occurring within a topic and its sub-topics is indicated via braille dots.
More dots means that more points or sub-topics exist within a given topic.
Examples:
- TOPIC
⣿⣿⡆
A large discussion occurred here- TOPIC
⣇
A smaller discussion occurred here
Last updated by this job
TOPIC
⡀
⢀
shared code #300039 (comment 506406843)- Maybe we could nest our shared code under an Application Security namespace - `AppSec`?
🤔 #300039 (comment 506406843)
- Maybe we could nest our shared code under an Application Security namespace - `AppSec`?
TOPIC
⣿⡀
⣾⣿
Proposal 2.0 #300039 (comment 510362957)- nest shared code under `AppSec` namespace #300039 (comment 510362957)
- use the feature categories on our Secure stage page to define feature category namespaces #300039 (comment 510362957)
- nest feature category namespaces under `AppSec` namespace #300039 (comment 510362957)
- Vulnerability Management code goes under `AppSec::Vulnerabilities` #300039 (comment 510362957)
- SAST code goes under `AppSec::Sast` #300039 (comment 510362957)
- DAST code goes under `AppSec::Dast` #300039 (comment 510362957)
- Coverage Fuzzing goes under `AppSec::Fuzzing::Coverage` #300039 (comment 510362957)
- API Fuzzing (which does not have a category on the stage page?
🤔 ) goes under `AppSec::Fuzzing::Api` #300039 (comment 510362957) - shared fuzzing code goes in `AppSec::Fuzzing` #300039 (comment 510362957)
- Secret Detection code goes under `AppSec::SecretDetection` #300039 (comment 510362957)
- License Compliance code goes under `AppSec::LicenseCompliance` #300039 (comment 510362957)
- Dependency Scanning code goes under `AppSec::DependencyScanning` #300039 (comment 510362957)
- rename `Security` namespaces to `AppSec` #300039 (comment 510362957)
- `Vulnerabilities` already exists
🎉 it can be moved under `AppSec` #300039 (comment 510362957) - there are several DAST models and services that can be put in `AppSec::Dast` #300039 (comment 510362957)