One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8359335 |
| Date de publication | 2023-07-20 12:00:23 (vue: 2023-07-20 18:06:41) |
| Titre | Un regard sur la culture de la révision de la sécurité de Chrome \\ A look at Chrome\\'s security review culture |
| Texte | Posted by Alex Gough, Chrome Security Team Security reviewers must develop the confidence and skills to make fast, difficult decisions. A simplistic piece of advice to reviewers is “just be confident” but in reality that takes practice and experience. Confidence comes with time, and people are there to support each other as we learn. This post shares advice we give to people doing security reviews for Chrome. Security Review in Chrome Chrome has a lightweight launch process. Teams write requirements and design documents outlining why the feature should be built, how the feature will benefit users, and how the feature will be built. Developers write code behind a feature flag and must pass a Launch Review before turning it on. Teams think about security early-on and coordinate with the security team. Teams are responsible for the safety of their features and ensuring that the security team is able to say \'yes\' to its security review. Security review focuses on the design of a proposed feature, not its details and is distinct from code review. Chrome changes need approval from engineers familiar with the code being changed but not necessarily from security experts. It is not practical for security engineers to scrutinize every change. Instead we focus on the feature\'s architecture, and how it might affect people using Chrome. Reviewers function best in an open and supportive engineering culture. Security review is not an easy task – it applies security engineering insights in a social context that could become adversarial and fractious. Google, and Chrome, embody a security-centric engineering culture, where respectful disagreement is valued, where we learn from mistakes, where decisions can be revisited, and where developers see the security team as a partner that helps them ship features safely. Within the security team we support each other by encouraging questioning & learning, and provide mentorship and coaching to help reviewers enhance their reviewing skills. Learning security review Start by shadowing Start with some help. As a new reviewer, you may not feel you\'re 100% ready - don\'t let that put you off. The best way to learn is to observe and see what\'s involved before easing in to doing reviews on your own. Start by shadowing to get a feel for the process. Ask the person you are shadowing how they plan to approach the review, then look at the materials yourself. Concentrate on learning how to review rather than on the details of the thing you are reviewing. Don\'t get too involved but observe how the reviewer does things and ask them why. Next time try to co-review something - ask the feature team some questions and talk through your thoughts with the other reviewer. Let them make the final approval decision. Do this a few times and you\'ll be ready to be the main reviewer, and remember that you can always reach out for help and advice. Read enough to make a decision Read a lot, but know when to stop. Understand what the feature is doing, what\'s new, and what\'s built on existing, approved, mechanisms. Focus on the new things. If you need to educate yourself, skim older docs or code for context. It can help to look at related reviews for repeated issues and solutions. It is tempting to try to understand everything and at first you\'ll dig deeper than you need to. You\'ll get better at knowing when to stop after a few reviews. Treat existing, approved, features as building blocks that you don\'t need to fully understand, but might be useful to skim as background. |
| Envoyé | Oui |
| Condensat | 100 able about absolutely abuse across actively actor add adding addressed addresses adversarial advice advocate affect affected after again alex all allows also always ambiguity ambiguous analysis anoint another answer anti any appealing application applied applies apply approach approaches approval approve approved architectural architecture are area areas aren arguments around articulate ask asking assessments assumption assumptions attention available awkward back background bad badly balance based become been before behind being benefit best better bit blocks book both bounce brain brief bring bug build building built bump burden but button calendar call can cannot careful center centric champions chances change changed changes chat checklist choosing chrome clarify clear clearly click close coaching code coffee come comes comfortable coming commit communicated communication community compile complete complex complicated component concentrate concern concerns concisely concrete confidence confident confident” conflicts confusing consequences considerations contact contain contained context conversations conversations” coordinate correct could couple courses covered critical cross culture data daunting decision decisions deep deeper deeply defense defenses deliberately describe describing design designers designs details develop developer developers development deviations diagram diagrams did didn differences different differently difficult dig digestion direction disagree disagreement discover discuss discussion distill distinct doc docs document documentation documents does doesn doing domain dominates don done down drop each early easing easy educate effective efforts element else embody embrace empower encourage encouraging end energy engagements engineer engineering engineers enhance enough enquiring ensuring especially establish evaluating evaluation even every everything examples existing expanded expect expectations expecting experience experienced expert expertise experts explain explained extends factor familiar familiarity faqs fast favorite feature features feedback feel feels final find fine finger first fix fixed flag focus focuses follow followed forever forms formulate found foundational fractious frameworks from frustration fully function fuzzer gate general get gets give good google got gough gradually great group groups grow guidance had halls happen happening happens happy harden harder harm has have having help helpful helps here hints hone how idea ideally ideas identify ignorance ignorant ignored illustrate imagine immediately impact implement implementation implicit important improve include increases indicates inevitable information initial input insightful insights instead interactions interfaces invalid invent invisible involved isn issues iterated its job journey judgment just justified keep keeps know knowing knowledge lacks larger later launch launching layered leading learn learning leave led let level library lightweight like likely line list lives local locate long look looking looks lose lot low made mailing main mainly maintain major make making many materials matter mature may mean mechanisms meetings mentorship message might mind mindset mine minutes mismatch missed missing mistake mistakes modeling modeling” models modifies more much must mysterious naturally necessarily need needed needs new newer next normal not note notes nothing notice nudge observations observe occurs off offer often older once one ones only open opinion organization other others ourselves out outlining over own pair pairing paragraph part particular partner parts pass passes past patience patterns pause peers people perfect performance permission person perspective phase piece pieces pillar plain plan please point points policies possible post posted practical practice press preventing principles probably problem problems process product progress project promised proposed protect provide provided provides purpose put puzzle quality question questioning questions quickly quite raise raised rather reach |
| Tags | Threat |
| Stories | |
| Notes | ★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.