We have used both Dependabot and Snyk to detect vulnerabilities in our GitHub hosted code repositories but they only support some (NodeJS, Java, JavaScript, Kotlin and Swift) of the current languages we are working on, so the question here is what kind of tool for such tasks should we consider either for Rust (cargo.toml) or Elixir (mix.exs) languages if there exists one for those.
1/ Dependabot does now support Rust and Elixir.
what I'm looking is something that actually analyzes our GitHub repos either as a whole Organization
2/ Since July 2020
Enable Dependabot, dependency graph, and other security features across your organization
You can now enable or disable the dependency graph, Dependabot alerts, Dependabot security updates, and secret scanning for all repositories in an organization with one click. You can also set whether each feature will be enabled or disabled for newly-created repositories.
Look for the "Security & analysis" tab in your organization settings page and on your user settings page.
In addition, we've consolidated the repository-level settings for dependency graph, Dependabot alerts, Dependabot security updates, and secret scanning to a "Security & analysis" tab in the repository settings page.
Learn more in the docs
Related
I'd like to cross-check the vulnerabilities covered by GitHub's CodeQL service and OWASP Top Ten Web Application Security Risks so that I know where the gaps are.
I can't find a list of vulnerabilities covered by CodeQL. Does GitHub publish the list of rules?
The source code of the CodeQL queries is available in the GitHub repository. The documentation also lists the existing queries:
CodeQL query help
CodeQL CWE coverage
However, which queries (or rather query suites) are run as part of GitHub workflows depends on the configuration of the workflow.
I've been using VS Code for a year or so now. I have no idea how VS Code Extension security is handled.
I'm alarmed by things like this:
Markdown Preview Enhanced (927K+ downloads)
Markdown Preview Enhanced (fork that points to the original repo) (2k+ downloads)
Some questions I have are:
What does Microsoft do to ensure Extensions we install are safe?
Are they scanning the Extensions for known vulns?
Is VS Code safe to use in an Enterprise Environment?
How can I tell?
Why are duplicate extension names allowed!
There are security and marketing implications by Microsoft allowing "package-squatting".
Does anyone have insights to share regarding VS Code Extension Security?
Hm. Unfortunately, the link to "extension marketplace terms" that #jonrsharpe provided does not include the word "extension". If you extrapolate VS Code Extensions to be covered by the Azure Marketplace terms (as alluded to in the text), then you get this little tidbit:
https://azure.microsoft.com/en-us/support/legal/marketplace-terms/
Publisher Privacy Policies. Publishers are responsible for providing
privacy statements that describe their privacy practices with respect
to Customer Data collected by their Offerings or any customer
information that they receive from Microsoft. Unless indicated
otherwise in connection with a Marketplace Offering published by
Microsoft, Microsoft’s privacy, security, and data location and data
retention policies will not apply to any Marketplace Offering or to
Publishers’ use of any Customer Data or other customer information.
In short "...Microsoft's privacy, security...policies will not apply to any..." VS Code Extensions OR to "...Publishers' use of any Customer Data or other customer information."
Microsoft does NOT handle VS Code Extension Security.
Microsoft's documentation on Design Manager mentions steps to import design package & the content it brings in. It also recommends not to deactivate the feature in solution gallery - /_catalogs/solutions/Forms/AllItems.aspx - which may lead to deletion to content types, eventually leading to issues in pages associated with page-layouts.
From branding perspective, It's very common practice that branding evolves over time & development team needs to plan to push newer version of package on existing sites as well. Documentation on upgrade scenarios - Do's & Don't - is missing from MSDN.
Observations:
Every newer version of package imported on site is a separate entity
& same can be found in solution gallery. The features for old
versions remains activated may imply there is no relation between old
& new versions.
Change in site columns, content types reflects at the site level after import of newer version but pages libraries where the content type was already present, doesn't not refresh for new columns, change in column properties. Moreover, any existing artifacts e.g. page-layouts are not refreshed for changes.
Does anyone has in-depth knowledge of how branding package responds to upgrade? What are Microsoft's recommendation on package upgrade & how to ensure artifacts are refreshed? Without upgrade option, design manager becomes pain if we've to push the changes for add, update & delete through Power-Shell or some other mechanism than design manager taking care of it.
I have looked everywhere and I couldn't find any Microsoft best practice regarding upgrading design packages
However I have been re-uploading design packages normally on almost every project I worked on with no issues.
you just need to upload the new package then run a powershell script to publish all content inside your masterpage gallery and style library much like this article:
https://www.rightpoint.com/thought/2015/10/19/publish-everything-in-the-master-page-gallery-with-powershell
Do not deactivate the old package. it shouldn't cause any issues.
Old package files having the same name will be updated and the ones that are not will stay untouched.
background
I've been a religious user for github/zenhub for quite a while. We recently moved our repos to gitlab for many reasons, including free pipelines, security, more flexible groups etc.
Problem
Zenhub is a greasemonkey app that's added to github, one of its features is the scrumboard that's similar to gitlab's native issue board. One of the amazing things about zenhub scrumboard is that it allows you to put many repos on the same board (I recall jira had the same thing).
question
Is there a way to do this on gitlab?
Beside a third-party like kanban.leanlabs.io, recent GitLab releases do integrate a more sophisticated issue management.
See "Announcing The GitLab Issue Board " (presented here)
But it might be limited to only the current repo.
Note that with GitLab 13.6 (November 2020), this is no longer limited to a repository:
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
See Documentation and Epic.
In GitLab issues and merge requests within a group display a collection of issues and merge requests from all projects below them.
And they also have an Issue Board available, which aggregates the issues from the projects within the given group. This is currently not reflected in the documentation, and could be well worth a Pull Request in doc/user/group/index.md and doc/user/project/issue_board.md.
Using this together with group labels and milestones, which also span across all subprojects, you can create the desired board view.
I do use github/zenhub in the past. https://gitboard.co is the zenhub alternative for gitlab. Which shows all your issue and merge request in one simple dashboard across multiple projects.
As I understand it, the TFS Changeset Comments Policy may be set by any permitted user to require all team members to add a comment when making a check-in. Clearly, this must be a setting on the TFS server, rather than a local setting on the machine of the developer who makes the change. Yet my reading on this indicated that a curious notion. Prior to VS2013, this policy was not bundled with Visual Studio; rather it was in the Productivity Power Tools (PPT). Various references all indicate that each member of the team had to have PPT installed in order for the policy to be effective. One source wrote it as "if you don't have the Power Tools installed, you can still override the check-in policy". But if this is indeed a server setting, how would one be able to override it? That's part 1 of my question.
Part 2 of my question is now, with the advent of VS2013 that has the Changeset Comments Policy packaged in, I presume that the policy will just work. But what happens if there are some users running VS2013 and some running VS2012--does the same limitation still exist, i.e. that the VS2012 users with PPT can still override the check-in policy?
In TFS the checkin policies requirement are server side, but the checkin policies them selves are client side. So for users that don't have the checkin policy installed this policy will always be not fulfilled. the Comments policy is no exception. When you don't have the policy available on your computer you will just get a more cryptic failed checkin policy.
This goes for both standard/bundled policies and custom made policies. Note that you can always override failed policies. There is no way to refuse the developers the option of overriding, even for missing policies.
As a side note I can say that tfs power tools has a feature that allows for automatic distribution of checkin policies. But then you of course will have to make sure that all developers have tfpt installed. for TFS/VS2012/13 this feature might be included, but I'm not sure. You can have a look at this blog post if this is relevant
http://blogs.msdn.com/b/youhana/archive/2011/03/27/distributing-custom-check-in-policies-amp-wit-controls-using-team-members.aspx