 Hi, I'm Fabio, Product Manager at GitHub. In this video, we'll go through the vision for the secure stage and the roadmap for the next releases. Let's start with a brief overview of the stage and which is the vision for the next year. GitHub covers all the stages in the DevOps life cycle, all the stages from plant to monitor, all the stages in one single application. GitHub also includes a secure stage. The secure stage makes applications built and applied with GitHub more secure by checking for vulnerabilities during the entire development life cycle. The main goal of the secure stage is to make security easy and accessible to anyone. Security tools are often hard to set up and manage, or sometimes people just don't focus on security because it's not their top priority until it's too late. Security automatically integrated in any pipeline with no configuration helps to onboard people and to show which is the potential of this area. The features provide support for decision makers. They don't replace them. Users have their final call on triaging vulnerabilities and taking action to remediate them. Security is not a black and white thing and it may highly depend case by case. Provided feedback is actionable. Developers can look at the high-level security status of their projects and then drill down into specific vulnerabilities. They can start remediation processes and follow the complete flow until a fix is deployed. All in one single interface, all in one single application, collaboration between different departments is easier with GitHub. Features are designed for both developers and security professionals. Even if they use different views and flows, they work on the same data and there is a single source of truth. No matter which is your role, GitHub will give you what you need. In 2019, the secure stage is focusing on the following product categories. Categories are organized into groups. We also have other top-level features that are cross-category but deserve to be mentioned as critical components of our vision. Cross-category is a static application of security testing. It checks the source code to verify that it has no well-known vulnerabilities. For example, coding errors like buffer overflows and insecure function calls are detected by this type of test. Our goal is to increase the list of supported programming languages to make the experience even better. Developers might unintentionally commit credentials and passwords to their repositories. In some cases, this means that their values will be publicly accessible to anyone. Secret detection aims to spot this data. For example, authorization keys to access their production environment. After the detection, users can be aware of the problem and revoke liquor credentials. Our goal is to introduce support for this new category and integrate results in existing security reports. Modern applications include public libraries very often. Dependency scanning, part of software composition analysis, checks security advisories for third-party dependencies and packages, reporting if they contain known vulnerabilities. This helps developers to upgrade them to newer versions that fix the flows. Our goal is to add more package managers to the supported list and to shift left these checks even more, even before code is committed to the repository. The second category of software composition analysis is license management. Even if not strictly related to security, it deals with third-party components that may introduce compliance problems. Defining policies for approved and blacklisted licenses is critical to ensure that the final application can be released to the public. Our goal is to make very easy for project and group owners to define policies so developers know in advance if their changes can be accepted or not. Once the application has been applied, Gillab can perform an application test that emulates a real attack. Dynamic application security testing can target applications written in any language. To get earlier results, Gillab can target review apps and provide feedback in the merge request widget even before code is approved and merged into the master branch. Our goal is to support multiple approaches for dynamic application security testing, like quick scans to fit in pipelines where time is a critical aspect. Interactive application security testing is an advanced technique that mixes dynamic attacks and runtime inspection to get more information about possible vulnerabilities triggered by remote requests. While the dynamic scan is running, a local agent monitors the application behavior spotting unexpected errors and flows that could be leveraged by attackers to get access to sensitive data. Our goal is to develop the technology needed to provide this feedback and to cover the main programming languages. Fuzzing is another new product category that we want to start in 2019. It consists in creating a huge amount of arbitrary random payloads and to send them to the running application. As opposed to standard dynamic analysis, fuzzing can test the app behavior with unexpected inputs. Our goal is to enable fuzzing as an additional advanced type of dynamic scan that users can leverage for specific sessions that don't have time-sensitive constraints. Container scanning scans Docker images for well-known secure components that may be part of the base image used to wrap the application. Even if the app code doesn't contain any security flow, vulnerabilities in the deployed container make the entire environment insecure and exposed to attacks. Our goal is to improve the information available to developers and to deeply integrate container scanning in the built-in GitHub container registry. Auto remediation is a cross-category feature that aims to provide an automated solution to remediate security vulnerabilities. GitHub will automatically check, detect, fix, deploy, and monitor the new version of the app, notifying users about the process and in case monolactions are needed. Our goal is to ensure that the flow can be fully automated and that the highest amount of vulnerabilities can be addressed by this flow. The security dashboard is the primary tool for security directors and engineers to monitor and start remediating security vulnerabilities. It gives a high-level view of the security status of a group, allowing drill-down capabilities and statistical data to track how the security process is performing. Our goal is to provide more insight to better understand performances of the security process at the instance level and support to first-class management of vulnerabilities from detection to solution. You can find more details and additional information in the product category page of the GitHub Handbook. Everyone can contribute with comments and proposals in topics and issues where these categories are discussed. Anything else? Please welcome the Defend stage. Defend is a brand-new DevOps stage that along with Secure completes the security coverage of the development lifecycle. It focuses on the Ops side, protecting the applied applications and crowd environments. Even after the app has been deployed, it should be constantly monitored to prevent and detect real attacks. Security teams should be warned of potential threats so they can mitigate effects and minimize the impact. Now it's time to see what will be released in the next versions of Gillette. The planning is always subject to changes and you can check the direction page to be up-to-date with the latest decisions. Gillette 11.9, that will be released on March 22nd, will include many interesting features. It will be possible to detect secrets unintentionally committed to the repository and to see results as part of the SEST report. This is the very first MVC for secret detection. Auto remediation will reach a major milestone with the ability to create a merge request that fixes a given vulnerability, making the entire remediation flow available in the Gillette UI. SEST will be able to analyze multimodal Maven projects that are currently unsupported. This release will also include container scanning improvements. First of all, results will be available in the group security dashboard along with SEST and the panacea scanning. We will increase details of container scanning vulnerabilities, making it easier to identify the problem and to fix it. Starting with this release, pipeline job definitions will be available officially as include templates for all the security features. They should be used when adding security jobs to pipelines so they can be upgraded automatically when a new version is released. On April 22nd, Gillette 11.10 will be released. It will contain the first iteration of runtime application security, one of the categories of the brand new defense stage. The web application firewall included in the Ingex controller for Kubernetes will provide the first layer of protection against external attacks to deployed applications. This release will also include the first iteration of the integration between container scanning and the Gillette container registry. Users will be able to check security status from the registry page when available. We will add desk vulnerabilities to the group security dashboard. This is the last missing piece to make the security findings available to security engineers. SEST will be also improved with the addition of a new analyzer for projects using the TypeScript language. It will be automatically available to everyone that already has SEST capabilities enabled for their projects without any specific change. Last release before the new major version is Gillette 11.11 that will be available on May 22nd. The first improvement is for dynamic application security testing. We want to make active scans available so users may have more accurate results on environments where this kind of attack is not impacting stability of a production environment. On the same topic, we also want to introduce dynamic scans on the master branch for auto devops. This could be risky since it may impact the production environment. So we'll ensure that the behavior is not bringing the main site down. The security dashboard targeting security directors and engineers will be available at the instance level. Users will be able to monitor any project and group in their Gillette instance. And it will be easier to keep everything under control. It will also be possible to forbid merging a change that is introducing a new license that has been already blacklisted in the project. This will prevent accidental mergers that would break compliance, creating possible legal and management problems for the app. In this release, we'll add a second iteration for secret detection. Users will be able to test the entire history of their repositories instead of just the last version available. This could be useful in some cases, even if it may take a lot of time to complete. This option will be available as an alternative to the default flow. Excellent. Here is what you will see in the next releases of Gillette. Thank you for watching. And if you have any question, please leave a comment to this video. Open an issue in the Gillette issue tracker or just write an email. We love talking with people about our plans and we really value any feedback. It helps to better understand how to solve real problems. Goodbye and stay tuned for the next video.