पहली बार चलाने से पहले downloaded macOS app की जांच

Security app को अपने काम के कारण असामान्य access मिलता है। यह network traffic पढ़ सकती है, system extension जोड़ सकती है, privileged helper install कर सकती है, files की जांच कर सकती है या screen recording और accessibility permissions मांग सकती है। इसके first launch को किसी सामान्य app installation की तरह लेना ऐसी गलती है जिसे आसानी से टाला जा सकता है।

अच्छी review के लिए पूरे product की reverse engineering करने की जरूरत नहीं होती। आपको यह जांचना होता है कि आपको वही artifact मिला है जिसे आप पाना चाहते थे, उसका publisher वही है जिसकी आपको उम्मीद थी, उसकी contents अब भी signed release से मेल खाती हैं और macOS उसे अपनी सामान्य protections के तहत स्वीकार करता है। App को permissions, credentials या administrator password देने से पहले यह करें।

यह review जानबूझकर दोहराव वाली है। यही इसकी ताकत है। macOS उस समय जो warning दिखाए, उसके आधार पर किया गया one-time ritual आसानी से bypass हो सकता है। हर नई security app के लिए इन्हीं checks का छोटा record रखना कठिनाई बढ़ाता है और उसे किसी दूसरे engineer को सौंपना आसान बनाता है।

File name publisher नहीं होता

Acme Security.app नाम की file आपको लगभग कुछ नहीं बताती। Copied icon, परिचित product name और polished download page की नकल करना आसान है। आपको signature में दर्ज identity की पुष्टि करनी है, फिर उस identity की तुलना publisher से अलग रास्ते से मिली जानकारी से करनी है।

Source से शुरुआत करें। Publisher के अपने release page या उसके documentation में बताए गए release location को प्राथमिकता दें। Download aggregators, file mirrors और chat thread से मिले links से बचें, जब original release सीधे मिल सकता हो। अगर कोई colleague file भेजता है, तो उससे पूछें कि उसने वह file कहां से प्राप्त की, उसकी possession को provenance न मानें।

यहां दो अलग सवाल हैं:

• क्या यह file उस जगह से आई है जहां से मैं इसे लेना चाहता था?
• क्या इस executable को sign करने वाला publisher वही है जिस पर मैं भरोसा करना चाहता था?

लोग अक्सर इन दोनों सवालों को एक मान लेते हैं। इसी वजह से compromised vendor download page भी सतही review में पास हो सकता है। इसी तरह valid Apple Developer ID वाली app केवल इसलिए trusted हो सकती है क्योंकि उसका नाम किसी जाने-पहचाने vendor जैसा है।

File की जांच से पहले अपनी अपेक्षा लिख लें। App का product name, version, expected file type, publisher name और प्रकाशित Team Identifier या signing certificate details दर्ज करें। अगर vendor ने कभी stable identifier प्रकाशित नहीं किया है, तो कई स्वतंत्र संकेतों का उपयोग करें: उसका documentation, source repository, कोई पुराना release जिस पर आप पहले से भरोसा करते हैं और किसी ज्ञात contact से मिला support response। जब vendor से जोड़ने का कोई पुराना आधार न हो, तब अकेली certificate subject line पर्याप्त नहीं है।

जो app दूसरे software की सुरक्षा करने का दावा करती है, उसके publisher से यह जानकारी आसानी से मिलनी चाहिए। अगर vendor आपसे Gatekeeper disable करने, shell में curl pipe चलाने या किसी mismatch को बिना सटीक explanation के ignore करने को कहता है, तो installation review पहले ही असफल हो चुकी है।

खोलने से पहले delivery artifact सत्यापित करें

Downloaded container को Applications में drag करने या installer चलाने से पहले जांचें। Container तय करता है कि कौन-से commands उपयोगी होंगे और आगे क्या हो सकता है।

.dmg एक disk image है। इसे mount करने से इसकी contents सामने आती हैं, लेकिन इससे अपने आप contained app शुरू नहीं होनी चाहिए। .pkg एक installer package है और Installer को authorize करने के बाद system changes कर सकता है। .zip एक archive है जो आमतौर पर app bundle या किसी दूसरे container में expand होती है। सीधे मिली .app पहले से application bundle होती है।

Review खत्म होने तक original download को बिना बदले रखें। Finder अक्सर ZIP files को अपने आप expand कर देता है। यह सुविधाजनक है, लेकिन इससे उस exact artifact का track खोना आसान हो जाता है जिसका hash vendor ने प्रकाशित किया है। अगर publisher ने ZIP के लिए SHA-256 checksum दिया है, तो extraction से पहले ZIP सत्यापित करें। अगर checksum disk image के लिए है, तो mounting से पहले disk image सत्यापित करें।

Terminal में पूरी तरह quoted path इस्तेमाल करें। Finder से file को Terminal में drag करने पर path सुरक्षित रूप से insert हो जाता है।

shasum -a 256 "$HOME/Downloads/VendorSecurity.dmg"

Output का रूप कुछ ऐसा होगा:

9fd1...e84c  /Users/you/Downloads/VendorSecurity.dmg

Publisher की value से सभी 64 hexadecimal characters मिलाएं। केवल शुरुआती कुछ characters मिलाकर काम पूरा न मानें।

Checksum तभी मजबूत evidence है जब expected digest downloaded file से अलग रास्ते से मिले। सबसे सरल अच्छा arrangement है vendor के release page से installer और signed release note, source repository release या अलग से maintained security page में दिया checksum। Download button के ठीक बगल में छपा hash accidental corruption पकड़ सकता है, लेकिन अगर attacker उस page और file दोनों को नियंत्रित करता है, तो यह आपकी रक्षा नहीं करता।

अगर vendor checksum प्रकाशित नहीं करता, तो झूठी निश्चितता न बनाएं। Signature और notarization checks जारी रखें और publisher verification को अधिक महत्व दें। अगर app आपके environment के लिए बहुत महत्वपूर्ण है, तो vendor से signed digest या release manifest मांगें। यह उचित request है।

Disk image के लिए आप macOS से उसकी internal structure भी validate करा सकते हैं:

hdiutil verify "$HOME/Downloads/VendorSecurity.dmg"

Successful verification बताती है कि image structure और checksum blocks आपस में consistent हैं। इससे publisher की पहचान नहीं होती और यह vendor द्वारा दिए गए SHA-256 digest की जगह नहीं लेती।

Valid signature integrity साबित करती है, समझदारी नहीं

Code signing एक सीमित लेकिन उपयोगी सवाल का जवाब देती है: क्या signer की मंज़ूरी के बाद signed bundle बदला है? इससे signing chain और Team Identifier भी मिलते हैं। इससे यह पता नहीं चलता कि app अच्छी तरह design की गई है, publisher आपके भरोसे के योग्य है या app का मांगा गया access उचित है।

Disk image mount करने या archive expand करने के बाद app bundle की सीधे जांच करें। यह command code signature verify करती है और bundle के अंदर nested signed code भी check करती है:

codesign --verify --deep --strict --verbose=4 "/Volumes/Vendor Security/Vendor Security.app"

Success पर अक्सर बहुत कम output आता है। Terminal का exit status ही परिणाम है, इसलिए command के बाद prompt पर शांतिपूर्वक लौटना सामान्य है। Failure होने पर codesign बदली हुई file, invalid signature या ऐसे nested component की पहचान करता है जो validate नहीं होता।

इसके बाद signing details दिखाएं:

codesign -dvvv "/Volumes/Vendor Security/Vendor Security.app" 2>&1 | \
  egrep "^(Identifier|TeamIdentifier|Authority|Timestamp)="

Output लगभग ऐसा दिख सकता है:

Identifier=com.vendor.security
TeamIdentifier=ABCDE12345
Authority=Developer ID Application: Vendor, Inc. (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jan 16, 2026 at 14:32:09

Actual vendor name, bundle identifier और Team Identifier आपकी अपेक्षा से मेल खाने चाहिए। Team Identifier लिख लें। यह app icon या display name की तुलना में कहीं अधिक stable और स्पष्ट पहचान है, और vendor के update जारी करने पर तुलना करने के लिए ठोस आधार देती है।

Authority शब्द को जरूरत से ज्यादा महत्व न दें। Developer ID signature का अर्थ है कि Apple ने certificate किसी registered developer को जारी किया है और code उस chain के अनुसार valid है। इसका अर्थ यह नहीं है कि Apple product की recommendation करता है। Apple के अपने documentation में संबंधित अंतर साफ है: notarization automated malware और signing check है, App Review नहीं।

Apple की code signing guidance developers को complex software sign करने के लिए codesign --deep का उपयोग न करने की चेतावनी भी देती है, क्योंकि यह options को बहुत व्यापक रूप से लागू करता है। यह चेतावनी signatures बनाने से जुड़ी है। User द्वारा verification pass करने पर --deep उपयोगी है, क्योंकि इससे codesign nested code को validate करता है। फिर भी यह हर script या configuration file में गलत intent की जांच नहीं करता।

अगर app में helper, command line tool या extension है, तो bundle verification पहला pass है, अंतिम निष्कर्ष नहीं। इस article में आगे दिया गया first launch review वह जगह है जहां आप इन components की तुलना app की बताई हुई जरूरतों से करते हैं।

Gatekeeper assessment उस release की जांच करता है जिसे macOS चलाएगा

Signature सही दिखने पर भी app पर Gatekeeper assessment चलाएं। spctl item को उस system policy के अनुसार evaluate करता है जो execution के समय महत्वपूर्ण होगी। यह इस सवाल के अधिक करीब है: «क्या यह Mac सामान्य protections के तहत इस app को स्वीकार करेगा?»

इस्तेमाल करें:

spctl --assess --type execute --verbose=4 \
  "/Volumes/Vendor Security/Vendor Security.app"

Healthy result में आमतौर पर ऐसी lines होती हैं:

/Volumes/Vendor Security/Vendor Security.app: accepted
source=Notarized Developer ID
origin=Vendor, Inc. (ABCDE12345)

Exact wording macOS release के अनुसार बदल सकती है। आपको accepted assessment, direct download होने पर notarized Developer ID source और ऐसा origin चाहिए जिसे आप पहचानते हों।

यह check वह गलती पकड़ता है जिसे checksum नहीं पकड़ सकता: आपने wrong publisher की unmodified file डाउनलोड की हो सकती है। यह उस दूसरी गलती को भी पकड़ता है जिसे certificate inspection अकेले छोड़ सकती है: validly signed app current Gatekeeper policy पर खरी न उतरे।

Apple Gatekeeper को downloaded software में identified developer, notarization और alteration की जांच करने वाला system बताता है। यह उपयोगी safety net है, लेकिन फिर भी operating system का policy assessment ही है। Publisher और मांगे गए privileges उचित हैं या नहीं, इसका निर्णय आपको खुद लेना है।

Failed assessment को समझे बिना attributes हटाकर या Finder override का इस्तेमाल करके suppress न करें। Failure text को review notes में सुरक्षित रखें। Revoked certificate, expired या malformed signature, missing notarization result और organization-managed restriction के लिए अलग-अलग responses चाहिए। हर warning को सामान्य परेशानी मानना exceptions को installation का सामान्य रास्ता बना देता है।

Stapled ticket मददगार है, लेकिन notarization check पूरी नहीं है

Notarization और stapling संबंधित हैं, लेकिन अलग चीजें हैं। Notarization का अर्थ है कि Apple's notary service ने submitted software को process किया और automated checks के बाद ticket जारी किया। Stapling उस ticket को app, disk image या installer package से attach करती है। Gatekeeper ticket को online भी ढूंढ सकता है।

अगर Xcode Command Line Tools installed हैं, तो देखें कि ticket attached है या नहीं:

xcrun stapler validate "/Volumes/Vendor Security/Vendor Security.app"

Successful validation confirm करती है कि ticket उस bundle के साथ physically attached है। यह ऐसे laptop के लिए उपयोगी है जो पहली बार app को network connection के बिना launch कर सकता है।

केवल इसलिए app reject न करें कि command कहती है कि ticket stapled नहीं है। Apple के documentation के अनुसार Gatekeeper notarization ticket online ढूंढ सकता है, जिसमें वह user भी शामिल है जिसने notarization पूरी होने से पहले app डाउनलोड की थी। ZIP archive खुद stapled ticket carry नहीं कर सकता। Publisher को उसके अंदर मौजूद items को staple करके नया archive बनाना होता है।

Checks सही क्रम में करें:

1. जब independently published digest उपलब्ध हो, तो SHA-256 digest सत्यापित करें।
2. App signature सत्यापित करें और Team Identifier देखें।
3. Gatekeeper assessment चलाएं।
4. अगर tool उपलब्ध है और offline first launch महत्वपूर्ण है, तो stapled ticket validate करें।

First normal launch के लिए Mac को online रखें, जब तक publisher offline deployment process को स्पष्ट रूप से document न करे। इससे Gatekeeper अपने सामान्य online lookups कर सकता है, जिनमें certificate status checks भी शामिल हैं। Stapled ticket को यह वादा न समझें कि signing identity बाद में revoke होने पर app हमेशा acceptable रहेगी।

Notarization की सीमाएं स्पष्ट हैं। यह app के behavior का complete audit नहीं है। इससे यह confirm नहीं होता कि app की cloud service data को सुरक्षित संभालती है, उसका update system sound है या नया version केवल उचित permissions मांगेगा। यह बताता है कि submitted artifact ने Apple's automated process पास किया और Gatekeeper के पास उपयोग करने के लिए ticket है।

Quarantine origin का evidence है, इसलिए इसे रहने दें

com.apple.quarantine extended attribute यह record करता है कि macOS को item ऐसे channel से मिला जिसे downloaded या transferred के रूप में mark किया गया था। इससे Gatekeeper को पता चलता है कि यह first run event है और इसकी जांच करनी चाहिए। यह malware label नहीं है।

Attributes देखने के लिए चलाएं:

xattr -l "/Volumes/Vendor Security/Vendor Security.app"

Downloaded item के लिए output में यह दिख सकता है:

com.apple.quarantine: 0083;...;Safari;...

Flags और timestamp format implementation details हैं। उपयोगी निष्कर्ष यह है कि item download provenance बनाए हुए है। केवल यह attribute होने से app suspicious नहीं हो जाती। अधिकांश browser downloads में यह attribute होना चाहिए।

Quarantine न होने से app safe भी साबित नहीं होती। Archive tools, network shares, removable media या colleague के copy operation से गुजरते समय files extended attributes खो सकती हैं। Apple यह भी कहता है कि macOS software के पहुंचने के तरीके की परवाह किए बिना first open पर known malicious content की जांच करता है। व्यवहार में provenance को बनाए रखना Gatekeeper और आपकी review process दोनों को बेहतर context देता है।

जो app open नहीं होती, उसके लिए लोकप्रिय fix यह है:

xattr -dr com.apple.quarantine "/Applications/Vendor Security.app"

इसे सामान्य installation procedure का हिस्सा न बनाएं। इससे control का result पसंद न आने पर control signal हटा दिया जाता है। इससे broken signature ठीक नहीं होती, publisher identity स्थापित नहीं होती और unnotarized app सुरक्षित नहीं बनती। अगर vendor की published instructions में यह command आवश्यक है, तो रुकें और पता लगाएं कि ऐसा release क्यों नहीं भेजा जा सकता जिसे Gatekeeper स्वीकार करे।

Managed Mac device management के ज़रिए अधिक सख्त rules लागू कर सकता है। ऐसी स्थिति में override उपलब्ध न होना या prohibited होना उचित कारण से हो सकता है। Restriction को technical puzzle मानने के बजाय administrator से policy path पूछें।

Installer को password देने से पहले packages की अपनी जांच करें

.pkg app bundle से अधिक सावधानी मांगती है, क्योंकि Apple's Installer authorization के बाद आपकी user folder के बाहर लिख सकता है। Security products को privileged helper, system extension, network filter या supporting components install करने के लिए packages की जरूरत हो सकती है। यह legitimate हो सकता है। फिर भी यह महत्वपूर्ण action है।

Double-click करने से पहले package की signing information जांचें:

pkgutil --check-signature "$HOME/Downloads/VendorSecurity.pkg"

Typical result package की signed status, Developer ID Installer certificate और certificate chain बताता है। जहां उपलब्ध हो, vendor name और Team Identifier की तुलना app के लिए दर्ज की गई identity या vendor की published installation material से करें।

इसके बाद Gatekeeper से package को installer के रूप में assess कराएं:

spctl --assess --type install --verbose=4 \
  "$HOME/Downloads/VendorSecurity.pkg"

Package assessment की जगह app assessment का उपयोग न करें। ये अलग artifacts हैं, कई releases में अलग certificate types के तहत signed होते हैं और इन्हें खोलने पर इनके consequences भी अलग होते हैं।

Administrator password डालने से पहले पहचानें कि installer क्या add करने का दावा करता है। अच्छा vendor बताता है कि वह privileged helper, system extension, login item, configuration profile या network component में से क्या install करता है। «Required system access» जैसे अस्पष्ट शब्द ऐसे software के लिए पर्याप्त नहीं हैं जो Mac के security-relevant हिस्सों को control करने की permission मांगता है।

अगर package app भी install करती है, तो उसे launch करने से पहले installed app की जांच करें। Signed package में app bundle होना legitimate है, लेकिन package की signature उस bundle की execution signature verify करने की जरूरत खत्म नहीं करती।

First launch approval review है, Allow दबाने की दौड़ नहीं

Artifact checks पास करने के बाद app को उसकी intended location पर ले जाएं और अपनी मौजूदगी में सामान्य तरीके से launch करें। App का initial setup पूरा होने तक original download और recorded outputs सुरक्षित रखें। केवल इसलिए हर prompt को approve न करें कि app का नाम security product है।

हर macOS prompt को इस बात के statement की तरह पढ़ें कि app क्या करना चाहती है। Typical requests में Notifications, Full Disk Access, Accessibility, Screen Recording, network filtering, system extension या administrator-approved helper शामिल हो सकते हैं। हर request का product के काम से ठोस संबंध होना चाहिए।

उदाहरण के लिए, network inspection app का network extension मांगना उचित हो सकता है। Credential action gateway को अपना vault manage करने और named services से connect करने की permission चाहिए हो सकती है, लेकिन इसके लिए universal screen recording की जरूरत नहीं होनी चाहिए। Disk scanner को Full Disk Access की जरूरत हो सकती है, लेकिन उसे बताना चाहिए कि वह क्या पढ़ता है और क्या local रहता है। Product category उसे blank check नहीं देती।

इस short first launch review का उपयोग करें:

• हर prompt को उस documented function से मिलाएं जिसे आप वास्तव में इस्तेमाल करने वाले हैं।
• कोई request unexpected हो तो रुकें और approve करने से पहले vendor का documentation देखें।
• जब तक install होने वाले component का नाम और उद्देश्य स्पष्ट न हो, administrator credentials न दें।
• Setup के बाद System Settings में नए Login Items, profiles, extensions या background items enabled हुए हैं या नहीं, जांचें।
• Release record में app version, Team Identifier, download hash और permission decisions दर्ज करें।

दूसरे और तीसरे bullets महत्वपूर्ण हैं, क्योंकि सबसे महंगी approval अक्सर app permission नहीं होती। वह administrator-approved component हो सकती है जो app की window बंद होने के बाद भी बनी रहती है और app से अधिक access के साथ काम कर सकती है।

Team deployment के लिए इस review को एक simple intake document में रखें। इसमें source location, date, file hash, signing identity, Gatekeeper result, notarization result, installed components, approved permissions और reviewer name शामिल करें। इससे बाद की update review बहुत तेज हो जाती है। Signing identity में आया कोई अनपेक्षित बदलाव हर developer laptop तक पहुंचने से पहले भी दिखाई दे जाता है।

Clean install को trusted operating model न समझें

Clean signature, accepted Gatekeeper assessment और reasonable permission set अच्छी शुरुआत हैं। वे यह साबित नहीं करते कि launch के बाद app हमेशा safe choices करेगी। आपको अभी भी देखना होगा कि वह secrets कहां store करती है, updates को authenticate कैसे करती है, Mac से बाहर क्या भेजती है और compromised process उसके privileges का गलत इस्तेमाल कर सकती है या नहीं।

Agent-facing security tools के लिए ऐसी boundary पर जोर दें जो agent की गलती के बाद भी बनी रहे। Agent को केवल इसलिए reusable credentials नहीं मिलने चाहिए कि उसे कोई action करना है। उसे local control point के ज़रिए action request करना चाहिए, जहां human approval आवश्यक हो और audit trail सुरक्षित रहे।

मैं Sallyport पर भी यही installation standard लागू करता हूं: पहले signed release verify करें, फिर उसकी actual boundary का मूल्यांकन करें। Sallyport credentials को अपने encrypted vault में रखता है और approved HTTP या SSH actions खुद करता है, secrets को agent process में भेजने के बजाय।

उपयोगी आदत सरल है: किसी app को केवल security software कहे जाने के कारण broad authority न दें। उससे publisher identity, unmodified contents, Gatekeeper status और मांगे गए exact access का प्रमाण मांगें। अगर वह इस review से नहीं गुजर सकती, तो उसे वे permissions नहीं मिलनी चाहिए जो security app को powerful बनाती हैं।