我们有 2 个代码分析器、4 个动态测试工具、我们自己的工艺和 250 个脚本。 并不是说这一切都是当前流程所需要的，但是一旦开始实施DevSecOps，就必须坚持到底。
。 角色创作者：Justin Roiland 和 Dan Harmon。
什么是 SecDevOps？ DevSecOps 怎么样？ 有什么区别？ 应用程序安全性——它是关于什么的？ 为什么经典方法不再有效？ 知道所有这些问题的答案 尤里沙巴林 из 剑鱼安全。 Yuri 将详细回答所有问题，并分析从经典应用安全模型到 DevSecOps 流程过渡的问题：如何正确地将安全开发流程集成到 DevOps 流程中而不破坏任何内容，如何经历主要阶段安全测试的内容、可以使用哪些工具、它们有何不同以及如何正确配置它们以避免陷阱。
关于演讲者： 尤里·沙巴林 - 公司首席安全架构师 剑鱼安全。 负责SSDL的实施，将应用程序分析工具整体集成到统一的开发和测试生态系统中。 7年信息安全经验。 曾在 Alfa-Bank、Sberbank 和 Positive Technologies 工作，该公司开发软件并提供服务。 在 ZerONights、PHDays、RISSPA、OWASP 国际会议上发表演讲。
应用程序安全性：它是关于什么的？
应用安全 - 这是负责应用程序安全的安全部分。 这不适用于基础设施或网络安全，而是适用于我们编写的内容和开发人员所做的工作 - 这些是应用程序本身的缺点和漏洞。
方向 - 安全开发生命周期 - 由微软开发。 该图显示了规范的SDLC模型，其主要任务是安全性参与开发的每个阶段，从需求到发布和生产。 微软意识到这个行业存在太多的错误，而且数量越来越多，必须采取一些措施来解决它，他们提出了这种方法，该方法已经成为规范。
应用程序安全和 SSDL 的目的并不是像人们普遍认为的那样检测漏洞，而是预防漏洞的发生。 随着时间的推移，微软的规范方法得到了改进、发展，并引入了更深入、更详细的研究。
规范的 SDLC 在各种方法中非常详细 - OpenSAMM、BSIMM、OWASP。 方法不同，但总体相似。
在成熟度模型中构建安全性
我最喜欢它 BSIMM - 。 该方法的基础是将应用程序安全流程分为 4 个领域：治理、智能、SSDL 接触点和部署。 每个领域有 12 个实践，代表 112 个活动。
112项活动中的每一项都有 3个成熟度级别：初级、中级、高级。 你可以逐节研究所有 12 种实践，选择对你来说重要的事情，弄清楚如何实现它们并逐渐添加元素，例如静态和动态代码分析或代码审查。 你写下一个计划，并根据它冷静地工作，作为实施所选活动的一部分。
为什么选择 DevSecOps
DevOps 是一个通用的大型流程，必须考虑安全性。
最初 涉及安全检查。 在实践中，安全团队的数量比现在少得多，他们不是作为流程的参与者，而是作为控制和监督机构，对其提出要求并在发布结束时检查产品的质量。 这是一种经典方法，其中安全团队远离开发并且不参与该过程。
主要问题是信息安全与开发脱节。 通常这是某种信息安全电路，包含 2-3 个大型且昂贵的工具。 每六个月一次，需要检查的源代码或应用程序到达，每年一次生成 。 所有这些导致行业的发布日期被推迟，并且开发人员面临自动化工具的大量漏洞。 不可能将所有这些都拆卸和修复，因为前六个月的结果还没有整理出来，但这里是新的一批。
在我们公司的工作过程中，我们看到各个领域、各个行业的安全都明白，是时候跟上发展的步伐了—— 。 DevSecOps 范式与每次发布和迭代中的敏捷开发方法、实施、支持和参与完美契合。
过渡到 DevSecOps
安全开发生命周期中最重要的词是 “过程”。 在考虑购买工具之前，您必须了解这一点。
仅仅将工具整合到 DevOps 流程中是不够的，流程参与者之间的沟通和理解很重要。
人更重要，而不是工具。
通常，安全开发流程的规划从选择和购买工具开始，并以尝试将该工具集成到当前流程中结束，这仍然是尝试。 这会导致不幸的后果，因为所有工具都有自己的特点和局限性。
一个常见的情况是，安全部门选择了一个好的、昂贵的、功能广泛的工具，然后找开发人员将其集成到流程中。 但它并没有成功——该流程的结构使得已购买的工具的局限性不适合当前的范式。
首先，描述您想要什么结果以及过程是什么样的。 这将有助于理解工具和安全在此过程中的作用。
从已经在使用的东西开始
在购买昂贵的工具之前，请先看看您已有的工具。 每个公司都有开发的安全需求，有检查，有渗透测试——为什么不把这一切转化为大家都能理解、方便的形式呢？
通常，要求是放在架子上的纸质塔木德。 有一个案例，我们来到一家公司看流程，要求看软件的安全要求。 处理这个问题的专家花了很长时间寻找：
- 现在，在笔记中的某处有一条该文档所在的路径。
结果一周后我们就收到了文件。
对于要求、检查和其他内容，请创建一个页面，例如 合流 - 这对每个人来说都很方便。
重新格式化您已有的内容并使用它来开始使用会更容易。
使用安全冠军
通常，在拥有 100-200 名开发人员的普通公司中，会有一名安全专家负责执行多项职能，但实际上没有时间检查所有内容。 即使他尽力了，他一个人也不会检查开发生成的所有代码。 对于这种情况，我们提出了一个概念—— .
安全冠军是开发团队中对产品安全感兴趣的人员。
安全冠军是进入开发团队的切入点，同时也是安全布道者。
通常，当安全专家来到开发团队并指出代码中的错误时，他会收到一个令人惊讶的答案：
- 你是谁？ 我是第一次见到你。 对我来说一切都很好 - 我的高级朋友在代码审查中给了我“申请”，我们继续！
这是一种典型的情况，因为对开发人员在工作和代码审查中不断互动的前辈或队友有更多的信任。 如果安全冠军而不是安全官员指出错误和后果，那么他的话就会更有分量。
此外，开发人员比任何安全专家都更了解他们的代码。 对于一个在静态分析工具中拥有至少 5 个项目的人来说，通常很难记住所有的细微差别。 安全冠军了解他们的产品：什么与什么相互作用以及首先关注什么 - 他们更有效。
因此，请考虑实施安全冠军并扩大安全团队的影响力。 这对冠军本人也很有用：在新领域进行专业发展，扩大技术视野，提升技术、管理和领导技能，增加市场价值。 这是社会工程的一些要素，是开发团队中你的“眼睛”。
测试阶段
说20%的努力产生80%的结果。 这 20% 是可以而且应该自动化的应用程序分析实践。 此类活动的示例是静态分析 - SAST，动态分析- 达斯特 и 开源控制。 我将更详细地告诉您有关活动以及工具、将它们引入流程时我们通常会遇到哪些功能以及如何正确执行的信息。
工具的主要问题
我将强调与所有文书相关并需要注意的问题。 我将更详细地分析它们，以免进一步重复。
分析时间长。 如果从提交到发布全部测试和组装需要30分钟，那么信息安全检查就需要一天的时间。 所以没有人会放慢这一进程。 考虑到这个特征并得出结论。
高水平的假阴性或假阳性。 所有产品都是不同的，都使用不同的框架和自己的编码风格。 在不同的代码库和技术上，工具可能会显示不同级别的假阴性和假阳性。 所以看看里面到底是什么 您的 公司和为 您的 应用将显示出良好且可靠的结果。
不与现有工具集成。 从与您已经使用的工具的集成角度来看待工具。 例如，如果您有 Jenkins 或 TeamCity，请检查这些工具与该软件的集成，而不是与您不使用的 GitLab CI 的集成。
定制缺乏或过于复杂。 如果一个工具没有 API，那为什么还需要它呢？ 界面中可以完成的所有操作都应该可以通过 API 获得。 理想情况下，该工具应该能够自定义检查。
没有产品开发路线图。 发展不会停滞不前，我们总是在使用新的框架和功能，将旧代码重写为新语言。 我们希望确保我们购买的工具能够支持新的框架和技术。 因此，了解产品具有真实且正确的信息非常重要 发展。
流程功能
除了工具的特性外，还要考虑开发过程的特性。 例如，阻碍发展是一个常见的错误。 让我们看看还应该考虑哪些其他功能以及安全团队应该注意什么。
为了不错过开发和发布截止日期，创建 不同的规则 和不同的 表演塞子 — 在存在漏洞的情况下停止构建过程的标准 — 针对不同环境。 例如，我们知道当前分支转到开发站或UAT，这意味着我们不会停下来说：
“你这里有漏洞，你不能再往前走！”
此时，有必要告诉开发者，存在需要注意的安全问题。
漏洞的存在并不妨碍进一步测试：手动、集成或手动。 另一方面，我们需要以某种方式提高产品的安全性，以便开发人员不会忽视他们认为安全的东西。 因此，有时我们会这样做：在展台上，当它被推出到开发环境时，我们只是通知开发：
- 伙计们，你们有问题，请注意它们。
在UAT阶段我们再次显示有关漏洞的警告，在发布阶段我们说：
- 伙计们，我们警告过你们好几次了，你们什么也没做——我们不会让你们这么做的。
如果我们谈论代码和动态，那么有必要仅显示和警告那些功能和刚刚在此功能中编写的代码的漏洞。 如果开发人员将按钮移动了 3 个像素，我们告诉他那里有 SQL 注入，因此需要紧急修复，这是错误的。 只看现在写的内容以及应用程序的更改。
假设我们有某种功能缺陷 - 应用程序不应该工作的方式：钱没有转移，当您单击按钮时没有转换到下一页，或者产品没有加载。 安全缺陷 - 这些是相同的缺陷，但不是在应用程序操作方面，而是在安全方面。
并非所有的软件质量问题都是安全问题。 但所有的安全问题都与软件质量有关。 谢里夫·曼苏尔，Expedia。
由于所有漏洞都是相同的缺陷，因此它们应该与所有开发缺陷位于同一位置。 因此，忘掉那些无人阅读的报告和可怕的 PDF 吧。
当我在一家开发公司工作时，我收到了一份静态分析工具的报告。 我打开它，感到震惊，煮了咖啡，翻阅了 350 页，合上它，继续工作。 大报告都是死报告。 通常它们无处可去，信件被删除、遗忘、丢失，或者企业表示接受风险。
该怎么办？ 我们只是将发现的已确认的缺陷转换成方便开发的形式，例如，我们将它们放入Jira中的backlog中。 我们对缺陷进行优先级排序，并按优先级顺序消除它们，以及功能缺陷和测试缺陷。
静态分析-SAST
这是针对漏洞的代码分析。，但它与 SonarQube 不一样。 我们不只是检查图案或风格。 分析中使用了多种方法：根据漏洞树，根据 ，通过分析配置文件。 这就是代码本身的全部内容。
该方法的优点: 在开发的早期阶段识别代码中的漏洞当还没有支架或现成的工具时，并且 增量扫描能力：扫描有变化的一段代码，并且只扫描我们当前正在做的功能，这样就减少了扫描时间。
缺点 - 这是缺乏对必要语言的支持。
必要的集成， 在我主观看来，这应该在工具中：
- 集成工具：Jenkins、TeamCity 和 Gitlab CI。
- 开发环境：Intellij IDEA、Visual Studio。 对于开发人员来说，更方便的是，不要浏览仍然需要记住的难以理解的界面，而是在自己的开发环境中查看他在工作场所发现的所有必要的集成和漏洞。
- 代码审查：SonarQube 和手动审查。
- 缺陷跟踪器：Jira 和 Bugzilla。
下图展示了静态分析的一些最佳代表。
重要的不是工具，而是流程，因此开源解决方案也适合测试流程。
SAST Open Source不会发现大量漏洞或复杂的数据流，但在构建流程时可以而且应该使用它们。 他们有助于了解如何构建流程、谁将响应错误、谁将报告以及谁将报告。 如果您想执行构建代码安全性的初始阶段，请使用开源解决方案。
如果您正处于旅程的开始并且什么都没有：没有 CI、没有 Jenkins、没有 TeamCity，那么如何集成？ 让我们考虑集成到流程中。
CVS 级别集成
如果您有 Bitbucket 或 GitLab，则可以进行级别集成 .
按事件 - 拉取请求，提交。 您扫描代码，构建状态会显示安全检查是通过还是失败。
联系我们。 当然，反馈总是需要的。 如果你只是兼职做安全工作，把它放在一个盒子里，没有告诉任何人任何事情，然后在月底抛出一堆错误 - 这是不正确的，也不好。
与代码审查系统集成
曾经，我们在多个重要项目中担任技术 AppSec 用户的默认审阅者。 根据新代码中是否发现错误或没有错误，审阅者将拉取请求的状态设置为“接受”或“需要工作” - 要么一切正常，要么指向确切需要改进的内容的链接需要改进。 为了与即将投入生产的版本进行集成，如果未通过信息安全测试，我们启用了合并禁止。 我们将其包含在手动代码审查中，并且该过程中的其他参与者看到了该特定过程的安全状态。
与 SonarQube 集成
许多人都有 在代码质量方面。 这里也是一样 - 您只能为 SAST 工具制作相同的门。 会有同样的接口，同样的质量门，只有它会被调用 安全门。 而且，如果您有一个使用 SonarQube 的流程，您可以轻松集成其中的所有内容。
CI 级别的集成
这里的一切也很简单：
- 与自动测试相当，单元测试。
- 按发展阶段划分：开发、测试、生产。 可能包括不同的规则集或不同的失败条件：停止组装、不停止组装。
- 同步/异步启动。 我们正在等待安全测试是否结束。 也就是说，我们只是启动它们并继续前进，然后我们就得到一切是好还是坏的状态。
这一切都在一个完美的粉红色世界中。 现实生活中没有这样的事情，但我们努力。 运行安全检查的结果应该与单元测试的结果类似。
例如，我们进行了一个大型项目，并决定现在使用 SAST 对其进行扫描 - 好的。 我们将这个项目推入了 SAST，它给我们带来了 20 个漏洞，但我们通过坚定的决定决定一切都很好。 000 个漏洞是我们的技术债务。 我们将把债务放在一个盒子里，我们将慢慢清理它，并将错误添加到缺陷跟踪器中。 让我们雇佣一家公司，自己做所有事情，或者让安全冠军帮助我们 - 技术债务将会减少。
新代码中所有新出现的漏洞都必须以与单元或自动测试中的错误相同的方式消除。 相对而言，组装开始，我们运行它，两次测试和两次安全测试都失败了。 好的 - 我们去了，看看发生了什么，修复了一件事，修复了另一件事，下次运行它 - 一切都很好，没有出现新的漏洞，没有测试失败。 如果此任务比较深入并且您需要很好地理解它，或者修复漏洞会影响底层的大部分内容：错误已添加到缺陷跟踪器中，则会对其进行优先级排序并进行纠正。 不幸的是，世界并不完美，测试有时会失败。
安全门的一个例子是质量门的类似物，就代码中漏洞的存在和数量而言。
我们与 SonarQube 集成 - 插件已安装，一切都非常方便和酷。
与开发环境集成
集成选项：
- 在提交之前从开发环境运行扫描。
- 查看结果。
- 分析结果。
- 与服务器同步。
这就是从服务器接收结果的样子。
在我们的开发环境中 只是出现一个附加项目，通知您在扫描过程中检测到此类漏洞。 您可以立即编辑代码，查看建议并 。 这一切都位于开发人员的工作场所，这非常方便 - 无需点击其他链接并查看其他内容。
开源
这是我最喜欢的话题。 每个人都使用开源库——当你可以使用一个所有东西都已经实现的现成库时，为什么还要写一堆拐杖和自行车呢？
当然，这是事实，但库也是由人编写的，它们也包含一定的风险，并且还存在定期或不断报告的漏洞。 因此，应用安全的下一步就是对开源组件的分析。
开源分析 - OSA
该工具包括三个大阶段。
搜索库中的漏洞。 例如，该工具知道我们正在使用某个库，并且在 或者错误跟踪器中存在与此版本的库相关的一些漏洞。 当您尝试使用它时，该工具会发出警告，指出该库存在漏洞，并建议您使用其他没有漏洞的版本。
许可证纯度分析。 这在这里还不是特别流行，但是如果您在国外工作，那么有时您可能会因使用无法使用或修改的开源组件而被征税。 根据许可图书馆的政策，我们不能这样做。 或者，如果我们修改它并使用它，我们应该发布我们的代码。 当然，没有人愿意发布他们产品的代码，但您也可以保护自己免受这种情况的影响。
分析工业环境中使用的组件。 让我们想象一个假设的情况，我们终于完成了开发并发布了微服务的最新版本。 他在那里生活得非常美好——一周、一个月、一年。 我们不收集，我们不进行安全检查，一切似乎都很好。 但突然间，发布两周后，我们在工业环境中的这个特定构建中使用的开源组件中出现了一个严重漏洞。 如果我们不记录我们使用的内容和位置，那么我们根本就不会看到此漏洞。 一些工具能够监控行业当前使用的库中的漏洞。 这非常有用。
特点：
- 不同的发展阶段有不同的政策。
- 监控工业环境中的组件。
- 组织内图书馆的控制。
- 支持各种构建系统和语言。
- Docker 镜像分析。
一些从事开源分析的行业领导者的例子。
唯一免费的就是这个 来自 OWASP。 您可以在第一阶段打开它，看看它是如何工作的以及它支持什么。 基本上，这些都是云产品或本地产品，但在其基础背后，它们仍然被发送到互联网。 他们发送的不是您的库，而是他们计算的哈希值或他们自己的值以及指纹到他们的服务器，以接收有关漏洞存在的信息。
流程整合
图书馆周边控制，它们是从外部源下载的。 我们有外部和内部存储库。 例如，Event Central 运行 Nexus，我们希望确保我们的存储库中不存在处于“严重”或“高”状态的漏洞。 您可以使用 Nexus Firewall Lifecycle 工具配置代理，以便切断此类漏洞并且不会最终出现在内部存储库中。
集成到 CI 中。 与自动测试、单元测试处于同一级别，并划分为开发阶段：开发、测试、生产。 在每个阶段，您都可以下载任何库，使用任何东西，但如果存在“关键”状态的困难，也许值得在发布到生产阶段引起开发人员的注意。
与工件集成：Nexus 和 JFrog。
集成到开发环境中。 您选择的工具应该与开发环境集成。 开发人员必须能够从其工作场所访问扫描结果，或者能够在提交 CVS 之前自行扫描和检查代码是否存在漏洞。
光盘集成。 这是我非常喜欢的一个很酷的功能，我已经讨论过它 - 监控工业环境中新漏洞的出现。 它的工作原理是这样的。
我们有 公共组件存储库 — 一些外部工具，以及我们的内部存储库。 我们希望它只包含可信组件。 代理请求时，我们检查下载的库是否存在漏洞。 如果它属于我们制定的某些政策并且必须与开发相协调，那么我们不会上传它并提示使用另一个版本。 因此，如果库中有一些非常关键和不好的东西，那么开发人员将不会在安装阶段收到该库 - 让他使用更高或更低的版本。
- 在构建时，我们会检查是否有人遗漏了任何损坏的东西，所有组件都是安全的，并且没有人在闪存驱动器上带来任何危险的东西。
- 我们在存储库中只有受信任的组件。
- 部署时，我们再次检查包本身：war、jar、DL或Docker镜像，以确保其符合策略。
- 当进入行业时，我们监控工业环境中正在发生的事情：出现或不出现严重漏洞。
动态分析 - DAST
动态分析工具与之前所说的一切都有根本的不同。 这是对用户使用应用程序的操作的一种模仿。 如果这是一个Web应用程序，我们发送请求，模拟客户端的工作，单击前面的按钮，从表单发送人工数据：引号，括号，不同编码的字符，以查看应用程序如何工作和处理外部数据。
同一系统允许您检查开源中的模板漏洞。 由于 DAST 不知道我们正在使用哪个开源代码，因此它只是抛出“恶意”模式并分析服务器的响应：
- 是的，这里有反序列化问题，但这里不是。
这其中存在很大的风险，因为如果您在测试人员使用的同一个工作台上进行安全测试，则可能会发生不愉快的事情。
- 应用程序服务器网络负载高。
- 没有集成。
- 能够更改所分析的应用程序的设置。
- 没有必要的技术支持。
- 设置困难。
当我们最终启动 AppScan 时，我们遇到了一个情况：我们花了很长时间尝试访问该应用程序，获得了 3 个帐户，并且很高兴 - 我们终于可以检查所有内容了！ 我们启动了扫描，AppScan 做的第一件事就是进入管理面板，刺穿所有按钮，更改一半数据，然后用其完全杀死服务器 -要求。 开发与测试说道：
- 伙计们，你们在开玩笑吗？！ 我们给你算账，你摆摊！
考虑可能的风险。 理想情况下，准备一个单独的测试台来测试信息安全，至少以某种方式与环境的其他部分隔离，并有条件地检查管理面板，最好是在手动模式下。 这是渗透测试——我们现在不考虑的剩余工作百分比。
值得考虑的是，您可以将其用作负载测试的模拟。 在第一阶段，您可以打开具有 10-15 个线程的动态扫描仪，看看会发生什么，但正如实践所示，通常没有什么好处。
一些我们经常使用的资源。
值得强调 对于任何安全专业人员来说都是一把“瑞士刀”。 大家都在用，而且非常方便。 企业版的新演示版本现已发布。 如果早些时候它只是一个带有插件的独立实用程序，那么现在开发人员终于制作了一个大型服务器，可以从中管理多个代理。 这很酷，我建议你尝试一下。
流程整合
集成过程非常顺利且简单： 安装成功后开始扫描 展位申请及 集成测试成功后扫描.
如果集成不起作用或者存在存根和模拟函数，那么它就毫无意义且无用——无论我们发送什么模式，服务器仍然会以相同的方式响应。
- 理想情况下，有一个单独的测试台。
- 测试前，记下登录顺序。
- 管理系统的测试仅是手动的。
过程
对一般过程以及每个工具的具体工作进行了一些概括。 所有应用程序都是不同的 - 一个应用程序使用动态分析效果更好，另一个应用程序使用静态分析，第三个应用程序使用开源分析、渗透测试或其他东西，例如，事件 .
每个过程都需要控制。
要了解流程的工作原理以及可以改进的地方，您需要从您可以获得的所有内容中收集指标，包括生产指标、工具指标和缺陷跟踪器指标。
任何信息都有帮助。 有必要从不同的角度来看看这个或那个工具在哪里更好地使用，在哪里过程特别下垂。 可能值得查看开发响应时间，以了解在哪里可以根据时间改进流程。 数据越多，从顶层到每个流程的细节可以构建的部分就越多。
由于所有静态和动态分析器都有自己的 API、自己的启动方法、原理，有些有调度程序，有些则没有 - 我们正在编写一个工具 应用安全协调器，它允许您从产品创建整个流程的单一入口点并从一个点进行管理。
经理、开发人员和安全工程师可以通过一个入口点查看正在运行的内容、配置和运行扫描、接收扫描结果以及提交要求。 我们正在尝试摆脱文书工作，将所有内容转化为人类的内容，以供开发使用 - Confluence 上的状态和指标页面、Jira 或各种缺陷跟踪器中的缺陷，或者集成到 CI 中的同步/异步流程中/光盘。
关键精华
工具不是主要的。 首先思考整个流程 - 然后实施工具。 这些工具很好，但价格昂贵，因此您可以从流程开始，在开发和安全之间建立沟通和理解。 从安全的角度来看，没有必要“停止”一切；从发展的角度来看，如果有什么高兆超危的东西，那就需要消除，而不是对问题视而不见。
产品质量 - 共同的目标 安全与发展并举。 我们只做一件事，努力确保一切正常运转，并且不存在声誉风险或财务损失。 这就是为什么我们提倡 DevSecOps、SecDevOps 方法来改善沟通并提高产品质量。
从你已有的开始：需求、架构、部分检查、培训、指南。 没有必要立即将所有实践应用到所有项目中—— 迭代地移动。 没有单一的标准—— 实验 并尝试不同的方法和解决方案。
信息安全缺陷与功能缺陷是等号的.
自动化一切那个移动。 凡是不动的，就移动它并使其自动化。 如果某件事是手工完成的，那么它就不是该过程的一个好的部分。 也许值得对其进行审查并使其自动化。
如果IS团队规模较小—— 使用安全冠军.
也许我所说的不适合你，你会想出一些你自己的东西——这很好。 但 根据您的流程要求选择工具。 不要看社区怎么说，说这个工具不好，这个工具好。 也许您的产品恰恰相反。
对工具的要求。
- 低水平误报。
- 充足的分析时间。
- 使用方便。
- 集成的可用性。
- 了解产品开发路线图。
- 定制工具的可能性。
Yuri 的报告被评为 DevOpsConf 2018 最佳报告之一。想要了解更多有趣的想法和实际案例，请于 27 月 28 日至 XNUMX 日来到斯科尔科沃 之内 。 更好的是，如果您准备好分享您的经验，那么 报告截止日期为 21 月 XNUMX 日。
来源： habr.com