npm audit სუფთაა? მავნე პაკეტი მაინც შეიძლება გამოგრჩეთ

npm პროექტის დამოკიდებულებების შესამოწმებლად ჯერ გადაამოწმეთ package-lock.json, შემდეგ გაუშვით npm audit და თითოეულ აღმოჩენას dependency path მიუყევით. npm-ის აუდიტის ინსტრუქცია განმარტავს, რომ ბრძანება ცნობილ სისუსტეებს ეძებს პირდაპირ, განვითარების, ჩაშენებულ და არასავალდებულო დამოკიდებულებებში, მაგრამ peerDependencies-ს არ ამოწმებს. სუფთა ანგარიში ნიშნავს, რომ შემოწმებულ ხეში ცნობილი სისუსტე ვერ მოიძებნა; ის პაკეტის კოდს უსაფრთხოდ არ აცხადებს.

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

დაიწყეთ lockfile-ით

პროექტის ძირეულ საქაღალდეში შეამოწმეთ package.json და package-lock.json. პირველი აცხადებს მოთხოვნილ დამოკიდებულებებსა და დასაშვებ ვერსიებს; მეორე აღწერს კონკრეტულად გადაწყვეტილი დამოკიდებულებების ხეს. თუ lockfile არ არსებობს და აუდიტი შეცდომას აბრუნებს, მისი შექმნა შეიძლება ბრძანებით npm install --package-lock-only. მიღებული ფაილი ჯერ გადახედეთ: ახლად გადაწყვეტილი ხე შესაძლოა განსხვავდებოდეს იმ პაკეტებისგან, რომლებითაც პროექტი ადრე მუშაობდა.

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

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

ანგარიშში იპოვეთ გზა პრობლემურ პაკეტამდე

აღმოჩენილ სისუსტეზე ჯერ წაიკითხეთ პაკეტის სახელი, დაზიანებული ვერსია, პრობლემის აღწერა, სიმძიმე და შემოთავაზებული გამოსწორება. შემდეგ ნახეთ dependency path — გზა, რომლითაც პაკეტი თქვენს პროექტში მოხვდა. თუ ის პირდაპირ წერია package.json-ში, განახლების არჩევანი თქვენს გუნდს შეუძლია; შუალედური დამოკიდებულების შემთხვევაში ხშირად მისი მომთხოვნი პაკეტის განახლებაა საჭირო.

პირობითად, თუ გზა არის „პროექტი → A → B“ და სისუსტე B-შია, ჯერ გაარკვიეთ, არსებობს თუ არა A-ს გამოშვება, რომელიც B-ს გამოსწორებულ ვერსიას იყენებს. თუ არ არსებობს, საკითხი შეიძლება A-ს შემნახველთან ცვლილებას ან სხვა დამოკიდებულების არჩევას მოითხოვდეს. ერთი და იგივე დაზიანებული პაკეტი ხეში რამდენიმე გზითაც შეიძლება ხვდებოდეს; მხოლოდ ერთი განშტოების განახლება ყველა აღმოჩენას ვერ მოხსნის.

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

როდის გამოიყენოთ npm audit fix

npm audit fix გამოიყენეთ, როცა შემოთავაზებული თავსებადი განახლებები გასაგებია და მათი შედეგის შემოწმება შეგიძლიათ. npm audit-ის CLI დოკუმენტაცია განმარტავს, რომ fix სრულ npm install-ს ასრულებს, ზოგი სისუსტე ხელით განხილვას მოითხოვს, ხოლო --force-მა შეიძლება დამოკიდებულება მითითებული ვერსიის დიაპაზონის გარეთ, მათ შორის ახალ მთავარ ვერსიაზე, გადაიყვანოს. ამიტომ fix-ის გაშვებამდე ცვლილების მასშტაბი შეაფასეთ.

სამუშაო ხის საწყისი მდგომარეობა შეინახეთ და, თუ წინასწარ ნახვა გჭირდებათ, გაუშვით npm audit fix --dry-run --json. მისაღები ცვლილებების შემთხვევაში გაუშვით fix და შეადარეთ package.json-ისა და package-lock.json-ის სხვაობა. ამის შემდეგ გაუშვით პროექტის შესაბამისი ტესტები და ხელახლა ჩაატარეთ აუდიტი. გადაამოწმეთ, გაქრა თუ არა დაზიანებული ვერსია ყველა იმ გზიდან, რომლითაც ის პროექტში ხვდებოდა.

თუ გამოსწორება --force-ს ან შესაძლო breaking change-ს მოითხოვს, განახლება ცალკე ცვლილებად განიხილეთ. შეისწავლეთ ზედა დონის პაკეტის ახალი ვერსიის ცვლილებები, შეადარეთ ისინი თქვენს მიერ გამოყენებულ API-ს და მხოლოდ შემდეგ შეცვალეთ ვერსია. თუ გამოსწორებული გამოშვება არ არსებობს, fix-ის გამეორება შედეგს ვერ შეცვლის: დააფიქსირეთ გამოყენების პირობები, შესაძლო შემამსუბუქებელი ზომა და ის დამოკიდებულება, რომლის განახლებასაც ელოდებით.

რატომ შეიძლება მავნე კოდი სუფთა ანგარიშის მიღმა დარჩეს

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

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

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

წარმომავლობა და ხელმოწერა ცალკე გადაამოწმეთ

პაკეტის გამოქვეყნების წარმომავლობა დამატებითი მტკიცებულებაა. npm-ის provenance-ის ინსტრუქცია აღწერს, როგორ ნახოთ გამოშვებასთან დაკავშირებული აგების გარემო, workflow და საწყისი commit; npm audit signatures კი რეესტრის ხელმოწერებსა და ხელმისაწვდომ ატესტაციებს ამოწმებს. ეს შემოწმება გეხმარებათ გამოშვების დაკავშირებაში იმ წყაროსა და გამოქვეყნების პროცესთან, რომელსაც ელოდით.

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

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

ასევე წაიკითხეთ:

• LLM API-ის დაბალი ფასი შეიძლება მოჩვენებითი იყოს — გადამწყვეტია პასუხის სიგრძე