Blog post: Generic semantic version processing (September 26)

Proposal

The semantic versioning (SemVer) specification can be considered the de-facto standard for tracking software states during its evolution. Unfortunately, in reality many languages/ecosystems did not adopt the standard as-is; instead we can find many different semantic versioning flavors that are not necessarily compatible with the original SemVer spec which led to the creation of a variety of different semantic versioning schemes.

GitLab provides a dependency scanning (DS) feature that automatically detects vulnerabilities in the dependencies of a software project for a variety of different languages. DS relies on the GitLab security advisory database that is updated on a daily basis providing information about vulnerable packages that is expressed in the package-specific (native) semantic version dialect. GitLab also recently launched a free and open-source GitLab community security advisory database.

At GitLab we use a semi-automated process for advisory generation: we extract advisory data from data-sources such as NVD, generate advisories that adhere to the GitLab advisory format before they are curated and stored in our GitLab security advisory database.

The plethora of different semantic version-schemes in the wild posed a major challenge for the level of automation we could apply in the advisory generation process: the different semantic version dialects prevented us from building generic mechanisms around version matching, version verification (i.e., the process of verifying whether or not versions are available on the package registry), fixed version inference etc.. Moreover, since advisory generation requires us to extract and update advisory data on scale from data-sources with hundreds of thousands vulnerability entries, translating and/or verifying versions by hand is not a viable, scalable solution.

Having a generic method to digest and process a variety of different semantic version dialects was an important building block for automating large parts of the advisory generation process. This led to the development of semver_dialects, a utility that helps processing semantic versions in a generic, language-agnostic manner which has been recently open-sourced (MIT) and published on rubygems.org.

Triage (REQUIRED)

The Inbound Marketing team prioritizes requests that drive results and meet our goals of generating organic traffic and inquiries.

Please note that there is a different process for when you want to announce something via the blog. Please see announcement requests in the handbook and open an announcement request issue instead of a blog post issue.

Generally speaking, engineering blog posts that are tutorials/how-tos or which share how we built or debugged something, are popular with our audience. If your proposed blog post is aligned with our Attributes of a successful blog post guidelines, you can skip straight to your proposal.

If you are pitching something outside of those guidelines, please fill in the below to help us prioritize. You can check out examples of high- and low-performing blog posts to help with your rationale.

This issue fulfills one of these goals:

• Drive traffic to our website
• Convert traffic into leads
• Thought leadership/share expertise
• Build relationships with potential customers
• Drive long-term results (please explain below in your proposal)
• Announcement
  • Link to announcement request issue (required, see https://about.gitlab.com/handbook/marketing/corporate-marketing/#requests-for-announcements)
• Cross-functional support
  • Link to OKR (required if this box is checked)

Checklist

• If you have a specific publish date in mind (please allow 3 weeks' lead time)
  • Include it in the issue title and apply the appropriate marketing milestone (e.g. Mktg: 2021-03-28)
  • Give the issue a due date of a minimum of 2 working days prior
  • If your post is likely to be >2,000 words, give a due date of a minimum of 4 working days prior
• If time sensitive
  • Add ~"Blog: Priority" label and supplied rationale in description
• If wide-spread customer impacting or sensitive, mention @nwoods to give her a heads up ASAP, apply the sensitive label, and check the PR handbook in case you need to open an announcement request instead of a blog post issue
• If the post is about one of GitLab's Technology Partners, including integration partners, mention @dpduncan, apply the Partner Marketing label, and see the blog handbook for more on third-party posts
• If the post is about one of GitLab's customers, mention @FionaOKeeffe, apply the Customer Reference Program label, and see the blog handbook for more on third-party posts
• Indicate if supporting an event or campaign
• Indicate if this post requires additional approval from internal or external parties before publishing (please provide details in a comment)

Production

• Requestor to complete issue template (Triage, Proposal, Roles and Responsibilities, Checklist )
• Issue sent through triage for consideration (pitch, planning/in progress, review, scheduled)
• Issue assigned to requestor to draft blog post and open MR
• MR created and linked to issue - issue is now deprecated in favor of MR and will close once MR is complete

/cc @tstadelhofer @mark.art @tmccaslin