AXIS Security Development Model Software-ის მომხმარებლის სახელმძღვანელო

AXIS Security Development Model Software

შესავალი

ASDM მიზნები
Axis Security Development Model (ASDM) არის ჩარჩო, რომელიც განსაზღვრავს პროცესს და ინსტრუმენტებს, რომლებიც გამოიყენება Axis-ის მიერ ჩაშენებული უსაფრთხოების მქონე პროგრამული უზრუნველყოფის შესაქმნელად მთელი სიცოცხლის ციკლის განმავლობაში, დაწყებიდან დეკომპორციამდე.

ASDM-ის მცდელობების მამოძრავებელი ძირითადი მიზნებია

• აქციეთ პროგრამული უზრუნველყოფის უსაფრთხოება Axis-ის პროგრამული უზრუნველყოფის განვითარების აქტივობების ინტეგრირებულ ნაწილად.
• შეამცირეთ უსაფრთხოებასთან დაკავშირებული ბიზნეს რისკები აქსისის მომხმარებლებისთვის.
• Meet increasing awareness of security considerations by customers and partners.
• შექმენით ხარჯების შემცირების პოტენციალი პრობლემების ადრეული გამოვლენისა და მოგვარების გამო
  ASDM სფერო არის აქსისის პროგრამული უზრუნველყოფა, რომელიც შედის აქსისის პროდუქტებსა და გადაწყვეტილებებში. Software Security Group (SSG) არის ASDM-ის მფლობელი და შემსრულებელი.

ლექსიკონი

ASDM დასრულდაview

ASDM მოიცავს რამდენიმე აქტივობას, რომლებიც განაწილებულია განვითარების ძირითად ფაზებზე. უსაფრთხოების საქმიანობა ერთობლივად არის იდენტიფიცირებული, როგორც ASDM.

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

პროგრამული უსაფრთხოების ჯგუფი (SSG)

SSG არის მთავარი შიდა საკონტაქტო პირი დეველოპერულ ორგანიზაციებთან უსაფრთხოების საკითხებთან დაკავშირებით. იგი მოიცავს უსაფრთხოების ლიდერებს და სხვებს, რომლებსაც აქვთ უსაფრთხოების სპეციალიზებული ცოდნა განვითარების სფეროებში, როგორიცაა მოთხოვნები, დიზაინი, განხორციელება, გადამოწმება,
ასევე მრავალფუნქციური DevOps პროცესები.
SSG პასუხისმგებელია ASDM-ის შემუშავებასა და შენარჩუნებაზე განვითარების უსაფრთხო პრაქტიკის და განვითარების ორგანიზაციაში უსაფრთხოების ცნობიერებისთვის.

თანამგზავრები
თანამგზავრები არიან განვითარების ორგანიზაციის წევრები, რომლებიც დროის ნაწილს ატარებენ პროგრამული უზრუნველყოფის უსაფრთხოების ასპექტებთან მუშაობაში. თანამგზავრების არსებობის მიზეზებია:

• გააფართოვეთ ASDM დიდი ცენტრალური SSG-ის აშენების გარეშე
• უზრუნველყოს ASDM მხარდაჭერა განვითარების გუნდებთან ახლოს
• ცოდნის გაზიარების ხელშეწყობა, მაგ., საუკეთესო პრაქტიკა
  სატელიტი ხელს შეუწყობს ახალი აქტივობების განხორციელებას და ASDM-ის შენარჩუნებას განვითარების გუნდების ქვეჯგუფში.

ASDM აქტივობის გავრცელება
ASDM აქტივობის გავრცელება განვითარების გუნდში არის როგორცtaged პროცესი:

1. გუნდი ეცნობა ახალ საქმიანობას როლური ტრენინგის საშუალებით.
2. SSG მუშაობს გუნდთან ერთად, რათა შეასრულოს აქტივობა, მაგალითად, რისკის შეფასება ან საფრთხის მოდელირება, გუნდის მიერ მართული სისტემის შერჩეული ნაწილებისთვის.
3. შემდგომი აქტივობები, რომლებიც დაკავშირებულია ინსტრუმენტთა ყუთის ინტეგრირებასთან ყოველდღიურ მუშაობაში, გადაეცემა გუნდს და თანამგზავრს, როდესაც ისინი მზად იქნებიან დამოუკიდებლად იმუშაონ SSG-ის უშუალო ჩართულობის გარეშე. ამ ფაზაში მუშაობას მართავს გუნდის მენეჯერი ASDM სტატუსით.
   გაშვება მეორდება, როდესაც ხელმისაწვდომია ASDM-ის ახალი ვერსიები შეცვლილი და/ან დამატებული აქტივობებით. SSG-ის მიერ გუნდთან გატარებული დროის რაოდენობა დიდად არის დამოკიდებული აქტივობასა და კოდის სირთულეზე. გუნდისთვის წარმატებული გადაცემის მთავარი ფაქტორია ჩაშენებული თანამგზავრის არსებობა, რომელსაც შეუძლია გააგრძელოს ASDM შემდგომი მუშაობა გუნდთან. SSG ახორციელებს სატელიტის სწავლას და მინიჭებას აქტივობების გაშვების პარალელურად.
   ქვემოთ მოყვანილი ფიგურა აჯამებს გაშვების მეთოდოლოგიას.

   

SSG განმარტება "შესრულებულია" გადაცემისთვის არის:

• შესრულებულია როლური ტრენინგი
• მინიჭებული სატელიტი
• გუნდი მზად არის ASDM აქტივობის შესასრულებლად
• დამყარებულია ASDM სტატუსის განმეორებითი შეხვედრები
  SSG იყენებს გუნდების მონაცემებს უმაღლესი მენეჯმენტისთვის სტატუსის ანგარიშების შეგროვებისთვის.

SSG-ის სხვა აქტივობები
გავრცელების აქტივობების პარალელურად, SSG ახორციელებს უსაფრთხოების ცნობიერების ამაღლების უფრო ფართო ტრენინგს, რომელიც მიზნად ისახავს, ​​მაგალითად, ახალ თანამშრომლებსა და უფროს მენეჯმენტს. გარდა ამისა, SSG ინახავს Axis-ის გადაწყვეტილებების უსაფრთხოების სითბოს რუკას საერთო/არქიტექტურული რისკის შეფასების მიზნებისთვის. უსაფრთხოების პროაქტიული ანალიზის აქტივობები კონკრეტული მოდულებისთვის ხორციელდება სითბოს რუქის საფუძველზე.

როლები და პასუხისმგებლობები
როგორც ნაჩვენებია ქვემოთ მოცემულ ცხრილში, არის რამდენიმე ძირითადი ერთეული და როლი, რომლებიც ASDM პროგრამის ნაწილია. ქვემოთ მოყვანილი ცხრილი აჯამებს როლებსა და პასუხისმგებლობებს ASDM-თან მიმართებაში.

ASDM მმართველობა

მმართველობის სისტემა მოიცავს შემდეგ ნაწილებს:

• სისტემური რისკის სითბოს რუკა, რომელიც დაგეხმარებათ ASDM აქტივობების პრიორიტეტიზაციაში
• განვითარების გეგმა და სტატუსი ტრენინგის ძალისხმევაზე ფოკუსირებისთვის
• საგზაო რუკა ხელსაწყოების ყუთის განვითარებისთვის
• სტატუსი იმის გასაზომად, თუ რამდენად კარგად არის ინტეგრირებული ASDM აქტივობები ორგანიზაციაში

ამრიგად, ASDM სისტემა მხარდაჭერილია როგორც ტაქტიკური/ოპერაციული, ასევე სტრატეგიული/აღმასრულებელი პერსპექტივიდან.
აღმასრულებელი სახელმძღვანელო სურათზე მარჯვენა მხარეს ფოკუსირებულია იმაზე, თუ როგორ უნდა განვითარდეს ორგანიზაცია ოპტიმალური ეფექტურობისთვის Axis-ის ბიზნეს მიზნების შესაბამისად. ამაში მნიშვნელოვანი შენატანი არის SSG-ის მიერ შესრულებული ASDM სტატუსის მოხსენება Firmware Steering Group-ის, CTO-სა და პროდუქტის მენეჯმენტის მიმართ.

ASDM სტატუსის სტრუქტურა

ASDM სტატუსის სტრუქტურას აქვს ორი პერსპექტივა: ერთი გუნდის ცენტრი, რომელიც მიბაძავს ჩვენს გუნდს და დეპარტამენტის სტრუქტურას, და ერთი გადაწყვეტის ცენტრი, რომელიც ფოკუსირებულია იმ გადაწყვეტილებებზე, რომლებიც ჩვენ შემოგვაქვს ბაზარზე.
ქვემოთ მოყვანილი ფიგურა ასახავს ASDM სტატუსის სტრუქტურას.

გუნდის სტატუსი
გუნდის სტატუსი შეიცავს ASDM სიმწიფის გუნდის თვითშეფასებას, მეტრიკას, რომელიც დაკავშირებულია მათ უსაფრთხოების ანალიზის აქტივობებთან, ასევე იმ კომპონენტების უსაფრთხოების სტატუსის გაერთიანებას, რომლებზეც ისინი პასუხისმგებელნი არიან.

Axis განსაზღვრავს ASDM სიმწიფეს, როგორც ASDM ვერსიას, რომელსაც ამჟამად იყენებს გუნდი. ვინაიდან ASDM ვითარდება, ჩვენ განვსაზღვრეთ ASDM ვერსიირება, სადაც ASDM-ის თითოეული ვერსია შეიცავს აქტივობების უნიკალურ კომპლექტს. მაგampასევე, ASDM-ის ჩვენი პირველი ვერსია ორიენტირებულია საფრთხის მოდელირებაზე.
Axis-მა განსაზღვრა შემდეგი ASDM ვერსიები:

გუნდისთვის მინიჭება ASDM-ის რომელ ვერსიას იყენებენ, ნიშნავს, რომ ეს არის ხაზის მენეჯერი, რომელიც პასუხისმგებელია ახალი ASDM ვერსიების მიღებაზე. ასე რომ, იმის ნაცვლად, რომ დაყენება, სადაც SSG უბიძგებს ცენტრალური ASDM გაშვების გეგმას, ის ახლა ხდება pull-ზე დაფუძნებული და კონტროლირებადი მენეჯერების მიერ.

კომპონენტის სტატუსი

• ჩვენ გვაქვს კომპონენტის ფართო განმარტება, რადგან ჩვენ უნდა მოვუაროთ ყველა სახის არქიტექტურულ ერთეულს, დაწყებული Linux-ის დემონებიდან პლატფორმაზე, სერვერის პროგრამული უზრუნველყოფის მეშვეობით, ღრუბლოვანი (მიკრო) სერვისებამდე.
• თითოეულმა გუნდმა უნდა შეადგინოს საკუთარი აზრი აბსტრაქციის დონის შესახებ, რომელიც მუშაობს მათთვის მათ გარემოსა და არქიტექტურაში. როგორც წესი, გუნდებმა თავიდან უნდა აიცილონ ახალი აბსტრაქციის დონის გამოგონება და შეინარჩუნონ ის, რასაც უკვე იყენებენ ყოველდღიურ მუშაობაში.
• იდეა არის ის, რომ თითოეულ გუნდს უნდა ჰქონდეს ნათელი view ყველა მათი მაღალი რისკის კომპონენტისგან, რომელიც მოიცავს როგორც ახალ, ასევე ძველ კომპონენტებს. ამ გაზრდილი ინტერესის მოტივაცია მემკვიდრეობითი კომპონენტების მიმართ უკავშირდება ჩვენს უნარს გადახედოთ უსაფრთხოების სტატუსს გადაწყვეტილებებისთვის. გადაწყვეტის შემთხვევაში, ჩვენ გვსურს გვქონდეს ხილვადობა გადაწყვეტის ყველა ნაწილის უსაფრთხოების სტატუსში, როგორც ახალს, ასევე ძველს.
• პრაქტიკაში ეს ნიშნავს, რომ ყველა გუნდმა უნდა დაათვალიეროს კომპონენტების ინვენტარი და გააკეთოს რისკის შეფასება.
• პირველი, რაც უნდა ვიცოდეთ, არის თუ არა კომპონენტმა უსაფრთხოების ანალიზი. თუ ეს ასე არ არის, ჩვენ ნამდვილად არ ვიცით არაფერი კომპონენტის უსაფრთხოების ხარისხის შესახებ.

ჩვენ ვუწოდებთ ამ ქონების დაფარვას და განვსაზღვრეთ შემდეგი დაფარვის დონეები:

მეტრიკა, რომელსაც ვიყენებთ კომპონენტის უსაფრთხოების ხარისხის დასაფიქსირებლად, ეფუძნება უსაფრთხოების სამუშაო ერთეულებს, რომლებიც დაკავშირებულია კომპონენტთან. ეს შეიძლება იყოს კონტრზომები, რომლებიც არ იქნა განხორციელებული, სატესტო შემთხვევები, რომლებიც არ არის შესრულებული და უსაფრთხოების შეცდომები, რომლებიც არ იქნა მოგვარებული.

გადაწყვეტის სტატუსი

გადაწყვეტის სტატუსი აერთიანებს უსაფრთხოების სტატუსს კომპონენტების ნაკრებისთვის, რომლებიც ქმნიან გამოსავალს.
გადაწყვეტის სტატუსის პირველი ნაწილი არის კომპონენტების ანალიზის გაშუქება. ეს ეხმარება გადაწყვეტის მფლობელებს გაიგონ, ცნობილია თუ არა გადაწყვეტის უსაფრთხოების სტატუსი. ერთი პერსპექტივით, ეს ხელს უწყობს ბრმა წერტილების იდენტიფიცირებას. გადაწყვეტის დანარჩენი სტატუსი შეიცავს მეტრიკას, რომელიც ასახავს გადაწყვეტის უსაფრთხოების ხარისხს. ჩვენ ამას ვაკეთებთ უსაფრთხოების სამუშაო ელემენტების დათვალიერებით, რომლებიც დაკავშირებულია გადაწყვეტის კომპონენტებთან. უსაფრთხოების სტატუსის მნიშვნელოვანი ასპექტია გადაწყვეტის მფლობელების მიერ განსაზღვრული შეცდომების ზოლი. გადაწყვეტის მფლობელებმა უნდა განსაზღვრონ უსაფრთხოების შესაბამისი დონე მათი გადაწყვეტისთვის. მაგampეს ნიშნავს, რომ ხსნარს არ უნდა ჰქონდეს გამოჩენილი კრიტიკული ან მაღალი სიმძიმის სამუშაო ნივთები, რომლებიც ბაზარზე გამოქვეყნდება.

ASDM საქმიანობა

რისკის შეფასება
რისკის შეფასების მთავარი მიზანია გაფილტვრა რა განვითარების აქტივობები, რომლებიც ასევე მოითხოვს უსაფრთხოების მუშაობას გუნდში.
რისკის შეფასება ხდება იმის დასკვნით, ზრდის თუ არა ახალი პროდუქტის ან არსებულ პროდუქტებში დამატებულ/შეცვლილ მახასიათებლებს რისკის ზემოქმედებას. გაითვალისწინეთ, რომ ეს ასევე მოიცავს მონაცემთა კონფიდენციალურობის ასპექტებს და შესაბამისობის მოთხოვნებს. მაგampცვლილებები, რომლებიც რისკზე ზემოქმედებას ახდენს, არის ახალი API, ავტორიზაციის მოთხოვნების ცვლილებები, ახალი შუა პროგრამა და ა.შ.

მონაცემთა კონფიდენციალურობა
ნდობა არის აქსისის ძირითადი ფოკუსირების სფერო და, როგორც ასეთი, მნიშვნელოვანია დაიცვას საუკეთესო პრაქტიკა ჩვენი პროდუქტების, გადაწყვეტილებებისა და სერვისების მიერ შეგროვებულ პირად მონაცემებთან მუშაობისას.
მონაცემთა კონფიდენციალურობასთან დაკავშირებული Axis-ის ძალისხმევის სფერო განისაზღვრება ისე, რომ ჩვენ შეგვიძლია:

• შეასრულეთ კანონიერი ვალდებულებები
• შეასრულეთ სახელშეკრულებო ვალდებულებები
• დაეხმარეთ მომხმარებლებს თავიანთი ვალდებულებების შესრულებაში

ჩვენ ვყოფთ მონაცემთა კონფიდენციალურობის აქტივობას ორ ქვეაქტივობად:

• მონაცემთა კონფიდენციალურობის შეფასება
  • შესრულებულია რისკის შეფასების დროს
  • განსაზღვრავს, საჭიროა თუ არა მონაცემთა კონფიდენციალურობის ანალიზი
•  მონაცემთა კონფიდენციალურობის ანალიზი
  • შესრულებულია, როდესაც ეს შესაძლებელია, საფრთხის მოდელირების დროს
  • განსაზღვრავს პერსონალურ მონაცემებს და საფრთხეებს პერსონალურ მონაცემებზე
  • განსაზღვრავს კონფიდენციალურობის მოთხოვნებს

საფრთხის მოდელირება
სანამ საფრთხეების იდენტიფიცირებას დავიწყებთ, უნდა გადავწყვიტოთ საფრთხის მოდელის ფარგლები. ფარგლების არტიკულაციის გზა არის თავდამსხმელების აღწერა, რომლებიც უნდა განვიხილოთ. ეს მიდგომა ასევე მოგვცემს საშუალებას განვსაზღვროთ მაღალი დონის თავდასხმის ზედაპირები, რომლებიც უნდა შევიტანოთ ანალიზში.

• საფრთხის სკოპინგის დროს ყურადღება გამახვილებულია თავდამსხმელების პოვნაზე და კატეგორიზაციაზე, რომლებსაც ჩვენ გვსურს გავუმკლავდეთ სისტემის მაღალი დონის აღწერილობის გამოყენებით. სასურველია, აღწერა შესრულდეს მონაცემთა ნაკადის დიაგრამის (DFD) გამოყენებით, რადგან ეს აადვილებს გამოყენების შემთხვევების უფრო დეტალურ აღწერილობებს, რომლებიც გამოიყენება საფრთხის მოდელის შესრულებისას.
• ეს არ ნიშნავს, რომ ყველა ის თავდამსხმელი, რომელსაც ჩვენ ვიდენტიფიცირებთ, გასათვალისწინებელია, ეს უბრალოდ ნიშნავს, რომ ჩვენ აშკარად და თანმიმდევრულნი ვართ თავდამსხმელებთან მიმართებაში, რომლებსაც საფრთხის მოდელში მივმართავთ. ამრიგად, არსებითად თავდამსხმელები, რომლებსაც ჩვენ ვირჩევთ განვიხილავთ, განსაზღვრავენ სისტემის უსაფრთხოების დონეს, რომელსაც ჩვენ ვაფასებთ.
  გაითვალისწინეთ, რომ ჩვენი თავდამსხმელის აღწერილობა არ ითვალისწინებს თავდამსხმელის შესაძლებლობებს ან მოტივაციას. ჩვენ ავირჩიეთ ეს მიდგომა საფრთხის მოდელირების მაქსიმალურად გასამარტივებლად და გასამარტივებლად.

  

საფრთხის მოდელირებას აქვს სამი საფეხური, რომელიც შეიძლება განმეორდეს გუნდის შეხედულებისამებრ:

1. აღწერეთ სისტემა DFD-ების ნაკრების გამოყენებით
2. გამოიყენეთ DFD საფრთხის იდენტიფიცირებისთვის და აღწეროთ ისინი ბოროტად გამოყენების სტილში
3. 3. საფრთხის საწინააღმდეგო ზომების და გადამოწმების განსაზღვრა
   საფრთხის მოდელირების აქტივობის შედეგი არის საფრთხის მოდელი, რომელიც შეიცავს პრიორიტეტულ საფრთხეებს და კონტრზომებს. კონტრზომების გადასაჭრელად საჭირო განვითარების სამუშაოები იმართება Jira-ს ბილეთების შექმნით, როგორც კონტრზომის განხორციელებისთვის, ასევე გადამოწმებისთვის.

   

სტატიკური კოდის ანალიზი
ASDM-ში გუნდებს შეუძლიათ გამოიყენონ სტატიკური კოდის ანალიზი სამი გზით:

• დეველოპერის სამუშაო პროცესი: დეველოპერები აანალიზებენ კოდს, რომელზეც მუშაობენ
• Gerrit სამუშაო პროცესი: დეველოპერები იღებენ გამოხმაურებას Gerrit-ში
• Legacy workflow: გუნდები აანალიზებენ მაღალი რისკის მემკვიდრეობის კომპონენტებს

  

დაუცველობის სკანირება
დაუცველობის რეგულარული სკანირება დეველოპერულ გუნდებს საშუალებას აძლევს, დაადგინონ და დააფიქსირონ პროგრამული უზრუნველყოფის ხარვეზები, სანამ პროდუქტები გამოქვეყნდება საზოგადოებისთვის, რაც ამცირებს მომხმარებლის რისკს პროდუქტის ან სერვისის გამოყენებისას. სკანირება ხორციელდება ყოველი გამოშვების ტექნიკის, პროგრამული უზრუნველყოფის გამოშვებამდე ან გაშვებული გრაფიკით (მომსახურებით) როგორც ღია წყაროს, ისე კომერციული დაუცველობის სკანირების პაკეტების გამოყენებით. სკანირების შედეგები გამოიყენება ბილეთების გენერირებისთვის Jira საკითხის თვალთვალის პლატფორმაზე. ბილეთები გაიცემა სპეციალური tag უნდა იყოს იდენტიფიცირებული განვითარების გუნდების მიერ, როგორც მოწყვლადობის სკანირების შედეგად და რომ მათ უნდა მიენიჭოთ მაღალი პრიორიტეტი. ყველა დაუცველობის სკანირება და Jira ბილეთები ინახება ცენტრალურად მიკვლევადობისა და აუდიტის მიზნებისთვის. კრიტიკული დაუცველობა უნდა მოგვარდეს გამოშვებამდე ან სპეციალური სერვისის გამოშვებაში სხვა, არაკრიტიკულ დაუცველობასთან ერთად,
თვალყურის დევნება და გადაწყვეტა firmware ან პროგრამული უზრუნველყოფის გამოშვების ციკლის შესაბამისად. მეტი ინფორმაცია იმის შესახებ, თუ როგორ ხდება დაუცველობის შეფასება და მართვა, იხილეთ დაუცველობის მართვა გვერდზე 12

გარე შეღწევადობის ტესტირება
ცალკეულ შემთხვევებში, მესამე მხარის შეღწევადობის ტესტირება ტარდება Axis-ის აპარატურულ ან პროგრამულ პროდუქტებზე. ამ ტესტების ჩატარების მთავარი მიზანია უზრუნველყოს ხედვა და დარწმუნება პლატრომის უსაფრთხოებასთან დაკავშირებით კონკრეტულ დროში და კონკრეტული მოცულობისთვის. ASDM-თან ჩვენი ერთ-ერთი მთავარი მიზანია გამჭვირვალობა, ამიტომ ჩვენ მოვუწოდებთ ჩვენს მომხმარებლებს, განახორციელონ გარე შეღწევადობის ტესტირება ჩვენს პროდუქტებზე და მოხარული ვართ ვითანამშრომლოთ ტესტირებისთვის შესაბამისი პარამეტრების განსაზღვრისას, ასევე შედეგების ინტერპრეტაციის ირგვლივ დისკუსიებში.

დაუცველობის მართვა
Axis 2021 წლიდან არის რეგისტრირებული CVE დასახელების ორგანო (CNA) და, შესაბამისად, შეუძლია გამოაქვეყნოს სტანდარტული CVE ანგარიშები MITER მონაცემთა ბაზაში მესამე მხარის დაუცველობის სკანერებისა და სხვა ხელსაწყოების მიერ მოხმარებისთვის. დაუცველობის დაფა (VB) არის შიდა ღერძის საკონტაქტო წერტილი გარე მკვლევარების მიერ აღმოჩენილი დაუცველობისთვის. მოხსენება
აღმოჩენილი დაუცველობებისა და შემდგომი გამოსწორების გეგმების კომუნიკაცია ხდება product-security@axis.com ელექტრონული ფოსტის მისამართი.
მოწყვლადობის საბჭოს მთავარი პასუხისმგებლობაა მოხსენებული დაუცველობის ანალიზი და პრიორიტეტიზაცია ბიზნესის პერსპექტივიდან გამომდინარე.

• ტექნიკური კლასიფიკაცია მოწოდებული SSG
• პოტენციური რისკი საბოლოო მომხმარებლებისთვის იმ გარემოში, სადაც Axis მოწყობილობა მუშაობს
• საკომპენსაციო უსაფრთხოების კონტროლის ხელმისაწვდომობა რისკის ალტერნატიული შერბილება პაჩის გარეშე)

VB რეგისტრირებს CVE ნომერს და მუშაობს რეპორტიორთან დაუცველობისთვის CVSS ქულის მინიჭების მიზნით. VB ასევე ახორციელებს გარე კომუნიკაციას პარტნიორებთან და მომხმარებლებთან Axis უსაფრთხოების შეტყობინებების სერვისის, პრესრელიზებისა და ახალი ამბების სტატიების მეშვეობით.

Axis Security Development Model © Axis Communications AB, 2022