Skip to content

15.9 Planning — Static Analysis

🔒 Secure, Static Analysis - Milestone Planning

This is a planning issue for devopssecure groupstatic analysis, which maintains:

See the group handbook page for more about this issue and how it fits into group workflows.

In this issue:

Narrative

We've delivered great improvements in the past few milestones—from migrating to Semgrep-based scanning for popular languages to developing proprietary language scanning capabilities to solving long-standing issues with MR pipelines.

This milestone, we will:

  • Begin to rebalance our focus toward SAST as a result of specific feedback from customers and our Field organizations.
    • This means putting down some of our longer-term plans for Secret Detection and being disciplined about what we take on in IaC and Code Quality.
  • Prepare for a crucial milestone for our agility in the next year-plus: the ability to make any potentially-breaking changes in 16.0.
    • This means solidifying technical details and otherwise getting ready so that we can provide timely, accurate notices to our users.

Note that we're now beginning a new fiscal year and have OKRs and other targets that we believe will make a difference for our users in the upcoming year. We will share further details of these plans in the upcoming weeks.

Team members can also check the metrics we use to assess Static Analysis. Note that this page will be updated in the next few days with more recent data.

Priorities

Key items to deliver

This section lists items that should be ready to deliver (or at least to move forward). Many of these items should be defined as ~Deliverable items, assuming they are feasible to deliver in the milestone.

Status of this list: Needs input from group members, specifically on typebug and typemaintenance.

Item Why? Area
Solidify 16.0 deprecation plans: 16.0 Static Analysis Deprecations (#356609 - closed) We are required to give 3 milestones' notice for any breaking changes. This means that we need to know what we are targeting so we can accurately describe it to users. All
Enable PAT revocation by default for Self-Managed Automatically revoke GitLab.com PATs discovered... (#371658 - closed) Has been announced and previewed with customers Secret Detection
Finish shipping Automatically resolve vulnerabilities when a SA... (#368284 - closed) Needed to unblock false positive mitigations SAST first, but also others
Following above, ship Disable noisy `detect-object-injection` rule by... (#373920 - closed) Single noisiest rule, often causes problems in customer projects SAST
Complete backend improvements to enable frontend Include SAST findings inline in the MR Changes ... (#384989 - closed) Take advantages of recent great work in CQ and demonstrates One DevSecOps Platform value with SAST. SAST
Dogfood bring-your-own Code Quality for gitlab-... (#385110 - closed) Add additional dogfooding opportunities for report ingestion and UI views. Discover issues before customers do! Code Quality
Complete Update converted SAST analyzers with new rules ... (#373117 - closed) We have converted a number of analyzers and will have removed the deprecated analyzers by default. We should take another pass to be sure coverage has remained up to date. SAST
Update Secret Detection with patterns from partners (&4944), specifically &8835 (team members only) Ensure we are detecting the right things and better protect customers. Secret Detection
Implement an MVC for rule customization within compliance frameworks or Scan Execution Policies (Custom Rulesets for Security Scanning at Group ... (#257928 - closed)) Common challenge. Helps us learn for the future. See meeting notes (team members only). SAST, Secret Detection
Complete other backend work to unblock frontend projects, see below #388565 (comment 1245893173) All
Should add a few more based on in-flight work/escalations

Learn and react: engage with these initiatives, and respond within the milestone by filing issues or implementing if feasible:

Looking forward

This section lists items that are in earlier stages of planning. Refining them is an important part of this milestone because it sets us up to work on them in the following milestones. Primary areas of responsibility are listed, but everyone can contribute!

This is almost certainly more than we can take on. It's generally in priority order (most important at the top).

  1. Development: Identify path forward on the following confidential Secret Detection partner: &8835
  2. Product/UX: Respond to UX Benchmark issue by identifying small changes and larger re-evaluations for SAST configuration. (ux-research#2169 (closed); don't overrotate on specific tasks; see meeting notes (team members only))
  3. Product/UX: Defining SAST profile ideas further (&8332 (closed)).

The work that makes the work work

  1. Process for rule coordination
  2. Definition of how Static Analysis responds to inbound requests during the milestone

Product and UX

This section includes other Product and UX context that may not fit into the Looking forward section above.

Product manager: @connorgilbert

  • Coordinate FedRAMP application changes, infrastructure analysis, product definition, and delivery. This will occupy a significant portion of my time.
  • Move Code Quality forward
    • File Opportunity Canvas (Lite) to align with Product leadership
  • Update direction pages to:
    • Remove metrics not actually used
    • Add FP Reduction to narrative
    • Specify focus on particular types of detection within Secret Detection

UX Designer: @mfangman

  • See planning issue (link: TODO)
  • Prepare SAST profiles and UX Roadmap for broader engagement in the group
  • Work on priorities from UX Roadmap (&8141)

Documentation

This section includes group inputs and the plan for Technical Writing in the milestone.

Technical Writing stable counterpart: @rdickenson

Input on group priorities

Initial thoughts below

From a groupstatic analysis perspective, the following would likely improve customer outcomes:

  1. Discussion/Meta: Identifying how to reduce duplication between similar feature areas. This would help us with maintenance effort, and help customers see the commonalities between feature categories. For example, we have very similar (almost identical) customization options, and similar ways of setting pinned analyzer versions. Could we refactor the common content out, and thereby slim down the feature-category-by-feature-category content to what's truly unique?
  2. Improve approachability of documentation, especially how SAST interacts with other features. (Customers use them all!) Perhaps this would involve creation of a backlog of sections to revisit or update that team members or the wider community could pick up, so the burden is not implicitly all on Technical Writing?
  3. Rework post-processing/revocation documentation for clarity. There is currently a confusing mix of implementation details for Self-Managed admins and revocation partners, and almost nothing for users.

Anticipated release posts and documentation include:

  • Any completed deliverable items from above
  • Monthly analyzer updates
  • Progress on GitLab.com PAT revocation

Planned new content

Pending from @rdickenson

Planned maintenance

Pending from @rdickenson

Quality

This section includes group inputs and the plan for Quality in the milestone.

Quality stable counterpart: @cahamed

Input on group priorities

Team members have been working to identify changes to our rule and analyzer testing. These efforts should inform our proactive Quality efforts this milestone.

Quality plan

Pending from @cahamed

Edited by Russell Dickenson